PKI credential roaming lets users access their private keys and certificates from any workstation in the Windows domain
Credential roaming, a new feature in Windows Server 2003 Service Pack 1 (SP1), enables Windows domain users to access their public key infrastructure (PKI) private keys and certificates from any workstation they log on to in the Windows domain. Their credentials can roam with them thanks to the Digital Identity Management Service (DIMS), which stores a secured copy of a user's PKI credentials in the user's Active Directory (AD) object and keeps them in sync with the local PKI credentials stored in the user's certificate and private key store on the workstation.
This article explains how DIMS credential roaming works, how it compares with other Microsoft PKI credential roaming solutions, how to configure it, and how to use it to best advantage in Windows domain environments.
Credential Roaming, Roaming Profiles, and Smart Cards
An important characteristic of DIMS and credential roaming is that they enable Windows domain users to have access to their PKI credentials from any domain machine without the overhead of configuring, using, and maintaining roaming user profiles or smart cards.
Roaming user profiles include not only a user's private keys and certificates but also his or her desktop data, application settings, My Documents data, Microsoft Internet Explorer (IE) cache, and so on. That's why they negatively impact user logon time, bandwidth usage, and server-side storage.
Smart cards offer a more secure private key and certificate roaming solution than credential roaming but bring significant deployment and maintenance costs and require disciplined and security-aware users. The same is true for Trusted Platform Modules (TPMs), which are special security chips that are part of a PC's motherboard and that offer smart card-like functionality. Table 1 compares the features of credential roaming, roaming profiles, and smart cards for dealing with PKI credentials in a Windows environment.
On the downside, setting up credential roaming is slightly more challenging than setting up roaming profiles or smart cards in a Windows environment, as you'll see in a moment. An even greater problem is that Windows client OSs currently don't support DIMS, although Microsoft says Windows Vista will.
An example that clearly shows the benefits of credential roaming is the use of the Encrypting File System (EFS) in a domain environment by users who don't have roaming profiles configured. With credential roaming, users have one EFS certificate and private key available on all domain workstations they log on to. Without credential roaming or roaming profiles, EFS would generate a new user certificate and private key the first time a user used EFS on a different machine.
Credential Roaming Operation
Credential roaming is currently supported only on Windows 2003 SP1. As I mentioned above, Microsoft is planning to add DIMS support in the next Microsoft client platform version called Windows Vista. On the server side, credential roaming works with an AD that includes the credential roaming schema extensions and that runs on a Windows 2000 SP3 or Windows 2003 or later platform.
Credential roaming currently supports the roaming only of X.509 certificates and Digital Signature Algorithm (DSA) or RSA key pairs that use the built-in Windows Cryptographic Service Providers (CSPs).
Because credential roaming stores a complete copy of a user's PKI credentials in AD, users will automatically-receive the complete PKI credential set the first time they log on to the domain after a hardware or software failure has occurred on their workstation. Even though credential roaming provides a recovery mechanism to protect users from losing all their private keys and certificates, it doesn't protect against accidental user deletion of individual private keys. The Windows 2003 PKI includes a special service that's integrated with the Certification Authority (CA) to provide backup and recovery services for individual private keys. When a user deletes a private key in his or her local store from the Microsoft Management Console (MMC) Certificates snap-in, credential roaming will also reflect this deletion in the user's AD object.
Here's the sequence of events that takes place when credential roaming kicks in during a user logon from a domain-joined workstation:
1. As part of the logon process, Group Policy Object (GPO) settings— including credential roaming settings that have been enabled in the GPO user configuration—are applied.
2. The client-side dimsntfy.dll compares the certificates and private keys stored in the user's local store to those stored in the user's AD object. If there are content differences, dimsroam.dll updates the local or AD store accordingly:
- If the user's local store contains certificates and private keys and the user's AD object doesn't, the certificates and private keys are copied to AD. This occurs when credential roaming is used for the first time.
- If the user's AD object contains certificates and private keys and the local store doesn't, the certificates and private keys are copied to the local store. This occurs when credential roaming is enabled and the user logs on to another workstation.
- If both the local store and the AD user object contain certificates and private keys and the ones in AD are more up-to-date, the AD-based certificates and private keys are copied to the local store. If the ones in the local store are more up-to-date, the local certificates and private keys are copied to the AD store. If the content of both stores is identical, no further DIMS action is taken.
- The updating of PKI credentials in a user's AD object also applies to deleted certificates and private keys. If a user deleted a private key in his or her local store, credential roaming will also delete the key in the user's AD object.
3. The certificate autoenrollment process (pautoenroll.dll) automatically enrolls the user for the certificates configured in the GPO and for certificate template settings. When the user is successfully enrolled for the certificate, DIMS kicks in again to synchronize the new certificate in the local store with the AD-based DIMS store.
Credential roaming isn't invoked only at user domain logon but each time one of the following events occurs:
- A user manually enrolls for a certificate by using the MMC Certificates snap-in, the CA Web interface, or the certreq.exe command line utility.
- A user is automatically enrolled for a certificate following a Windows certificate autoenrollment event.
- A user imports a new certificate into the local certificate store.
- A user exports or deletes a certificate from the local certificate store.
- A user unlocks a password protected Windows screensaver.
- GPO settings are refreshed on a user's workstation.
Microsoft leverages the Kerberos protocol and LDAP over SSL (LDAPs)—two key Windows AD security technologies—to both sign and encrypt the DIMS credential data exchanged between the Windows client and the domain controllers (DCs).
Credential roaming isn't enabled by default on a Windows 2003 or Win2K SP3 or later AD installation. It requires the following configuration steps, which I'll explain in more detail in the following sections:
Step 1: Extend the AD schema to include the DIMS-specific user object attributes.
Step 2: Change permissions on AD user objects to protect the AD-based PKI credentials against unauthorized access.
Step 3: In environments that also use roaming profiles, exclude DIMSrelated file system folders from roaming profile configuration.
Step 4: Configure the client-side DIMS parameters and enforce these parameters through GPO settings.
Step 1: Extend the AD Schema
DIMS requires three new AD user object attributes to securely store a user's PKI credentials and allow them to roam:
- msPKIDPAPIMasterKeys—This multivalue AD user object attribute is used to store master key files. Master key files contain secured copies of Windows master keys (i.e., cryptographic keys used to secure other Windows data and secrets, including private keys). Master keys are an important element of the Windows Data Protection API (DPAPI—Windows' internal architecture for securing access to data and secrets). DIMS requires copies of the master keys because it uses them to encrypt the private keys stored in the AD user objects (more specifically, in the msPKIAccountCredentials attribute described below). More information about DPAPI and the important role of master keys is available in the Microsoft article "How to troubleshoot the Data Protection API (DPAPI)," http://support.microsoft.com/?kbid=309408.
- msPKIAccountCredentials—This multivalue AD user object attribute is used to store binary blobs of encrypted PKI credentials, including private keys and certificates. The PKI credentials are encrypted by using the master keys stored in the msPKIDPAPIMasterKeys attribute.
- msPKIRoamingTimeStamp—This AD user object attribute is used by DIMS to record the time of the last change to the PKI credentials stored in the AD user object.
These three new user attributes aren't replicated to Global Catalog (GC) DCs and are thus replicated only between DCs in the same domain.
To extend the AD schema and include the above user object attributes, you can use the Ldifde script dimsroam.ldf, which you can find at http://www.microsoft.com/technet/ prodtechnol/windowsserver2003/library/ServerHelp/2e157a02-d786-48f4-9bf2-21359223727d.mspx.Ldifde also creates a new AD property set called private information that includes the three DIMS-specific user object attributes described above. The script marks the three DIMS-specific AD attributes as confidential: It sets the AD confidentiality bit in the attributes' searchFlags property. The confidentiality bit is a new feature Microsoft introduced in Windows 2003 SP1 to hide sensitive AD attributes and their content from users. When the confidentiality bit is set for an AD attribute, even users that have read permission to the attribute can't view the attribute's content. This is a very handy feature when you consider the importance of the DIMS data stored in AD (remember the master key files).
You can follow these steps to extend your AD schema to include the DIMS-specific attributes:
1. Make sure that you have AD schema change permission. By default, only the members of the Schema Administrators group have this permission.
2. Make sure that you've identified the correct Windows DC for extending the AD schema. The AD schema can be extended only on the DC that has the schema master operations master role. To identify the correct DC, you can use the MMC AD Schema snap-in or the ntdsutil.exe command line utility.
3. For a Win2K machine, make sure that you've allowed schema changes on the schema master operations master DC. Schema changes are allowed only if the HKEY_LOCAL_ MACHINE€System€CurrentControl-Set€Services€NTDS€Parameters€Schema Update Allowed registry subkey is set to a value of 1 on the schema master. This step isn't required on a Windows 2003 machine.
4. Copy the dimsroam.ldf script into Notepad, be sure to save it in a file with the .ldf extension, and replace all occurrences of DC=x in the file with the actual DC= name of your AD configuration naming context. You can check the exact name by connecting to the naming context from the MMC ADSIEdit snap-in.
5. Run the following Ldifde command from the command line to extend your AD schema:
Ldifde -i -f dimsroam.ldfWhen the AD schema is extended successfully, Ldifde generates a report similar to the one shown in Figure 1. Also, the DIMS attributes should show up on each AD user object. To check this, you can use ADSIEdit, as Figure 2 shows.
Step 2: Change the Default Permissions on AD User Objects
By default, users have read permission to all the attributes of their AD user object because the well-known security principal named self is granted the Read All Properties permission on a user object. Users don't have read access to attributes that are marked as confidential, such as the three DIMS-specific attributes (as explained in step 1). Confidential attributes can always be read by administrators but can't be accessed by users, even if the users are intentionally or accidentally granted general read access to an AD object or container. Users can read confidential attributes only if they're given an explicit permission on the confidential attribute: the control_access permission. So to make credential roaming work, we must give users the permission to read and write the three DIMS-specific attributes on their proper AD user objects.
I recommend that you grant the control_access permission for the private information property set (which contains the three DIMS-specific attributes) to the self security principal on the organizational unit (OU) object that contains all users that must be DIMS-enabled. Granting the control_access permission can't currently be done from the standard Windows-ACL editor. You must use scriptingor the new ldp.exe tool that comes with the AD Application Mode (ADAM) version included in Windows 2003 R2.
In the DIMS example, to grant control_access permission for the private information to self by using ldp.exe, you must enter the following information and select the following options in the LDP ACE - Access Control Entry dialog box (as shown in Figure 3): Trustee: nt authority€self ACE type: Allow Access mask: Read property, Write property, Control access ACE flags: Inherit Object type: Private Information --propset Inherited object type: user
Step 3: Exclude DIMS-Related File System Folders from Roaming Profile Configuration
Microsoft recommends that you use roaming profiles or credential roaming (not both) because the technologies could overwrite each other's PKI credentials, leaving the user with an outdated version of their PKI credentials. Organizations that want to use both technologies should add the file system folders that are used by DIMS to the roaming profile exclusion list. To do so, go to the Default Domain Policy\User Configuration\Administrative Templates\System/User Profiles\Exclude directories from roaming profile setting in the MMC Group Policy Object snapin, (shown in Figure 4) and add the DIMS-specific file system folders listed in Figure 5 to the exclusion list.
Step 4: Configure Client-Side DIMS Settings and Enforce Them Through GPOs
You can use GPOs to enforce the DIMS client-side configuration, including enabling/disabling credential roaming for a particular user account. The DIMS configuration administrative template is available at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/serverhelp/9b3dfb50-f815-472b-9825-008f42b702f1.mspx. On this Web page, you must copy the template content to Notepad and save it as, for example, dims.adm. You can then load the DIMS administrative template into the appropriate GPO by right-clicking the Default Domain Policy€User Configuration€Administrative Templates container in the Group Policy Object snap-in and selecting Add/Remove Templates.
After the DIMS administrative template is loaded successfully, you'll see a Digital ID Management Service container in the Default Domain Policy\User Configuration\Administrative Templates container (as shown in Figure 6). The Explain tab of the X.509 certificate and key roaming setting's Properties dialog box provides more information about the meaning and effect of the template's DIMS-related GPO settings.
Setting up credential roaming can be challenging, as described in this article. Credential roaming isn't a fit for organizations that want the best security solution for storing their PKI credentials. Smart cards or TPMs are a far better alternative in that case. A final, important potential deployment stopper for credential roaming at the time of this writing is the lack of Windows client OS support for DIMS. But this situation will change when Microsoft releases Windows Vista. When it does, credential roaming will be a good solution for organizations that want their users to have access to the same PKI credentials each time they log on to the Windows domain and that don't want all the overhead linked to either deploying smart cards or maintaining roaming user profiles.