My thinking would be that the login script would fetch a web page from a server. That web page would then check the database - if it's clear then login proceeds. If it's showing the user may be logged on elsewhere then it would attempt to query the remote machine (web page can do this using admin level credentials) and if the user isn't logged on or the machine is down then again login proceeds.
That can be a pain with domain admin rights: Pre-reqs are clean DNS, that Remote Admin hole in the firewall, WMI actually working, the machine not starting up or shutting down, and "are-they-still-logged-on?" threads really need to time-out much quicker than Windows RPC does when it hits some of those problems. This is where client-side code has some advantages i.e. it bypasses all of that.you need to be able to connect to WMI
I carefully reviewed this very interesting thread and noticed 2 things:
1) Most of you think that UserLock is the best software solution when it comes to securing and optimizing free access Windows networks in educational organizations.
2) Most of you experience serious budget issues and cannot afford purchasing UserLock licenses at their standard price.
I'd like to make a proposal.
As you may know:
- UserLock’s licensing scheme is per maximum simultaneous sessions on your network. This usually amounts to the total workstations.
A license is also required per terminal session (Terminal Server, Citrix...), if any. UserLock will not protect sessions exceeding the license count.
- UserLock licenses price goes down as the amount of user session licenses purchased goes up.
The more you purchase, the larger the discount!
As CEO of IS Decisions, I am ready to consider all Edugeek forums members as a “unique virtual customer”.This means that we will apply volume discounts not to your individual UserLock order, but to the total amount of licenses ordered by all interested Edugeek forums members.
And we will grant an exceptional 10% extra discount on top of that.
Let’s take an example:
- 10 Edugeek Forums members are interested in UserLock, with the following individual licenses requirements: 200, 300, 500, 800, 1 000, 1 200, 1 500, 2 000, 2 500, 4 000.
- This amounts to a total of 14 000 UserLock licenses
- Standard Unit Price for 14 000 UserLock licenses: € 1,69 (app. £ 1,51)
- Educational Unit Price for 14 000 UserLock licenses: € 1,35 (app. £ 1,21)
- Exceptional Unit Price for 14 000 UserLock licenses: € 1,21 (app. £ 1,08)
This exceptional offer is valid for Purchase Orders placed until 28 May 2010.
I therefore suggest that each interested Edugeek posts his/her individual licenses requirements in this thread and also sends this information to email@example.com before 16 April 2010.
We will add all these licenses requirements and inform you in this thread about the Exceptional Unit Price that will result from this addition.
We will then send an individual quotation based upon this Exceptional Unit Price to each interested educational institution and will process orders accordingly.
Please let me know your thoughts and/or start posting your UserLock licenses requirements!
Thanks in advance. Warm regards,
chazzy2501 (25th March 2010)
I've just recently been looking into alternatives to the system we've been using the last few years. And it doesn't seem there are many on the market, as I see it's not been mentioned at all on Edugeek I thought I might pass the link over. Please be aware I'm in no way affiliated with the company and can only vouch for it's effectiveness on RM CC3... but yeah, it works very well and (perhaps more importantly), it costs us 20x less than it's main competitor...
According to the website XP, Vista, and Seven are all supported.
Here's the link: Flo Computer Services - MaxLogons
Last edited by MWT; 8th March 2011 at 12:03 AM.
The cconnect utility mentioned here Limiting a user's concurrent connections in Windows Server 2003, Windows 2000, and Windows NT 4.0 is getting a bit long in the tooth but works pretty well. I used it at my last school - admittedly in an XP environment, but there's no reason it shouldn't work on a later OS.
The main part runs in the log on/off script. When a user logs on, it records this to a database. A subsequent logon from a different PC checks the database and logs off the second user immediately if they are recorded as already being logged on elsewhere. When the first used logs off the PC normally, this clears the flag in the database and the user is free to log on elsewhere.
Should the user PC crash or get turned off - the little scallys do like to play pranks on each other - they can log back on to the PC they originally logged on to fine as the setup allows re-logins from the original PC. They can then log off normally and the flag will be cleared from the database.
There is a simple front end that the admin team can use to check the recorded logons (perhaps to see who is logged on where) or clear individual records.
As said, it worked a treat for us at our last place - and may be worth a punt if you can't stretch to a licenced product or don't fancy mucking around in your AD schema.
Cconnect offers limited and poor functionality and is really complex to implement.
Worse, Cconnect introduces new breaches: with very limited skills, it is possible to carry out several successful attacks. These attacks let an unskilled user log in despite CConnect measures, gain sensitive information, and finally run a Denial of Service attack.
How to circumvent CConnect protection
On every request, CConnect opens a fresh session in the first place, performs the authorization process, and then logs the user off if needed.
- An illegitimate user can run a Ctr-Del-Alt, find and kill the CConnect process through the task manager before CConnect logs the user off. The illegitimate user is logged in.
- Once a user is logged in, a regular user can edit a .bat file that launches the following command at startup: kill.exe –f CConnect. Kill.exe is provided in the Resource Kit, along with CConnect!
This effectively stops CConnect during the subsequent connections, and lets illegitimate users log in despite CConnect protection.
- Once a user is logged in, a regular user can edit a dummy string value pointing to an erroneous address under the key HKCU\Software\Microsoft\Windows\CurrentVersion\Run .
As a result, Windows will prompt a message error that freezes the opening session process. This allows enough time for an attacker to do whatever he wants in order to circumvent CConnect protection, for instance to kill CConnect process.
These attacks point out an obvious flaw in CConnect design - the security-related function, the authorization, is entirely performed by the agent.
Amazingly enough, the agent can be killed by a user without any privileges.
Arguably CConnect was designed with no security in mind.
How to gather information for further attacks exploiting CConnect flaws
In order to perform the authorization process, the agent has to send and retrieve information from the SQL Server database.
To do so, it stores the worthy information in HKCU\Software\Microsoft\CConnect in the client register. An inquisitive attacker will very easily discover the server’s name, an account and its
password, all in clear.
Once in possession of this juicy information, he gets full access to that database. If poorly administrated, the attacker would also get full access to the entire database server.
How to run a DoS attack exploiting CConnect flaw
As just said above, any user has easy and full access to the database table that holds CConnect information, namely SYSIAD table in the master database. There are two easy ways to launch aDenial of Service attack:
- The attacker logs in a workstation with User A´s account, improperly stops CConnect.exe, e.g. by killing it using the task manager (alternatively a dirtier option would be to crash the system).
As CConnect stops unexpectedly, it does not clean its entry in the SYSIAD table, therefore from CConnect’s view User A is still logged in. With just one concurrent connection allowed, he
cannot log in any more. Failsafe is not a CConnect feature…
-A more ambitious attacker can launch a mass Denial of Service simply using MS Access.
All he has to do is open a new project, connect to the database, overwrite the SYSIAD table, and prevent everybody, including the network administrators to log into the system!
"An illegitimate user can run a Ctr-Del-Alt, find and kill the CConnect process through the task manager before CConnect logs the user off. The illegitimate user is logged in."
"Once a user is logged in, a regular user can edit a .bat file that launches the following command at startup: kill.exe –f CConnect. Kill.exe is provided in the Resource Kit, along with CConnect!
This effectively stops CConnect during the subsequent connections, and lets illegitimate users log in despite CConnect protection"
"Once a user is logged in, a regular user can edit a dummy string value pointing to an erroneous address under the key HKCU\Software\Microsoft\Windows\CurrentVersion\Run .
As a result, Windows will prompt a message error that freezes the opening session process. This allows enough time for an attacker to do whatever he wants in order to circumvent CConnect protection, for instance to kill CConnect process."
"Amazingly enough, the agent can be killed by a user without any privileges"
GPO's can prevent this
All of those concerns can be addressed technically, it will take some time to test and implement but can be done.
However, I have not heard or or used your product, but sounds good.
There are currently 1 users browsing this thread. (0 members and 1 guests)