When the Bio-Medical Library staff first developed Windows 2000 configurations last year, we enabled two local accounts. w2kuser is the account housing user applications and settings. w2kuser was intended to be used mostly in User or Power User mode, to restrict what can be changed, but must become a local Administrator for many software changes to occur.
One of the more time-consuming aspects of maintaining our PCs involves adding w2kuser to the Administrators group before any significant change, and then removing w2kuser from Administrators afterwards. As student worker Haudy describes, there are about 13 steps that not only take time but also are easy to forget.
If we enable the Windows RunAs service and use a simple batch script Haudy developed, we can cut in half the time and trouble of this rights switch. When I first heard of this fix it sounded good, but I told Haudy that we had to look into the security implications of enabled the RunAs service.
The approach is similar in concept to running the “su” command in UNIX. Based on Haudy’s research and what I have seen, I see no good reason not to enable RunAs. It’s a few mouse-clicks per PC to enable, after which Haudy’s script could run from the K: drive. The script requires the Administrator's password - which is not embedded – and the script is based on the common Windows “net” executable, meaning we’re not exposing anything important by making it executable from a public account. No password, no go.
In short, let’s do this ASAP, and thereafter be more diligent about dropping the w2kuser account on public PCs back to User mode after each such change. This should make maintaining security much easier.
The notes below are largely Haudy's from a couple of years ago. Note that most of the Novell-specific stuff is no longer valid for most of our users since we switched in 2004 to Samba file services.
--- Haudy notes ---
Current method to give w2kuser admin level rights in order to make system and software configuration changes, starting from a logged-in w2kuser account:
2.Log out of w2kuser
3.Login as the local Administrator by changing the username on the Novell login screen and entering the local Administrator's password
4.Go to Users and Groups control panel
5.Add w2kuser to Administrators group
6.Logout of the local Administrator account
7.Login as w2kuser (who now has admin level rights)
8.Make necessary configuration changes
9.Apply the novell.reg registry patch that enables auto-logon
10.Apply the w2kpublic.reg registry patch that enables auto-logon
11.Go to Users and Groups control panel
12.Remove w2kuser from Administrators group
13.Reboot, which will auto-logon as w2kuser and auto re-enable WinSelect
Proposed way to give w2kuser admin level rights in order to make system and software configuration changes, starting from a logged-in w2kuser account:
2.Run adminme.bat and enter the local Administrator account password
3.Log out of w2kuser
4.Log in as w2kuser (no username changes on the Novell login screen)
5.Make necessary configuration changes
7.Reboot, which will auto-logon as w2kuser and auto re-enable WinSelect
Streamlines making changes to w2kuser account
Much easier and faster to make changes to w2kuser account
Eliminates problems caused by forgetting to re-apply registry patches after every configuration change
Improves security by making security easier to use
6 fewer steps to go thru; these were time-consuming steps.
RunAs service to be enabled in automatic startup mode.
RunAs security issues:
I found no security issues with RunAs in numerous searches of SANS, Google, or Google Groups. The only thing I found is a general security tip to turn off unneeded services. RunAs is needed to make the batch file adminme.bat work. The SANS Securing Windows 2000 Step-by-Step document considers RunAs to be a service that “need to be running on production systems”.
runas /user:[local Administrator] "net localgroup Administrators %username% /add"
@echo You must logout and log back in again for Admin rights to take effect.
net localgroup Administrators %username% /delete
@echo You must logout and log back in again for removal of Admin
@echo rights to take effect.