There is no question that administrators need to have a user account that will allow them to perform their tasks of taking care of the network and enterprise. There is a question as to whether or not this user account that provides these “Superman” privileges should also be the user account that is used to check email, surf the Web, and perform other routine tasks that a typical employee would perform. When the IT staff only has a single user account for performing their daily “Clark Kent” tasks, as well as their “Superman” tasks, there are too many situations that leave the network, servers, Active Directory, and other essential resources vulnerable.
This article will discuss some of the most common vulnerabilities that are exposed when someone with administrative or other elevated privileges use only one user account for all tasks. Some of these situations might seem abstract or far-fetched, but there is no doubt that someone has taken advantage of some of these exploits at one time or another.
We will also uncover some common solutions for helping track and solve the dilemma of using dual user accounts. No one, even the IT staff, likes to use multiple user accounts. However, in the light of protecting the network, servers, Active Directory, and other resources, it is something that needs to be solved in every environment.
Finally, this article will finish up with some tools that can be used to help utilize dual user accounts for day-to-day tasks. When you are done reading this article you will be well on your way to using dual user accounts for everyone in the IT staff to help protect all resources on the network.
What is the exposure of using a single user account?
If you are like many administrators, you might feel that the exposure of using a single user account for both your “Clark Kent” and “Superman” tasks might not be a problem at all. I have heard more than one time that dual user accounts are a ridiculous idea and that there are no vulnerabilities for a single user account.
I have also heard from many administrators that they are fully aware of the vulnerabilities, but that they are so conscious of the vulnerabilities that it would never be an issue for them. Even though I would like to believe that these administrators are exempt from the Kryptonite that can sabotage their best intentions, there is just no possible way to protect against all potential situations where the use of a single user account is vulnerable.
Although the exposure seems obvious, I will state the obvious to make sure that I am getting my point across. If an administrator logs on to perform a typical, non-administrative task, there is a potential for the account or logon session to be compromised. The time that it takes for an attacker to do damage once they hijack or compromise the account or logon session is negligible. Thus, the fewer times that administrative user accounts are used the better, to reduce the times that an attacker can compromise the account or logon session.
The most obvious vulnerability of an administrator logging in with an account that has administrative privileges is when they forget to lock the computer when they walk away from the computer. I will never forget when I was consulting with a large power company a couple of years ago. The network admin swore to me that he “ALWAYS” locked his computer when he even stepped away from it. I asked “ALWAYS?” He replied with an animate “YES!” It only took me about 7 days of surveillance to catch this network admin’s computer unattended and unlocked. I did not do any damage, but I can tell you that when he returned to his computer, he knew for certain that he had left it unlocked.
Another vulnerable situation is when routine tasks are performed with this “Superman” account. Tasks like submitting emails, surfing the Web, purchasing products off the of the Web, etc. When these tasks are performed a trail is left behind for an attacker to pursue. It is common for users, even administrators, to use similar usernames and passwords for Yahoo mail, Ebay, PayPal, etc. This activity exposes the production network to possible attacks as a trail of information is left behind after mail is checked and items are purchased.
A final exposure is when an administrator is performing routine checks and audits on Active Directory or servers, and errantly makes a “click”, “check”, or other configuration that is only possible by an administrator. These errant mistakes might go unnoticed, which can cause an array of problems over time. It is best to not use an administrative account to perform routine checks, where a standard user account could be used to reduce this exposure to making errant mistakes.
Using Dual accounts
The obvious solution to all of these exposures is to have administrators have two user accounts. One user account will be used for when they log on to their personal computer in the morning. This account will be used for checking e-mail, browsing the Internet, making any Web purchases, writing memos, etc.
The other user account is designed to be the “Superman” account. This account will be used when the administrator needs to perform some superhuman, or at least superuser, task on the network. Creating user accounts, resetting user passwords, configuring Group Policy, and setting permissions on network resources would be some examples of tasks that would fall under this account’s scope.
It is common for this “Superman” account to have some naming convention that makes it easy for the administrator to remember, as well as for the auditors to track. Examples of such a naming convention might be the following:
I have used both of these naming conventions before. The first uses jb, which is short for James Bond. As long as the name is easy to remember and easy to pick out from the audit trail, the job is accomplished.
Making Dual user accounts effective
I must admit that having dual user accounts in a Windows NT environment is not really a great solution. Forcing users to log off from their “Clark Kent” account to perform an administrative task after logging in as their “Superman” account is not very efficient. However, starting with Windows 2000 there is a solution to this problem. The solution is to use the Run As options that are tucked away in the different administrative tools.
Almost every administrative tool has the “Run As” option just a right-click away. Figure 1 illustrates the Run As menu option for the Active Directory Users and Computers administrative tool.
Figure 1: The Run As menu option is available by right-clicking on the tool that you want to access as a different user account
Once you select the Run As menu option, you are presented with a dialog box that allows you to input credentials that differ from those that you initially logged in with, as shown in Figure 2.
Figure 2: The Run As dialog box accepts credentials that differ from those you initially logged in with
Once you finish performing your task in the administrative tool, you only need to close out of the tool. The credentials that you used to launch the tool are not cached. This helps protect the username and password from compromise by an attacker.
If you want to expedite accessing the tool from the Start Menu or from right-clicking on the tool, the Run As option is also supported in a batch file. This allows you to just double click on an icon to prompt you for the password of the user account that is being used for the administrative tool. An example of using an administrative account to launch the Active Directory Users and Computers tool would be the following:
runas /user:bcn\austin-x “mmc %windir%\system32\dsa.msc”
There is no question that the use of a single user account for an administrator is not a good security practice. There are many reasons that an administrator can provide for them not to use dual accounts, but in reality all of the reasons are excuses. The vulnerabilities of using a single user account for administrators far outweigh the benefits. Therefore, it is a great idea to implement dual user accounts for all administrators, developers, helpdesk staff, and anyone else that is responsible for performing elevated privilege tasks on the network. The use of a naming convention can help the administrator remember the dual accounts easily, plus provides an easy way for auditors to ensure that only administrative accounts are being used for administrative tasks when they view the security logs and audit trails. With tools such as the Run As menu option and command, the use of dual accounts is not as cumbersome as it once was, making it a viable solution for every Windows administrator.