Mapped drive visible to all logon sessions unexpectedly.

Today, I will talk about an issue we run into recently.

Background:
After you turn on User Account Control (UAC) in Windows Vista or Windows 7, programs may not be able to access some network locations. This problem may also occur when you use the command prompt to access a network location.  When a member of the Administrators group logs on to a computer running Windows Vista or Windows 7 that has UAC enabled, the user runs as a standard user. When an administrator logs on to a computer running Windows Vista or Windows 7, the Local Security Authority (LSA) creates two access tokens. If LSA is notified that the user is a member of the Administrators group, LSA creates the second logon that has the administrator rights removed (filtered). This filtered access token is used to start the user's desktop. If a user is logged on to a computer running Windows Vista or Windows 7 and if UAC is enabled, a program that uses the user's filtered access token and a program that uses the user's full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs. 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.
To get around this problem, configure the EnableLinkedConnections registry value. This value enables Windows Vista and Windows 7 to share network connections between the filtered access token and the full administrator access token for a member of the Administrators group. After you configure this registry value, LSA checks whether there is another access token that is associated with the current user session if a network resource is mapped to an access token. If LSA determines that there is a linked access token, it adds the network share to the linked location.

Problem:
Sets up server 2012 R2 and adds this registry to make admin users see the mapped drive which are configured by group policy preference. Next normal users are able to see mapped drives for admin users unexpectedly if and only if admin user logs into the box earlier and stays in that session. If admin user logs off the session, normal users won’t be able to see the mapped drive then.

Findings:
Through the live debugging, we’ve found mapped drives were created in \GLOBAL?? Directory of the object manager in the logon session of admin user, hereby the mapped drives are visible across all logon sessions. With further debugging, we’ve nailed down the culprit, kernel redirector driver, which tried to impersonate the admin user in system work thread and failed the impersonation, then ended up creating the mapped drive objects in system account context that will create objects in \GLOBAL?? Directory as a result. But why it only happens with EnableLinkedConnections in place? The reason is EnableLinkedConnections is backed by kernel redirector drivers that are responsible to mapping remote network resource to local resource. While setting up the mapped drive, driver FSD thread would often impersonate the user and associates the current thread with user’s access token. then kernel redirectors will check if EnableLinkedConnections  is on. if yes, driver would often call ZwQueryInformationToken to get the TokenElevationType info pertaining to current token of the running thread first and get the linked token next.  To our curiosity, ZwQueryInformationToken returned TokenElevationTypeDefault type which implies current user token didn't have linked token at all. Keep in mind, admin user will have two access tokens if UAC is turned on. So it contradicts with the theory in the background introduction.

At long last, we managed to figure out the reason of above puzzle. There were two additional UAC configurations along with the registry on the box:
1. “admin approval mode for built-in administrator account”
Enabled: The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
2.  “Turn on Admin Approval Mode”
Disabled: Admin Approval Mode and all related UAC policy settings are disabled.

With above two settings on, it virtually disables UAC function even though it appears to be turned on.  So admin users won’t have two separate tokens and EnableLinkedConnections doesn’t fit into this setup.

Resolution:
Remove EnableLinkedConnections on the server.