Roam, Roam in the 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:

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:

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:

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:

Ldifde -i -f dimsroam.ldf 

When 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 PolicyUser ConfigurationAdministrative TemplatesSystem/User ProfilesExclude 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 PolicyUser ConfigurationAdministrative 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.

Roaming Readiness
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.