Stop Pupils Sharing their logins!

[localzuk]

File servers usually show hundreds of logon and logoff events for the same user throughout the day, because each time a user maps a drive to a server, opens up a file on this server and then closes it, the file server closes (within just seconds or at the most a couple of minutes) that logon session and logs a logoff event …

 

Good luck with the filtering!

 

On the contrary, UserLock only logs an event when a user opens a desktop session, when he locks/unlocks his desktop and when he logs off.

This will usually generate 4 events per day (maybe a bit more if a password protected screensaver is configured) and will allow SysAdmins to seamlessly analyze and archive session history.

 

Indeed, the logs do show multiple logons/off events for a single user. However, you are also forgetting your target market - schools. A pupil may log in and out of the network more than once in a day, depending on their lessons/clubs - so there is more than likely to be more than 4 events a day for your system...

 

I've just had a look at the log, and filtered it down to a single one of our users and as you say there are many events for that user since they logged on at 7:30am. However, all those events contain the IP address of the machine they're using, so filtering it wouldn't be difficult - just add a chunk of code which checks to see if the new events are still on the same IP.

 

However, I can see this sort of thing chewing through a substantial amount of resources, processing all the events, sending requests to machines etc... Doing it client-side would be a lot more bandwidth and server friendly.

 

The problem I have with UserLock is the price, limiting logins isn't a task which I would consider spending money on, as it is a relatively minor issue. If it were a function of a larger suite of tools, then maybe, but £1655k for our 600 kid school , if we were to ever have a computer per child (or £730 for the current number of machines)? No chance - our entire network control package doesn't cost that much.

Edited March 19, 2010 by localzuk

[FAA]

Indeed, the logs do show multiple logons/off events for a single user. However, you are also forgetting your target market - schools. A pupil may log in and out of the network more than once in a day, depending on their lessons/clubs - so there is more than likely to be more than 4 events a day for your system...

 

You are right, but dozens of relevant events are manageable when hundreds are not.

 

 

The problem I have with UserLock is the price, limiting logins isn't a task which I would consider spending money on, as it is a relatively minor issue. If it were a function of a larger suite of tools, then maybe, but £1655k for our 600 kid school , if we were to ever have a computer per child (or £730 for the current number of machines)? No chance - our entire network control package doesn't cost that much.

 

UserLock offers far more features than just limiting concurrent logins. Please check "Securing and optimizing a free access network", but I got your point.

 

How many machines do you have in your network?

Edited March 19, 2010 by FAA

[cookie_monster]

I use a simple VB script that logs to an access Db (currently) it logs user logon and logoff, it works very well and it's free and simple.

 

On Error Resume Next

Dim adoCn
Dim adoRs
Dim network
Dim user
Dim compname
Dim strSQLInsert


Dim WshShell ' <--- New 
Set WshShell = CreateObject("WScript.Shell") ' <--- New 

Set network = CreateObject("Wscript.Network")

user = network.username
compname = network.computername

Set adoCn = CreateObject("ADODB.Connection")

adoCn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
          "Data Source=\\server\logs$\students.mdb" 'CHANGE THIS BIT

'Check the connection opened ok           
If Err.Number <> 0 Then           
Call ErrHandler
End If

' ********************* NEW BIT *******************
'Citrix specific section

if UCase(Left(compname, 4) = "CITR") then

compname = UCase(WshShell.ExpandEnvironmentStrings("%CLIENTNAME%"))

end if
' **************************************************

strSQLInsert = "INSERT INTO [Log On] ([date], [time], [user], compname) " & _  
"VALUES ('" & Date & "', '" & Time & "', '" & user & "', '" & compname & "')"

adoCn.Execute strSQLInsert, , 8

'Check the data was inserted OK
If Err.Number <> 0 Then           
Call ErrHandler
End If

adoCn.Close

Set adoCn = Nothing
Set network = Nothing





Sub ErrHandler()
Dim fso, f

Const ForReading = 1, ForWriting = 2, ForAppending = 8

Set fso = CreateObject("Scripting.FileSystemObject")

Set f = fso.OpenTextFile("\\server\logs$\" & LogError & ".txt" , ForAppending, True)

f.WriteLine Date & ", " & Time & ", " & user & ", " & compname & ", " & Chr(34) & Err.Description & Chr(34)
f.Close

Set fso = nothing

Err.Clear

End Sub

 

I'm not a great coder

Edited March 19, 2010 by cookie_monster

[PiqueABoo]

File servers usually show hundreds of logon and logoff events for the same user throughout the day

 

::shrug again:: Enumerate AD for every computer that isn't a workstation in your domain, drop any logon activity where the associated computer is in that list. If necessary add some custom computers to the drop list via some app registry key. Now what does that leave you with? And how hard was that aspect?

 

OK there will still be some things to deal with in the remainder, but I think the difficult bit (besides needing to get you head around making subauthentication packages for DCs), is knowing when someone pulled the plug out of the wall instead of logging off gracefully. I'm struggling to see a way of doing that centrally which doesn't involve polling your current list of computers-with-logged-on-users every so often...

 

..and having said that I'm struggling to see how a solution with client-side code hooking logon/off events would cope with that much better (you could do it in the other direction though i.e. have the client send a server some kind of "keep alive").

 

PS: Doh.. polling ..I don't think we care unless some user logs on to a second machine i.e. that's the only point you really need to go look at what's happened on the first one. Or is my brain broken tonight?

Edited March 19, 2010 by PiqueABoo
PS:

[localzuk]

PS: Doh.. polling ..I don't think we care unless some user logs on to a second machine i.e. that's the only point you really need to go look at what's happened on the first one. Or is my brain broken tonight?

 

Good point!! The server doesn't need to keep track of anything like log off events, it can just poll the machine which had a log on event, to see if it still valid! Very simple really!

[LCPSWolf]

I'm glad to see this issue is still being bounced around. I'm facing this issue over 5 schools with close to 4000 PC's. Userlock, though the "best" solution isn't an option due to budget.

 

I can't wait to see where this is heading. For whatever reason, the LimitLogin requirements (IIS, Soap, client side programs) just don't seem reasonable.

 

We're just this year coming from Novell which had the limiting of logins built it. We miss the ability! As an aside, Do I assume that Novell's abililty to do this was part of the Novell Client that was installed on each PC?

 

I'll start poking around with this, but will have to do some serious testing before my boss will let me roll it out!

 

Thanks for everyone looking at this!

[LCPSWolf]

OK there will still be some things to deal with in the remainder, but I think the difficult bit (besides needing to get you head around making subauthentication packages for DCs), is knowing when someone pulled the plug out of the wall instead of logging off gracefully. I'm struggling to see a way of doing that centrally which doesn't involve polling your current list of computers-with-logged-on-users every so often...

 

Maybe I'm missing something, but isn't the checking for logged in users easier than polling everyone?..

 

For example:

 

User1 logs in, (login script fires, creates files, etc). Power dies to PC. User files are still there, effectively leaving him logged in and unable to log into another PC.

 

User1 goes to log in again, different PC. The server, upon seeing that the user is already logged in (supposedly) can poll the PC he was logged in from - if it's on, and he's logged in, deny login. In any other circumstance (PC is off, a different user is now logged in) wipe the files for User1 and let the User1 log in as normal.

 

If it's done this way, there's no need to poll all the logged in users at perodic times, only when users are logging in - if they are already present.

 

Am I missing something with this? ...and the likely harder question: is it easy / doable to poll a PC to get current user login info?

 

Just brainstorming. Thanks for any feedback.

 

(Edit) I think this was the same thing localzuk just said. My fault.

Edited March 22, 2010 by LCPSWolf

[waldronm2000]

We're just this year coming from Novell which had the limiting of logins built it. We miss the ability! As an aside, Do I assume that Novell's abililty to do this was part of the Novell Client that was installed on each PC?

 

No, it's derived from the fact that Novell is a much more clearly-defined client/server environment, as opposed to one that has evolved that way from a more peer-to-peer ancestry. The server environment in Novell is (or at least was when I used to use them) much more separate from the client environment, and better able to keep track of events like user logons centrally.

[cookie_monster]

No, it's derived from the fact that Novell is a much more clearly-defined client/server environment, as opposed to one that has evolved that way from a more peer-to-peer ancestry. The server environment in Novell is (or at least was when I used to use them) much more separate from the client environment, and better able to keep track of events like user logons centrally.

 

 

 

Actually it's an active directory issue related to the multi master model. You could limit user logons in User Manager for Domains in the NT4 days. The NT4 client and server were more tightly integrated the change when moving to AD was massive and some features/abilities were lost however there were big gains managing multiple NT4 domain trusts was a PITA.

Edited March 22, 2010 by cookie_monster

[cookie_monster]

Anyone tried this?

 

Limiting a user's concurrent connections in Windows Server 2003, Windows 2000, and Windows NT 4.0

[LCPSWolf]

Anyone tried this?

 

Limiting a user's concurrent connections in Windows Server 2003, Windows 2000, and Windows NT 4.0

 

And has anyone tried this on 2008? (or 2008 R2, whichever) =)

[waldronm2000]

Actually it's an active directory issue related to the multi master model. You could limit user logons in User Manager for Domains in the NT4 days. The NT4 client and server were more tightly integrated the change when moving to AD was massive and some features/abilities were lost however there were big gains managing multiple NT4 domain trusts was a PITA.

 

Agree totally. Kind of what I meant though I didn't explain it very well! Convergence times between domain controllers mean there is no single definitive point where logon status for a user can be reliable obtained.

[srochford]

User1 logs in, (login script fires, creates files, etc). Power dies to PC. User files are still there, effectively leaving him logged in and unable to log into another PC.

 

User1 goes to log in again, different PC. The server, upon seeing that the user is already logged in (supposedly) can poll the PC he was logged in from - if it's on, and he's logged in, deny login. In any other circumstance (PC is off, a different user is now logged in) wipe the files for User1 and let the User1 log in as normal.

 

 

Relatively easy to query another PC to see who's logged in; only problem is that you need to be an admin on that machine to do it remotely. (Possibly not an admin but you need to be able to connect to WMI and by default I think only admins can do that).

 

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.

[PiqueABoo]

you need to be able to connect to WMI

 

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.

[FAA]

Dear Edugeeks,

 

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 protected] 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,

François Amigorena

CEO

IS Decisions

[MWT]

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

Edited March 7, 2011 by MWT

[TheCrust]

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.

[FAA]

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!

[sukh]

Hi FAA

 

"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.

 

Regards

Sukh