Introduction
As a consultant, I often get strange emails asking for my input on a situation. Often, the situations that I get occur on many networks without a root cause or final solution being implemented. In some instances, there is no solution, rather an understanding of the situation will go a long way. Most recently, I got an email regarding a failed installation of an application. The person emailing me was certain that the computer needed to be reinstalled due to the issues they were having. Yes, this was a corporate environment and I was a little shocked, but I must agree that any incident can be quite complex when not knowing how to break down the situation. With that said, the overall situation was due to the user having multiple credentials in the environment and those multiple credentials having totally different local and network permissions and privileges. After the situation was evaluated, the solution was not anything else but knowing which user account needed to be used for the correct task.
Logging On Initially
When you log on to a computer that has joined an Active Directory domain, you have two (minimum) options. First, you can logon to the domain using a user account that has been configured for you by a domain administrator. This account would be your domain account. Second, you can logon locally, which would be to the computer where the keyboard is attached. Each computer has a local user account database known as the security accounts manager (SAM).
You can see these two options in Figure 1. With Windows 7, the options are not as clear as they used to be. If you press the “How do I log on to another domain?”, the local computer even states (this computer) to give you an idea that you are using a user account stored on the local computer, and not the one stored on a domain controller.
Figure 1: Initial logon to a computer which is joined to an Active Directory domain.
If your computer has not joined an Active Directory domain, at logon there will only be one option. That of course would be to logon to the local computer, using a user account stored in the local SAM. You will not see any options at the logon screen, as you must be logging on locally, which can be seen in Figure 2.
Figure 2: Initial logon to a computer which is not joined to an Active Directory domain.
Accessing Resources and Running Applications with Logged on Credentials
If you choose to logon using a local account you will be receiving an authentication token which has the following information on it:
- Local user name and security identifier (SID)
- Local SAM groups that your user has membership in and their SIDs
- Local computer user rights that the user and groups have been configured for
You can see this authentication token using a tool like Process Explorer, which shows the process token for each process. The authentication token is copied for each process that is run by default. Figure 3 illustrates what the process token for a locally logged on user accessing a local application would look like.
Figure 3: Process token for a locally logged on user.
When you have used this type of logon, the only resources that you will be able to access without using alternate credentials are those that are stored locally on the computer. Since the local users cannot be granted permissions to network resources (those files stored on servers and network storage devices) or privileges on other computers, the scope is limited. When you do try and access a resource not located on the local computer, you will typically get one of two messages. The first would be an access denied message. The second type of message would be that which prompts you for credentials to access the resource. This is an automated prompt which is due to the fact that the token being presented to the resource (server holding the resource) knows that the user and/or groups listed on the token are not listed on the resource access control list (ACL). The second type of message would look like that in Figure 4.
Figure 4: Prompt for alternate credentials when accessing network resources and logged on locally.
Performing a Run As or Connect As Different User
Often, a user will need to use alternate credentials to access a computer resource or network resource. This can be done in a few ways. First, the user can connect to a network resource using a mapped drive. Within the configuration of the mapped drive the user can user alternate credentials. You can see this option in Figure 5.
Figure 5: Mapping a drive using alternate credentials.
Second, you can connect to a resource with alternate credentials, like you saw in the previous section of this article. Figure 5 showed what this would look like and how you are able to put in alternate credentials to access a network resource. This option is very similar to mapping a drive with regard to using the credentials. The difference is that the mapping of a drive will cache the credentials that you are using and use them without prompting you.
A third option is to perform a RunAs. A RunAs is the ability to run an application or similar computer utility with alternate credentials. You can see the RunAs dialog box shown in Figure 6.
Figure 6: Performing an action using the RunAs feature.
Accessing Resources as a Different User
Once you have established a connection to a resource or running an application with alternate credentials the computer must keep track of all actions performed by each “logged on user”, based on the actions that are performed in the scope of the connection. For example, if the user runs an application as a different user, only the actions performed from that action use the alternate credentials. You can see the credentials of an application being run using alternate credentials from the mapped drive in Figure 7.
Figure 7: Process Explorer showing alternate credentials via mapped drive.
This might sound like a great idea, and in many cases it is necessary. However, if the user tries to install an application from the mapped drive, using the alternate credentials, issues might occur. If the alternate credential user does not have the correct permissions and privileges to the local computer, the installation might fail. Although the initial logon was done with a local account and the local account has local administrative privileges, the alternate credentials don’t have anything locally but standard user privileges. Due to this lack of privilege, the installation might fail.
Other consequences might occur from using alternate credentials as well. Often shortcuts, saved files and anything else done inside of the user profile will become complicated. The user profile will be per user logged on, which in the cases we are looking at are two different users. For example, a shortcut placed on the desktop for the alternate credential user will not be available for the locally logged on user.
Summary
Using alternate credentials is important and something that occurs on a corporate network every day. However, due to the ways the computer must deal with each token of user information, strange behavior might occur. This might be applications failing to run, files being misplaced during save, or failure to access resources correctly without using the alternate credentials. In any case, being able to understand the logged on environment, tracking the tokens, and knowing the level of access of each logged on user will help you solve and understand each problem.
