UAC versus Administrators

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 custom equivalent).

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, it 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 they are running a “legacy” application!

Why Mapped Drives Do Not Appear

Microsoft has a KnowledgeBase article (937624) that describes some of the problems that UAC introduced (starting with Windows Vista, but also applicable to Windows 7) 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 937624 is how Microsft explains the cause of these problems (in Windows Vista and Windows 7 and Server 2008):

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 is to ensure that the system security policy enabling use of multiple security tokens by UAC is active.  Syscob has available a tools downloads “fix”, in the Registry Fixes section, that will enable this policy (see LinkTokens.reg download).  Applying the LinkTokens.reg 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 (“regedit”), go into the HKEY_LOCAL_MACHINE hive and open the SOFTWARE\
Microsoft\Windows\CurrentVersion\Policies\System 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 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:

  1. Click Start, type regedit in the Start Search box, and then press ENTER.
  2. Locate and then right-click the following registry subkey:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
    Windows\CurrentVersion\Policies\System
  3. Point to New, and then click DWORD Value.
  4. Type EnableLinkedConnections, and then press ENTER.
  5. Right-click EnableLinkedConnections, and then click Modify.
  6. In the Value data box, type 1, and then click OK.
  7. Exit Registry Editor, and then restart the computer.

Should the Database [“server”] drive, which all Syscob applications 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 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, but with the multiple token policy enabled as described above.

KnowledgeBase: http://support.microsoft.com/kb/937624.

UAC vs. Users

Aside from the issue described at left, 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.  This means that disabling UAC is neither easy nor recommended for Windows 7.

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 (often the minimum setting).

Strong Protection

In a similar vein Microsoft provides a Digital Certificate security option called “Strong Protection” which can drive the “SEDI user” to distraction.  When a Digital Certificate is “exported” to a file with “Strong Protection” enabled then any use of that certificate's “Private Key” (e.g. for encrypting/decrypting or signing/verifying Secure EDI [SEDI] traffic) will result in a user confirmation dialog to permit access to the key.

Should the site's Gatekeeper TYPE 3 CA certificate be exported with “Strong Protection” enabled then (after importing that .pfx file into the Export-It Certificate Manager store) every EDN exchanged with Customs ICS will require that the user answer eight [8] confirmation dialogs!  In addition to annoying the user this makes unattended [“auto mode”] operation impossible should such a Digital Certificate be used by SEDI.

Syscob very strongly recommends that, if a site uses Digital Certificates to enable direct EDI exchanges with Customs ICS, the “Strong Protection” feature never be enabled!  That includes avoiding “Strong Protection” if it is offered as an option during the process of downloading the certificate from VeriSign after enrollment.

It should also be taken that Syscob very strongly recommends that the options to “Delete private key after export” or to “Include all certificates in chain” never be selected during export of a Digital Certificate to a file.  And that, once exported to a file, copies of that file (and a record of the password assigned for it during export) be kept in multiple locations.  Should the file, or its password, be “lost” then the Digital Certificate may have to be replaced at a cost over $500.