Lock workstation at domain login

[Guest]

Environment:
Windows XP Pro SP1 authenticating to a network domain. The workstation is
located in an area with routine corporate physical security readily available
to other employees. It is not in a physically secured area such as a server
room.

Issue:
The IT department has begun pushing out periodic Automated Updates overnight
which subsequently reboot my workstation. The negative result of this
process is my scheduled tasks, which require my network credentials, fail
because I am no longer logged into the network when the task is scheduled to
run. (I leave my workstation logged in and locked when unattended).

Givens:
1. Tasks will remain on the existing workstation.
(That is where required software is located).

2. Task will continue to use my existing network account credentials.
(Tasks require security access to network resources which require
permissions granted to my network account).

Proposed solution:
I have identified a means to Autologin to the domain after the workstation
is rebooted following the Automated Updates. It requires changes to the
Winlogon registry key. However, the process requires the password to be
stored in the registry in clear text. The obvious downside here is that
other users with sufficient permission can read the password, either locally
or remotely. I believe I can mitigate this exposure by modifying the
permissions on the Winlogon key to restrict access to everyone except my
network account and SYSTEM. Another minor downside is that all future
network account password changes would also have to be made to the registry
key.

A remaining issue is how to lock my workstation immediately after the
machine has rebooted and Autologin has logged into the domain with my network
credentials. I need to identify a means to run a command at startup that
will lock the workstation and can not be circumvented by a user.

I am familiar with the following command that will lock the workstation:
%windir%\System32\rundll32.exe user32,LockWorkStation

However, I need to identify a means to run the command that can not be
bypassed by a user. For example, putting the command in Start
Menu\Programs\Startup is not a feasible option because this startup method
can be skipped

Questions:
Q1. Does anyone see any other security holes in the Autologin portion of the
process I described that I failed to mention?

Q2. Is there a way to run the command to lock the workstation at startup
that a user can not break out of before it runs?

Thank you.

 

[Doug Knox MS-MVP]

TweakUI for Windows XP will enable autologon, and will not store the password in plain text.

 

[Guest]

Doug, I often learn something unrelated to what I was originally researching.
This may be such an occasion. I always thought TweakUI was a user friendly
front-end interface to functions that could also be performed by other means,
such as Regedit, if a user knew how. Is that not the case? Please bear with
me. I’m just trying to understand what it is and what it does before I
install it.

Do you know if TweakUI does something for Autologon that prevents a separate
password from having to be stored other than the actual network password?
That would be the preferred choice. But if that were true, it would make one
wonder why the Autologon option which requires the DefaultPassword registry
entry would ever have been created in the first place.

If TweakUI is just making the registry entries Autologon is expecting, why
would it matter if the entries are made with TweakUI or Regedit? There would
have to be something that prevents those entries from being read.

If TweakUI’s Autologon is something entirely different, where and how is the
password stored? Is it encrypted or merely hidden? How would one change
this password value when network policy requires periodic network account
password changes. Or, are password changes passed through automatically?

I know I’ve asked a lot of questions, but I do appreciate your help, Doug,
and help from anyone else who cares to jump in.

Oh, and BTW, if anyone can help me with the other question about how to
configure a startup command that can’t be bypassed by a user, I would be
grateful.

Thanks.

 

[Doug Knox MS-MVP]

The latest version of TweakUI uses a system API that stores your password in encrypted format, in a different part of the Registry. The original TweakUI used the same method as outlined in various KB articles and other sources, by storing the userame and plaintext password. I'm not sure which version of TweakUI for XP resovled this, and started storing the password correctly, but it does.

If your network requires regular password changes, either method would have to be updated. The passwords are stored (either plain text or encrypted) and called as needed. If the logon password changes, the stored passwords won't match.

As for Startup commands that can't be bypassed........... I know that holding down the left Shift key during logon will bypass things in the Start Menu, Programs, Startup folder, but I don't believe this applies to the Registry vectors (I could be wrong though).

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

is where autorun entries for all users would be placed. HKEY_CURRENT_USER only applies to the current user, so changes would have to be made while they're logged on, or via other methods of editing the user portion of the Reigstry.

 

[Guest]

Thank you very much, Doug. I appreciate that you took the time to provide
such a detailed response to my questions. I will certainly give serious
consideration to using TweakUI. I am the only user for the machine. The
Registry approach sounds like a viable option for locking the workstation at
logon if I do implement some type of autologon option. Thanks again.

 

[Stikeebun]

Hi, sorry if I am stating the obvious, but can't you re-schedule you
tasks for when you ARE logged in? Also, do your IT deptartment kno
you're trying to fiddle like this? I am a Network Admin and woul
appreciate the user actually telling me that a problem has been cause
by these updates. If they are using an Active Directory policy t
schedule SUS surely they could create another OU for your pc an
re-schedule the updates? Aren't you risking disciplinary procedures ?

 

[Guest]

Tasks are scheduled based on dependencies and expected completion times.
They update processes used by other end-users. Even if there was no need for
tasks to be completed by established times, what you suggest has a logical
flaw. The tasks are ALREADY scheduled for when I am logged in. It is the
unexpected reboot that prevents them from running when scheduled. The IT
department is aware of the issue because I notified them and asked them to
provide a solution. I also asked them for feedback on all solutions I have
proposed. Active Desktop is not an issue.