"Brandon McCombs" <n***@none.com> wrote in message
news:4988e219$0$5016$9a6e19ea@unlimited.newshosting.com...
> 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.