B
biragwang
I administer a Win2K/XP domain at work consisting of approximately 200
computers. The majority of the clients are laptops (about 80%). With
the mobile nature of laptops, we needed a way for users to be able to
logon while not on the network. Creating local accounts for each user
on their laptop was an unappealing solution. Not only would we be
forced to maintain all these individual local user accounts, but the
users would also have another layer of complexity added to their lives
as they switched back and forth between local and domain accounts (and
this would mean more helpdesk type calls for us everytime a user
forgot thet they had saved their important file to the desktop of
their local account and not their domain account). The other option
(the one we chose and implemented) was to enable cached logons.
For the most part, cached logons work great. However, I've begun to
rely more heavily upon logon and startup scripts...and here's where
the fun begins. I've noticed that some systems do not seem to apply
our startup and logon scripts (even though I know that they were
brought in that day and attached to the network). It didn't take me
long to discover the source of the problem: system hibernationand
cached logons. It seems that some users will logon at home the night
before, or in the morning (via cached logon), then their system
hibernates and they bring the system into work in a hibernated state
(while still logged on via cached logon!). Into work they go,
attaching their system to the network and bringing it out of
hibernation. The system has full (to my eye) domain access without
having to have authenticated with one of our DCs and without
processing any logon or startup scripts.
Very shortly, this will be against company policy. However, I prefer
(if possible) to prevent this from happening entirely. Failing at
100% prevention, I'd like to easily be able to identify and log when a
users brings their system into work and attaches to the network in a
hibernated/cached logon state. I can't rely upon logon or startup
scripts for this because they won't run if the users
hibernates/caches, then attaches to the network. I am experimenting
with disabling hibernation (via GP if possible) at present. However,
even if I succeed in disabling all hibernation, a system could still
connect to the network while logged on via cached logon (just not
hibernated). So, my first choice would be some method whereby I could
prevent domain access via cached logon, or force local authentication
when actually attached to the network. Failing at this, I'd like to
be able to log when users connect to the network while in a cached
logon state.
Sorry about such a long-winded post. Any ideas are greatly
appreciated!
Steve
computers. The majority of the clients are laptops (about 80%). With
the mobile nature of laptops, we needed a way for users to be able to
logon while not on the network. Creating local accounts for each user
on their laptop was an unappealing solution. Not only would we be
forced to maintain all these individual local user accounts, but the
users would also have another layer of complexity added to their lives
as they switched back and forth between local and domain accounts (and
this would mean more helpdesk type calls for us everytime a user
forgot thet they had saved their important file to the desktop of
their local account and not their domain account). The other option
(the one we chose and implemented) was to enable cached logons.
For the most part, cached logons work great. However, I've begun to
rely more heavily upon logon and startup scripts...and here's where
the fun begins. I've noticed that some systems do not seem to apply
our startup and logon scripts (even though I know that they were
brought in that day and attached to the network). It didn't take me
long to discover the source of the problem: system hibernationand
cached logons. It seems that some users will logon at home the night
before, or in the morning (via cached logon), then their system
hibernates and they bring the system into work in a hibernated state
(while still logged on via cached logon!). Into work they go,
attaching their system to the network and bringing it out of
hibernation. The system has full (to my eye) domain access without
having to have authenticated with one of our DCs and without
processing any logon or startup scripts.
Very shortly, this will be against company policy. However, I prefer
(if possible) to prevent this from happening entirely. Failing at
100% prevention, I'd like to easily be able to identify and log when a
users brings their system into work and attaches to the network in a
hibernated/cached logon state. I can't rely upon logon or startup
scripts for this because they won't run if the users
hibernates/caches, then attaches to the network. I am experimenting
with disabling hibernation (via GP if possible) at present. However,
even if I succeed in disabling all hibernation, a system could still
connect to the network while logged on via cached logon (just not
hibernated). So, my first choice would be some method whereby I could
prevent domain access via cached logon, or force local authentication
when actually attached to the network. Failing at this, I'd like to
be able to log when users connect to the network while in a cached
logon state.
Sorry about such a long-winded post. Any ideas are greatly
appreciated!
Steve