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