A.1. Prevent LSA Denial of “Administrators” Rights
One aspect of Windows® security which is seldom considered is that “rights” (privileges and permissions) are established by possession of a “token” object. Users will usually possess several tokens, including one for each security group in which the user has membership. To be able to run “legacy” applications, like Syscob export software, a user will have at least two [2] tokens assigned: one as a user (which is quite limited) and another as a member of the local Administrators group (or equivalent custom group).
User Access Control [UAC] versus “Administrators”
The introduction of the User Access Control [UAC] security subsystem in Windows Vista (and enhanced in Windows 7) was accompanied by new Application Program Interfaces [APIs] which did not exist in earlier versions of Windows®. Microsoft views this as a positive because it “obsoletes” earlier software, generating upgrade revenue, and discourages competitors by forcing the cost of software modifications on them. This tactic also influences software vendors to stop supporting Windows® versions from which Microsoft no longer receives income. For example, any program which interacts with UAC is excluded from running on Windows 2003, Windows XP or earlier Windows versions (because UAC does not exist in them).
The first visible impact of UAC arises from the fact that, unless the new APIs are used, the Local Security Authority [LSA] only checks the “default” Security ID [SID] token for evaluating the “rights” possesed by a user. Since the default is the extremely restricted “user” token (and the “Primary Group SID” defaults to the Domain Users group) this makes user membership in the local Administrators group irrelevant when running a “legacy” application! In simple terms the oxymoronic term “limited administrator” introduced with Windows Vista means “just a simple user possessing no administrative privileges or permissions.”
Why Mapped Drives Do Not Appear
Microsoft has a KnowledgeBase article (KB937624) that describes some of the problems that UAC introduced (starting with Windows Vista, but also applicable to Windows 7, Server 2008 and Server 2011) and which affected even internal Windows® facilities like the Command Prompt window. Here is how Microsoft describes the problem in the KnowledgeBase article:
After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations. This problem may also occur when you use the command prompt to access a network location.
And this excerpt from KnowledgeBase article KB937624 is how Microsft explains the cause of these problems (in Windows Vista and Windows 7 and Server 2008 and Server 2011):
CAUSE
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.
When an administrator logs on to Windows Vista, 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. Applications can use the full administrator access token if the administrator user clicks Allow in a User Account Control dialog box.
If a user is logged on to Windows Vista and if User Account Control 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.
Correcting the Problem
The solution to this “invisible network drive” issue (and the concomitant fact that true “admin” rights are denied to the user without constantly answering dialogs) is to ensure that the system security policy enabling use of multiple security tokens by UAC is active. Syscob has available, in the Tools Repository on the web (in the Registry Fixes section), a “fix” that will enable this policy ( download, 330 bytes). Applying the to the Registry simply automates the manual Microsoft procedure for setting the required security policy in the Registry.
To do this manually simply “run” the Registry Editor (“”), open the key. It should look like this (the critical value is highlighted with pink):
If the EnableLinkedConnections value is zero then it needs to be modified to have the value 0x00000001 (as seen above). If the critical value does not exist (i.e. there is no value named EnableLinkedConnections) in this key then the Microsoft KnowledgeBase article provides these instructions for defining one:
To work around this problem, configure the EnableLinkedConnections registry value. This value enables Windows Vista 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.
To configure the EnableLinkedConnections registry value, follow these steps:
- Click Start, type regedit in the Start Search box, and then press ENTER.
- Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Policies\System - Point to New, and then click DWORD Value.
- Type EnableLinkedConnections, and then press ENTER.
- Right-click EnableLinkedConnections, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Exit Registry Editor, and then restart the computer.
Should the “server” drive, which all Syscob application users
share and which is usually a mapped network drive letter, not appear as a choice
in a Syscob installer (including updaters and the “Icon & Rego”
utility) then the “fix” above needs to be applied. The need for
this “fix” can also be established by running eSecurity
(see eSecurity
Analysis Tool topic) and finding “deny” (rather than
“owner”) as the state for the Administrators group
in the enumeration of security group memberships. The alternative,
totally disabling UAC in Vista, will also work, but that is difficult to do in
Windows 7 (and weakens security significantly). Syscob recommends having UAC
active, with a notification level setting acceptable to the user (usually minimum level),
but with the multiple token policy enabled as described above.
Other UAC Impacts on Syscob Users
Aside from the issue described above, the most common complaint from users about UAC is the frequency of its “confirmation” dialogs. Under Windows Vista this usually led to completely disabling User Access Control (and web links for the procedure are easy to find). This response caused Microsoft to couple UAC more tightly to core security in Windows 7 and subsequent versions. This means that disabling UAC is neither easy nor recommended for Windows 7 or later versions.
However, the problem of too frequent confirmation dialogs “training” a user to simply confirm without taking the time to read, or understand, the message still remains. Syscob recommends that optimum security is provided by a user who has not been anesthetized by continuous “Do you really want to…” dialogs. That means setting UAC to a “notification level” value that is both acceptable to the user and which provides acceptable security (usually the minimum setting).
To adjust the UAC level open the User Accounts applet in Control Panel and then click the Change User Account Control settings link. That will open the window seen above and the slider can be dragged downward to a level which is best suited to the user experience level (usually “Never notify” as seen above for users without technical knowledge of Windows®).
Microsoft KnowledgeBase article: http://support.microsoft.com/kb/937624 (KB937624).