Problem solve Get help with specific problems with your technologies, process and projects.

Using batch files for temporary user access to the local admin group

When a program that many users need to access requires local admin rights to run, what's the best way to manage user privileges? IAM expert Joel Dubin weighs in on how best to manage user accounts.

Users on my network need to run an application that requires local admin rights. For security purposes, we prefer...

not to provide users with local admin rights. Would you recommend trying to write a batch file to add each user to the local admin group when he or she clicks the program's desktop? This privilege level would only last until the user exits the program.

Local administrator rights should not be provided to users. This is one of the easiest steps to take to protect workstations and desktops from malware, which often, but not always, require administrator privileges to run.

On the other hand, a lot of legitimate Windows software requires administrator privileges to run properly. Locking down local administrator rights may also prevent users from working with some of their routine applications.

The idea of using a batch script to add users temporarily to the local administrator group is a good one. In fact, Windows "runas" can be added to allow users to temporarily elevate their privileges to an administrator level.

The intricacies of scripting are beyond the scope of this brief answer, but there are still a few caveats at a high-level to keep in mind for securing batch scripts using "runas."

First, "runas" isn't as finely tuned as its Linux counterpart, "sudo." Unlike "sudo," which can provide granular access to single applications, a user running as an administrator under "runas" has complete access to the system during his or her session. Organizations should closely monitor which users are allowed to use "runas," and take advantage of its various switches by tuning it as much as possible.

Second, make sure the script only adds local accounts and not domain accounts that could grant access to not only the individual and workstation, but the entire domain.

Third, scripts should only run when the user clicks on the application's desktop icon. It's not a good idea to have the script run at startup, a common practice for logon scripts. This will defeat the purpose of blocking local administrator rights by granting administrator access to the user only during their session. Conversely, also make sure the script turns off the user's temporary access at the end of the session. Better yet, include code in the script to extinguish the session when the user exits the application.

Finally, make sure scripts are located in directories inaccessible to ordinary users. Otherwise the scripts can be manipulated to escalate privileges and provide inappropriate access for malicious users.

More information:

  • Learn how to manage user IDs to avoid root-password sharing.
  • Explore enterprise policy management options with this advice.
This was last published in August 2008

Dig Deeper on Privileged access management