- Think Like A Computer - http://www.think-like-a-computer.com -

Login Scripts Fail to Map Network Drives

This only applies to you if UAC  is enabled and users are a member of the local administrators groups.

I was doing some work recently for a client when I noticed that a login script was failing to map network drives if deployed through group policy. The strange thing is that if I ran the script manually it worked. Also, at other sites this same login script works perfectly fine whether it’s run by itself or deployed through group policy. The only difference I could find was that users were local admins at the site where the script fails. When users are local administrators UAC comes into play.

UAC and Login Scripts

A  bit of investigation for UAC, login scripts and local administrators brought me across a Microsoft KB article which describes this behaviour. Here is an extract:

After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations

This problem occurs because User Account Control treats members of the Administrators group as standard users. Therefore, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token.

When a member of the Administrators group logs on to a Windows Vista-based computer that has User Account Control enabled, the user runs as a standard user. Standard users are members of the Users group. If you are a member of the Administrators group and if you want to perform a task that requires a full administrator access token, User Account Control prompts you for approval. For example, you are prompted if you try to edit security policies on the computer. If you click Allow in the User Account Control dialog box, you can then complete the administrative task by using the full administrator access token.

Notice how both these paragraphs say that everything is done using the standard user token and not the administrator token? It even says explicitly that login scripts run using the standard user token. Then further down it says:

When network shares are mapped, they are linked to the current logon session for the current process access token. This means that, if a user uses the command prompt (Cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token.

So basically it is saying that if you run a process using your standard access token and another process as your administrator token they can’t SEE or interact with the other. The article then says that the mapped drives are being done with the standard user access token. The problem I have here is that when I log in as an administrator UAC automatically runs EVERYTHING under my standard user access token therefore I shouldn’t have this problem. This is the whole point of UAC, to run programs/processes with the least privileges. When I open Explorer it runs with my standard user token so I should be able to see the drives because the script also ran as my standard user token. It doesn’t make sense.

Group Policies and UAC

Eventually I came to the conclusion that the script mustn’t be running as the standard user token but instead as the administrator token. If this is the case then the Microsoft article is wrong! Hmm, have I outsmarted Microsoft? Again more investigation was needed first which led me to Deploying Group Policy Using Windows Vista. Here is an excerpt of the important bit:

Group Policy Scripts can fail due to User Account Control

By default, all users logging on to Windows Vista use their full token to process Group Policy and logon scripts. However, they use their limited user token to load the desktop and all subsequent processes. Non-administrative limited and elevated tokens are mostly identical, with regard to privileges and groups.

Ahhh, now I see what is happening! The network drives ARE being mapped with the administrator token as I suspected. Because the scripts are launched through group policies they run using the full admin token. When you load Explorer using your standard user token it can’t see the mapped network drives because these where mapped using the admin token. This means that the Microsoft article is technically correct as it doesn’t mention anything about group policies. Oh well, better luck next time! Still, as most scripts are ran through group policy you would think that Microsoft would at least mention this caveat! This raised another question though.

Why Do Group Policies Run As Administrators?

I had a chat about this with some friends trying to figure out why Microsoft would choose to run group policies by default with your administrator token rather than the standard token. Doesn’t this defeat the whole purpose of UAC? Everything about it is designed to run with the least privileges and only elevate if needed. Furthermore UAC is meant to prompt you when you are elevating processes which of course does not happen using a GPO. Here is my take on it.

This is not official and I have no proof but it is my theory and I’m pretty sure it is the reasoning behind it. If you are an administrator and there are group policies that run when you log in, then chances are high that some of these are specifically related to administrative tasks. Let’s say a group policy launches a login script to modify the registry or edit the hosts file. Maybe the GPO drops some files in the Windows folder. All of these “tasks” would fail if they ran under the standard user token as they actually require to be elevated. Because GPO’s are ran non interactively there is no way to do this. This would mean every GPO that required an elevated prompt would fail. There would be no way around this. The solution was to have all GPO’s run by default with their administrator token. This is why I THINK GPO’s are implemented this way. On a side note I would be interested to hear your thoughts on this in the comments section.

Solutions

We have 3 depending on your requirements: