Re: Windows 2008 Limitlogin



Brandon,
Are you saying you are one of the authors of LimitLogon?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.


"Brandon McCombs" <none@xxxxxxxx> wrote in message news:4988e219$0$5016$9a6e19ea@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Budi wrote:
Dear Expert

We are using windows 2008 64 bit Enterprise, we are trying to limit concurrent user login using limit login but unfortunetely always fail.
my question is straight simple, is it possible to use limit login on windows 2008 64 bit Domain, if so please advice how to complete the task.
need your respon asap, my bos is always asking me

Thanks in advance
Budi

Budi, back in July of 2008 I wrote the following to someone:

I'm one of the people that Paul was referring to who has written a script [whether he specifically knew of me doing this or not] to control concurrent sessions. It actually consists of a logon script which checks for an existing logon and logs the user off if one is detected. The logoff script updates the same attribute. Both scripts manipulate a custom attribute which stores a space delimited list of hostnames matching machines to which a user has logged on.

It currently prevents regular users from logging in more than once by first warning them of where their other session exists (hostname) and then uses WMI to log the user off forcefully (which is fine since the user doesn't get to do anything). The scripts are set to run synchronously so the users can't do anything but click the OK in the mesg window and then the logoff process starts. This only works for Windows XP. For admins who log in to Windows Server, a separate (3rd) perl script that ties into a 3rd party perl module must be used because for some reason WMI on Server is ignored. However at work we just *warn* admins they have a concurrent session since they like having that ability.

Note that multiple, quick concurrent logons may still be be possible depending on which ADS server logs a user on, and the speed at which the attribute data is replicated across ADS servers so that they are all aware of the current session status for any given account. If you login quick enough you can probably beat the replication time and get in another session if you happen to log on to another server that hasn't been told about your first session. This can also screw with updating the attribute correctly during log off and may require you to manually reset the attribute value every so often but I've found it much better than other solutions (especially since it *does* work).

Also, users must be given explicit privilege to update this new attribute during logoff using the SELF UPN, otherwise the script just doesn't work properly. It must also be initialized (added to the directory cache) after being added to the schema in order to even see it listed in the attribute list to specify it in ACLs. I created a utility script which inits the attribute to 'NULL' for all users, then I can give them permission to modify it using ADSIEdit.


------------

The above was regarding scripts I wrote for Windows Server 2003 R2 Enterprise Edition 32-bit. As long as VBS works for 64-bit Windows then you should be able to use them or write your own to do the same.

.