Sign in with
Sign up | Sign in
Your question

Multiple Login

Last response: in Windows XP
Share
Anonymous
March 10, 2005 1:57:04 PM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

I have a simple question and one that Ishould know the answer to. Does
anyone know how to block users from logging into multiple machines at the
same time? I have Windows XP Pro clients and Windows 2000 servers in an
active directory environment.

More about : multiple login

Anonymous
March 10, 2005 11:24:00 PM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Mike Hartman wrote:

> I have a simple question and one that Ishould know the answer to. Does
> anyone know how to block users from logging into multiple machines at the
> same time? I have Windows XP Pro clients and Windows 2000 servers in an
> active directory environment.
Hi

Nothing builtin that can help you here I'm afraid (but I think
Microsoft is going to release something this year that supports this).


The UserLock product in the link below is an option
http://www.softwareshelf.com/products/display.asp?p=42

Microsoft's current solution:

You could install the CCONNECT Microsoft Resource Kit utility onto every
computer, it is in the Win2k Server Resource Kit, Supplement 1 (pay ware, and
you will need a SQL server database as well).

More about CCONNECT here:
http://groups.google.co.uk/groups?selm=3F5CE888.8A3EE8D...


Coming from Microsoft is a product called LimitLogin (still in beta):
http://bink.nu/?ArticleID=1452


Here is a third option you may get to work:

Tip 296 at http://www.jsiinc.com/

0296 » A better way to prevent a user from logging on more than once.
http://www.jsiinc.com/SUBA/tip0200/rh0296.htm


--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.m...
Anonymous
March 11, 2005 3:07:40 AM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

"Torgeir Bakken (MVP)" wrote:

> Mike Hartman wrote:
>
> > I have a simple question and one that Ishould know the answer to. Does
> > anyone know how to block users from logging into multiple machines at the
> > same time? I have Windows XP Pro clients and Windows 2000 servers in an
> > active directory environment.
> Hi
>
> Nothing builtin that can help you here I'm afraid (but I think
> Microsoft is going to release something this year that supports this).
>
> The UserLock product in the link below is an option
> http://www.softwareshelf.com/products/display.asp?p=42
>
> Microsoft's current solution:
>
> You could install the CCONNECT Microsoft Resource Kit utility onto every
> computer, it is in the Win2k Server Resource Kit, Supplement 1 (pay ware, and
> you will need a SQL server database as well).
>
> More about CCONNECT here:
> http://groups.google.co.uk/groups?selm=3F5CE888.8A3EE8D...
>
> Coming from Microsoft is a product called LimitLogin (still in beta):
> http://bink.nu/?ArticleID=1452
>
> Here is a third option you may get to work:
>
> Tip 296 at http://www.jsiinc.com/
>
> 0296 » A better way to prevent a user from logging on more than once.
> http://www.jsiinc.com/SUBA/tip0200/rh0296.htm
>
> --
> torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
> Administration scripting examples and an ONLINE version of
> the 1328 page Scripting Guide:
> http://www.microsoft.com/technet/scriptcenter/default.m...

Instead of the current "solutions" which require database installations I simply
added an integer attribute to the Active Directory schema with a minimum value of
0 and then edited the user object class to have the new attribute as optional.

I created a logon and logoff script that will either increment or decrement this
value to keep track of logons. The logon script will increment the value to 1 if
it is 0 and if it is 1 it will increment to 2, pop up a dialog alerting the user
to what is hapening (if they are already logged in somewhjere else) and when the
user clicks OK the script utilizes the WMI shutdown ability to log the user off
w/o them being able to do anything. The logoff script simply decrements the
integer (not necessarily to a 0). When a group policy is in place that makes
scripts run synchronously the Desktop and icons will not show up because the user
is immediately logged off. The scripts are put into 2 separate group policies,
one as a login and the other as a logoff script. It works quite nicely
considering it's a free solution. The scripts are heavily optimized by grabbing
the windows environment variable containing the username and using that as a
search filter in the LDAP query. That way there is only one result returned from
the ADS query and I don't have to have a loop setup. The workstation environment
variable was also grabbed in order to use it as an argument to the function that
logs the user off the workstation using WMI.

Further details:
I then modified the security permissions of the OUs the users are located in and
added the SELF user principal name. I clicked Advanced on the permissions window
so I could get more granular control of permissions. I selected the SELF entry
and clicked Edit. I then clickd on the Properties tab and chose User Objects in
the Apply Onto dropdown box. Then I gave Allow access to "Write
<newattributename>". Basically, this gives regular users the correct permission
to write a value to the new attribute but it only allows them to write to their
own w/o having to specify each user explicitly because I used the SELF user
principal name.

For users who got created before the new attribute was part of the user object
class I simply made a script that grabbed all the users in the OUs that I had
added and set their attribute value to a 0 to basically initialize it. For users
who haven't been created yet the attribute is initialized by how the logon script
first sets it.

If this is a bit confusing feel free to email me with questions.

Brandon
Related resources
Anonymous
March 11, 2005 4:41:28 AM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Brandon McCombs wrote:

> Instead of the current "solutions" which require database
> installations I simply added an integer attribute to the Active
> Directory schema with a minimum value of 0 and then edited the
> user object class to have the new attribute as optional.
>
> I created a logon and logoff script that will either increment or
> decrement this value to keep track of logons. The logon script
> will increment the value to 1 if it is 0 and if it is 1 it will
> increment to 2, pop up a dialog alerting the user to what is
> hapening (if they are already logged in somewhjere else) and when
> the user clicks OK the script utilizes the WMI shutdown ability to
> log the user off w/o them being able to do anything. The logoff
> script simply decrements the integer (not necessarily to a 0).

I see one problem here, and that is when the user is "thrown" off the
computer without running the logoff script that is supposed to
decrement the value.

If the computer is "brutally" powered off by the user or by a power
glitch, or for some reason the OS crashes or hangs so a reboot without
logoff must be done, the user will not be able to log on again without
contacting support personnel. If this happens in the evening or in the
weekend, and no support personnel is available, you will have a pretty
angry user on your hands I think.


> The scripts are heavily optimized by grabbing the windows
> environment variable containing the username and using that as a
> search filter in the LDAP query. That way there is only one result
> returned from the ADS query and I don't have to have a loop setup.

On Win2k/WinXP/Win2k3 computers, you don't need to do a LDAP query at
all.

For current user, you can use the ADSystemInfo object to obtain the
distinguished name of the user directly:

'--------------------8<----------------------
Set oADSystemInfo = CreateObject("ADSystemInfo")

Wscript.Echo "User's distinguished name: " & oADSystemInfo.UserName

' get AD user object
Set oADsUser = GetObject("LDAP://" & oADSystemInfo.UserName)

' get full name of the current user
sDisplayName = oADsUser.DisplayName
Wscript.Echo "User's display name: " & sDisplayName

'--------------------8<----------------------




--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.m...
Anonymous
March 11, 2005 4:41:29 AM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

"Torgeir Bakken (MVP)" wrote:

> Brandon McCombs wrote:
>
> > Instead of the current "solutions" which require database
> > installations I simply added an integer attribute to the Active
> > Directory schema with a minimum value of 0 and then edited the
> > user object class to have the new attribute as optional.
> >
> > I created a logon and logoff script that will either increment or
> > decrement this value to keep track of logons. The logon script
> > will increment the value to 1 if it is 0 and if it is 1 it will
> > increment to 2, pop up a dialog alerting the user to what is
> > hapening (if they are already logged in somewhjere else) and when
> > the user clicks OK the script utilizes the WMI shutdown ability to
> > log the user off w/o them being able to do anything. The logoff
> > script simply decrements the integer (not necessarily to a 0).
>
> I see one problem here, and that is when the user is "thrown" off the
> computer without running the logoff script that is supposed to
> decrement the value.
>
> If the computer is "brutally" powered off by the user or by a power
> glitch, or for some reason the OS crashes or hangs so a reboot without
> logoff must be done, the user will not be able to log on again without
> contacting support personnel. If this happens in the evening or in the
> weekend, and no support personnel is available, you will have a pretty
> angry user on your hands I think.
>

Yes, we've already had a couple users with that problem. I don't recall
the situation but I think they had to power the machine off b/c an app
froze or something and the flag still stuck around. How would any other
method get around this problem? A service running in the background isn't
able to sense when the machine goes offline so it can't exactly tell the
server you aren't going to be logged in anymore when the machine is
powered off. Do other methods check at login time for something?

The system runs in a 17x7 environment where support personnel are
available 24x7 environment who service calls for multiple systems in the
same building and they will always be available to handle locked accounts,
logged in accounts, and to reset passwords if needed. The system is a
gov't system so people are always around at the help desk.

It was the best solution considering the lack of good alternatives.
Thanks for the tip below too.

>
> > The scripts are heavily optimized by grabbing the windows
> > environment variable containing the username and using that as a
> > search filter in the LDAP query. That way there is only one result
> > returned from the ADS query and I don't have to have a loop setup.
>
> On Win2k/WinXP/Win2k3 computers, you don't need to do a LDAP query at
> all.
>
> For current user, you can use the ADSystemInfo object to obtain the
> distinguished name of the user directly:
>
> '--------------------8<----------------------
> Set oADSystemInfo = CreateObject("ADSystemInfo")
>
> Wscript.Echo "User's distinguished name: " & oADSystemInfo.UserName
>
> ' get AD user object
> Set oADsUser = GetObject("LDAP://" & oADSystemInfo.UserName)
>
> ' get full name of the current user
> sDisplayName = oADsUser.DisplayName
> Wscript.Echo "User's display name: " & sDisplayName
>
> '--------------------8<----------------------
>
> --
> torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
> Administration scripting examples and an ONLINE version of
> the 1328 page Scripting Guide:
> http://www.microsoft.com/technet/scriptcenter/default.m...
Anonymous
March 11, 2005 5:38:36 AM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Brandon McCombs wrote:

> "Torgeir Bakken (MVP)" wrote:
>
>>I see one problem here, and that is when the user is "thrown" off the
>>computer without running the logoff script that is supposed to
>>decrement the value.
>>
>>If the computer is "brutally" powered off by the user or by a power
>>glitch, or for some reason the OS crashes or hangs so a reboot without
>>logoff must be done, the user will not be able to log on again without
>>contacting support personnel. If this happens in the evening or in the
>>weekend, and no support personnel is available, you will have a pretty
>>angry user on your hands I think.
>
>
> Yes, we've already had a couple users with that problem. I don't recall
> the situation but I think they had to power the machine off b/c an app
> froze or something and the flag still stuck around. How would any other
> method get around this problem? A service running in the background isn't
> able to sense when the machine goes offline so it can't exactly tell the
> server you aren't going to be logged in anymore when the machine is
> powered off. Do other methods check at login time for something?
Hi

The UserLock product and Microsoft's CCONNECT use a central database,
so as long as you log on to the same computer that was "brutally"
rebooted/powered off, the system sees that it was the same computer
you already was logged on to previously and it will not increment
the the count.

For your solution, you could actually implement the same concept, by
in addition to the count attribute having a "LastUsedComputer"
attribute (or use an already existing attribute). When the logon
script sees that the current logon is done from the same computer
found in "LastUsedComputer", just log on the user without reading/
writing the count attribute. If not the same computer, do the count
attribute logic as usual, and update the "LastUsedComputer" attribute
as well.


--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.m...
Anonymous
March 14, 2005 7:22:45 AM

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

"Torgeir Bakken (MVP)" wrote:

> Brandon McCombs wrote:
>
> > "Torgeir Bakken (MVP)" wrote:
> >
> >>I see one problem here, and that is when the user is "thrown" off the
> >>computer without running the logoff script that is supposed to
> >>decrement the value.
> >>
> >>If the computer is "brutally" powered off by the user or by a power
> >>glitch, or for some reason the OS crashes or hangs so a reboot without
> >>logoff must be done, the user will not be able to log on again without
> >>contacting support personnel. If this happens in the evening or in the
> >>weekend, and no support personnel is available, you will have a pretty
> >>angry user on your hands I think.
> >
> >
> > Yes, we've already had a couple users with that problem. I don't recall
> > the situation but I think they had to power the machine off b/c an app
> > froze or something and the flag still stuck around. How would any other
> > method get around this problem? A service running in the background isn't
> > able to sense when the machine goes offline so it can't exactly tell the
> > server you aren't going to be logged in anymore when the machine is
> > powered off. Do other methods check at login time for something?
> Hi
>
> The UserLock product and Microsoft's CCONNECT use a central database,
> so as long as you log on to the same computer that was "brutally"
> rebooted/powered off, the system sees that it was the same computer
> you already was logged on to previously and it will not increment
> the the count.
>
> For your solution, you could actually implement the same concept, by
> in addition to the count attribute having a "LastUsedComputer"
> attribute (or use an already existing attribute). When the logon
> script sees that the current logon is done from the same computer
> found in "LastUsedComputer", just log on the user without reading/
> writing the count attribute. If not the same computer, do the count
> attribute logic as usual, and update the "LastUsedComputer" attribute
> as well.

good idea. thanks for the tip. I'll try this.
!