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.mspx
Facebook
Twitter
Instagram