Windows: Credential Roaming
Note
This document is being updated for Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
Applies to
Windows Server 2003 SP1, Windows Server 2003 R2, Windows XP SP2, Windows Server 2008, Windows Vista
Credential roaming does not apply to Windows RT devices
Implementation Differences
The client part of credential roaming was first introduced as a core part of Windows Server 2003 SP1. A user who logs on to a computer that has at least Windows Server 2003 SP1 installed can immediately benefit from the credential roaming features as soon as the related Group Policy has been enabled.
Windows Server 2003 R2 requires Windows Server 2003 SP1 to be available on a computer so that the credential roaming experience in Windows Server 2003 R2 is the same as in Windows Server 2003 SP1. Windows Server 2003 R2 is a feature extension of Windows that contains no changes that are specific to credential roaming.
Since credential roaming is not part of Windows XP SP2, the feature is available as a separate software update that can be deployed in Windows XP SP2 computers.
To make the credential roaming experience similar among all Windows versions, a software update is also provided for Windows Server 2003 SP1 computers. This update has the same functionality as the update for Windows XP SP2.
The credential roaming functionality is also implemented as a core feature in Windows Vista and Windows 7.
However, there are differences as to how credential roaming behaves for each of these versions. This is mainly because credential roaming was improved in several development phases. As mentioned, Windows Server 2003 SP1 was the first release of Credential Management Services. The code was implemented for Windows Vista and was finally ported back to the Windows XP SP2 and Windows Server 2003 SP1 credential roaming software update. Because of new core features in Windows Vista, Credential Management Services in Windows Vista has more capabilities than the software update for Windows XP SP2 or Windows Server 2003 SP1.
The following table illustrates the differences between the credential roaming releases at a high level. In the white paper, you will find more information on every implementation detail.
The different implementations are fully interoperable so that a user could work on all three Windows versions. However, some information, such as the credential manager information, might not be available on a client computer that runs on an earlier version.
Credential Roaming Releases
| Feature | Windows Server 2003 SP1 | Windows XP SP2 software update, Windows Server SP1 software update | Windows Vista / Windows Server 2008 |
| Can roam DPAPI master keys. | Yes | Yes | Yes |
| Can roam X.509 certificates. | Yes | Yes | Yes |
| Can roam Digital Signature Algorithm (DSA) and Rivest-Shamir-Adleman (RSA) keys. | Yes | Yes | Yes |
| Can roam keys made by other algorithms, for example, Elliptic Curve Cryptography (ECC). | No, if the Active Directory object of the current user contains keys other than RSA and DSA, those keys are ignored. | No, If the Active Directory object of the current user contains keys other than RSA and DSA, those keys are ignored. | Yes |
| Can roam stored user names and passwords. | No, If the Active Directory object of the current user contains any credential manager information, it is ignored. | No, If the Active Directory object of the current user contains any credential manager information, it is ignored. | Yes, but only with other Windows Vista client computers. |
| Conflict resolution: LENIENT or STRICT | Yes | No | No |
| Conflict resolution: Last writer wins | No | Yes | Yes |
| Implementation: Part of Winlogon | Yes | Yes | No |
| Implementation: WMI job (taskeng.exe process) | No | No | Yes |
Since Credential Management Services requires a properly configured backend infrastructure, there are differences if you have an Active Directory infrastructure that runs on Windows 2000, Windows Server 2003, or a more recent Windows Server product. The following table shows the differences between the Active Directory releases.
| Domain Controller | Windows 2000 SP3, Windows 2000 SP4, Windows Server 2003 RTM | Windows Server 2003 SP1 or later | Active Directory running in Windows Server 2008 |
| Schema update is required if the current schema version is lower than 34. | Yes | Yes | Not required |
| Administrative Template (ADM) import into Group Policy is required. | Yes | Yes | Not required |
| Active Directory security descriptor property settings must be applied manually. | Cannot be applied | Yes | Not required |
| Group Policies: Works smoothly with roaming profiles. | No, certain configuration folders should be excluded from roaming to avoid roaming conflicts. | No, certain configuration folders should be excluded from roaming to avoid roaming conflicts. |
Note
The confidentiality flag that is used to secure certain attributes in Active Directory is not available in versions earlier than Windows Server 2003 SP1. To keep the roaming credentials secure, all domain controllers must run on Windows Server 2003 SP1 or a later version. In a mixed domain controller environment, even a single Windows Server 2003 or Windows 2000 domain controller would weaken the security because every authenticated user would have read permissions on all user attributes on that domain controller.
Where Credential Roaming Can Be Used
Credential roaming can be used in a wide variety of scenarios where users need their certificates and private keys on more than one domain computer. Any X.509 certificates stored in the user's "Personal" store (store name "My") and the corresponding key pairs that are used for applications such as encryption, decryption, signing, client authentication, and securing Web sites can be included in a credential roaming deployment. Also, pending certificate requests that are stored in the user's "Certificate Enrollment Requests" store (store name "REQUEST") are part of credential roaming.
Credential roaming services also add value in scenarios where users logged on to multiple Windows Vista computers have a requirement to access their stored user names and passwords on each of those computers.
To appreciate the power and flexibility of credential roaming, the following sections describe various use scenarios.
- Accessing secured information from multiple computers.
- Logging on to secured wireless networks.
- Accessing secure Web sites.
- Accessing remote systems with credential manager.
- Using Encrypting File System.
- Enrolling certificates for pending certificate requests.
- Improving the renewal of smart card certificates.
Note
Credentials Roaming was designed to accommodate single user sign-in scenarios. It was not designed for scenarios where many users are signed-in to a single devices, such as Terminal Services.
Accessing Secured Information from Multiple Computers
This scenario is about accessing secured e-mail from multiple computers.
- A user is manually or auto-enrolled for a digital e-mail certificate on a desktop computer. With credential roaming in place, and without any additional action on the user's part, the user's local "Personal" certificate store is synchronized with Active Directory as part of the certificate enrollment process.
- When the user logs on to a laptop computer as a domain user, which is connected to the network, the user's certificates and keys are downloaded from the domain controller to the laptop computer. If Group Policy applies or certificate renewal takes place on the laptop computer, the credentials that are stored in Active Directory are updated at the same time.
By default, once the user has any certificates and private keys on the laptop computer, these locally installed credentials are available to the user even when not connected to the organization's network—connected to the Internet over the home Internet connection or disconnected from any network.
For example, Bob has a workstation and a laptop computer at work. Both computers are domain members and Bob has logged on to both computers as a domain member. Bob was enrolled for an e-mail encryption certificate in his "Personal" certificate store and carries an e-mail signing certificate on his smart card. Certificate enrollment was performed when Bob worked at the workstation.
When Bob logged on to his laptop, both the certificates as well as the private key corresponding to the encryption certificate were roamed into the user profile on his laptop computer while being connected to the corporate network.
Bob takes the laptop computer home to read his e-mail. At home, he connects the laptop computer to the Internet and benefits from Remote Procedure Call (RPC) over secure hypertext transfer protocol (HTTPS) to enable Microsoft Office Outlook® to synchronize his mailbox. To read e-mail that way, no interactive desktop network logon is required since Outlook authenticates just the session that is required to exchange information with the Microsoft Exchange Server. Bob has the same working experience on his laptop computer with encrypted e-mails as on the workstation in the office because the Secure/Multipurpose Internet Mail Extension (S/MIME) encryption certificate is also available on the laptop computer. Bob is also able to sign e-mail. However, since the signing key is stored on his smart card, he needs to insert the smart card and enter the personal identification number (PIN) before he can send a signed e-mail. With Credential Management Services, his signing and encryption certificate roams automatically but only the private key that is associated with the encryption certificate roams as well. The private key that is associated with his signing certificate resides on his smart card at any time and therefore cannot roam.
After awhile, Bob decides that it takes too long to download all the files with attachments through his modem connection. Therefore, he terminates Outlook on his laptop computer and opens a terminal server session to his company's extranet. Those terminal servers have very limited network access but provide access to the Exchange mailbox with Outlook. In the terminal server session, Bob is able to read encrypted e-mail messages, since his S/MIME certificates have been roamed when he logged on to the terminal server session with domain credentials.
The following figure illustrates the processes and network connections associated with using credential roaming on multiple computers. A certificate is enrolled to a computer where a user is logged on interactively. With credential roaming, the certificate and also the corresponding key pair are uploaded into the user's object in Active Directory about 10 seconds after certificate enrollment. If the domain consists of multiple domain controllers, Active Directory replication will make the updated user object available to all other domain controllers within the domain. If the same user who was previously enrolled for a certificate logs on to a different computer or terminal server session, credential roaming will synchronize the user's local certificate store with the certificates that are stored in Active Directory.
Logging on to Secured Wireless Networks
Alice works as a developer of internal applications. Therefore, she spends most of her time on her workstation. However, to demonstrate her current development to a broader audience, she needs to go to a conference room where only wireless network access is provided. Her organization enforces authentication via Protected Extensible Authentication Protocol (PEAP) with a certificate before a client can access the wireless network. To connect from the conference room to her application server, Alice borrows a domain-joined laptop computer from her co-worker.
Her client authentication certificate was already issued when she was logged on to the workstation. To use the user client authentication certificate on the wireless network, she must first log on to the laptop computer while it is connected to an Ethernet port in her office so that credential roaming can replicate her authentication certificate and parent Certificate Authority (CA) certificates for establishing trust.
Later, when Alice is ready to make her presentation, she can use her credentials to log on to the wireless network and access her application server.
Accessing Secure Web Sites
Bob is a database specialist. He works as a consultant and uses digital certificates to authenticate to secure Web sites. Those Web sites are maintained by his own company to obtain and update customer data from inside and outside his corporate network.
Bob uses his powerful desktop computer in his company's office where he performs database testing. However, he prefers his laptop computer when he visits customers. As a user enabled for credential roaming, Bob has the same working experience when he connects to one of the Web sites in his company's extranet because his Secure Socket Layer (SSL) client authentication certificate roams to his laptop computer.
Accessing Remote Systems with Credential Manager
Windows Vista extends the credential roaming functionality so that stored user names and passwords can also be roamed between multiple Windows Vista computers. Pre-Windows Vista versions will just ignore these credentials if there are any in the user's Active Directory object.
Alice works as an IT administrator in a company that has recently acquired another company. An Active Directory trust has not yet been established between the Active Directory forest where Alice's account resides and the forest of the newly acquired company. Since she has to access resources at computers that belong to her forest and to the acquired forest, she decided to store the user name and password when she accesses a resource in the acquired forest instead of entering the logon information repeatedly. Alice can access resources in the new forest from any of her Windows Vista logon sessions once she has added the resource to her credential manager.
Using Encrypting File System
Credential roaming can enhance the use of Encrypting File System (EFS) in various ways, for example, roaming EFS certificates that are signed by a CA or are self-signed.
Bob works at his workstation computer and also at his laptop computer. Sometimes, he uses a Universal Serial Bus (USB) memory stick to move files between both systems if he is not connected to the network. To keep confidential files secure on the token, he has decided to format the token with New Technology File System (NTFS) on his Windows Vista computer and to encrypt some of his files on the USB memory stick. Bob has encrypted some files with his self-signed EFS certificate since his IT administrator had not disabled the use of EFS at all according to the Microsoft Knowledge Base article at http://support.microsoft.com/?id=222022. At a later time, the IT administrator decides to deploy EFS certificates to managed domain users. Now Bob has some files encrypted with self-signed certificates and some with the enterprise CA issued EFS certificate. With credential roaming in place, Bob is not concerned that he might lose his local profile including the self-signed EFS certificate and key on one of these machines. His self-signed certificate is downloaded into a new profile once it is created.
If both computers are upgraded to Windows Vista, Bob is also able to copy EFS–encrypted files between the computers and can access the files on the workstation from the laptop computer remotely, or vice versa.
Note
An EFS data recovery agent should not log on and perform data recovery while the related user account is enabled for Credential Management Services. Credential Management Services would leave the data recovery certificate on any computer where the agent logs on locally or remotely with an interactive session. Even if the data recovery certificate including the private key is DPAPI–protected, it is a good practice to keep the number of certificate and key copies as low as possible.
Enrolling Certificates for Pending Certificate Requests
The CSC can ensure that certificate requests that require certificate manager approval are properly enrolled even if the user is logged on to a different computer than the one where the certificate request was originally submitted.
This functionality is enabled by the fact that credential roaming also stores the certificate request and the key material that was generated as part of the certificate request generation in the Active Directory user object.
Bob works as a new employee in an insurance company. When he prepared his work environment, he also submitted a certificate request for wireless access while being connected to the wired network from his domain-joined laptop computer. To keep the organization's wireless network secure, every client-authentication certificate must be approved by a certificate manager. Unfortunately, while the certificate request is pending, Bob decided to start over with his laptop computer setup. He was not aware that the insurance company is using local profiles to keep the network use low. Without Bob's awareness, the CSC has uploaded the certificate request including the newly generated key pair into his Active Directory user object when he actually submitted the request. A few hours later, Bob's laptop computer was up and running with the new configuration. In the meantime, the person who acts as certificate manager had also approved his certificate request. When Bob logged on to the domain, he could download his new certificate from an intranet HTTP link. Bob accepted the certificate and automatically linked it with the private key that was already downloaded from his Active Directory user object into the local key store. He also removed the pending certificate from the local and Active Directory user object.
Without credential roaming, Bob would have lost his previously generated certificate request; he would have spent time troubleshooting why his certificate request had disappeared.
Improving the Renewal of Smart Card Certificates
With credential roaming in place, smart card users will have a better renewal experience. Users who use their smart cards rarely are notified by the Windows auto-enrollment functionality if a certificate that is stored on a smart card (or similar token) is going to expire.
Windows stores a copy of every certificate that is stored on a smart card in the user's "Personal" certificate store. Thus, the auto-enrollment code has access to the certificate properties and can verify the expiration date of certificates.
Alice works in the accounting department. During the company-wide smart card enrollment, Alice has received a smart card and was enrolled for a smart card certificate. She has activated her smart card at her workstation computer. She did not realize that the smart card certificate was populated into her personal certificate store and from there—with credential roaming in place—into her Active Directory user object.
The only purpose for her to use a smart card certificate is to dial into the corporate network. However, it is very seldom and usually only required when she is working on the annual financial statement from home.
During the year, Alice was given a new computer so her local user profile including the smart card certificate in the personal store was lost. Since she had no roaming profile and never uses the smart card at her workstation, she would not be notified in time if the smart card certificate was going to expire and prevent her from dialing into the corporate network. With credential roaming, the smart card certificate is downloaded into her new local user profile so that the auto-renewal mechanism can remind her to renew the smart card certificate before year's end so she can prepare the annual financial statement from home.
Without credential roaming, Alice's smart card certificate would have expired without her notice and would have prevented her from dialing into the corporation's network.
How Credential Roaming Works
The credential roaming part of the CSC adds new functionality for user credential management. It relies on the existing domain logon mechanism and uses group policies to maintain the configuration. The following sections provide some general information about credential roaming and detailed information about how it works on Windows Server 2003 SP1, Windows XP SP2 with the software update for credential roaming, and Windows Vista or Windows Server 2008.
Support for Service Accounts
With the current implementation, credential roaming for service accounts works only under specific circumstances.
Technically, a service account is a user account that is dedicated to a certain application running as a service on Windows. Therefore, a service account has the identical capabilities that a user account has. However, a number of applications, such as Microsoft Windows Internet Information Service (IIS) or Microsoft SQL Server™, maintain all their certificates in the computer store—regardless of whether the application uses a custom service account or is using the default local system account. Since credential roaming is only able to roam certificates that are available in the personal store of a user, it will not recognize any certificates that are available in the machine's personal store. Microsoft is aware of this limitation, which applies to a number of Microsoft server products, and is planning on developing workarounds in future versions of Windows.
If your application maintains the certificates that belong to its service account in the user Personal certificate store, credential roaming will work. It will not work if the application requires the certificates in the computer's certificate store.
Active Directory Schema
This section describes the specific schema attributes that are used for storing user credentials and data relating to credential roaming. All the information is related to the domain-naming context. This means that all information stored in these attributes is only replicated within a domain and is not exchanged with global catalog servers.
Note
As mentioned previously, only domain controllers running on Windows Server 2003 SP1 (Build 3790.1830) and later Windows versions provide the capability to secure the credential roaming attributes to be read/write only to the user. Domain controllers running on any Windows 2000 version or Windows Server 2003 (Build 3790) do not allow securing specific attributes from reading.
To determine the build-number of a computer, see the Microsoft Knowledge Base article at http://support.microsoft.com/?id=262255.
Protecting the specific attributes that contain private keys and user names and passwords relies on a new Active Directory security feature called "confidential attribute" that was introduced in Windows Server 2003 SP1. For more information about the confidential attribute, see the article "Confidential Attributes" at
The following list shows the common names of the attributes that are required for credential roaming. Those attributes need to be added manually to an Active Directory schema that is lower than schema version 34. To verify the schema version of Active Directory, view the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Parameters\Schema Version registry key on a domain controller.
ms-PKI-DPAPIMasterKeys This multi-valued attribute contains master key files and information for DPAPI.
For more information about DPAPI, see the Knowledge Base article at http://support.microsoft.com/?id=309408
The following objects will be roamed and are contained within this attribute.
All master key files. There can be multiple master key files. New master key files are created every 90 days through the DPAPI. Master key files must be maintained and roamed in perpetuity. The DPAPI master key files only exist if DAPI was used to protect information already and are hidden and found in the file system at
%APPDATA%\Microsoft\Protect\userGUID}
Use dir /a:s at a command-line prompt to make these files visible. If the Protect directory does not exist, no certificates have been enrolled.
The Preferred file that specifies the most current master key to be used for encryption. This file is updated every time a new master key is created. The Preferred file is hidden and is found in the file at
%APPDATA%\Microsoft\Protect\userGUID}\Preferred
Also, the file only exists if DAPI was used to protect information. Use dir /a:s at a command-line prompt to make this file visible.
ms-PKI-AccountCredentials This multi-valued attribute contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests.
ms-PKI-RoamingTimeStamp This attribute is used to record the time of the latest change to the user object in Active Directory.
userCertificate This attribute is used by Certificate Services and applications to store X.509 encryption certificates. It is not used by the CSC. Roaming certificates are only maintained in the ms-PKI-AccountCredentials. Therefore, it might happen that a user who has two certificates, for example, will roam the certificates successfully but other users cannot access these certificates from the user object.
The following table shows the access permissions that are applied to the attributes specific to credential roaming.
In a pure Windows Server 2003 SP1 domain controller environment where the confidential attribute was set properly for credential roaming specific attributes, the following access permissions apply.
Access Permissions
| Common Name | User Who Owns the Attribute (Current User) or Domain Administrator | Other User |
| ms-PKI-DPAPIMasterKeys | Read/Write | Not visible and no access |
| ms-PKI-AccountCredentials | Read/Write | Not visible and no access |
| ms-PKI-RoamingTimeStamp | Read/Write | Not visible and no access |
| userCertificate | Read/Write | Read |
In a mixed environment where Windows Server 2003 SP1 domain controllers are used together with domain controllers that are running earlier Windows versions than Windows Server 2003 SP1 or where Windows Server 2003 SP1 is not used at all, the following access permissions apply on all computers that do not run Windows Server 2003 SP1, regardless of the confidential attribute. However, if the confidential attribute was set, it applies at least on those computers that run Windows Server 2003 SP1 or a later Windows version.
| CMS-Related Attribute | User Who Owns the Attribute (Current User) or Domain Administrator | Other User |
| ms-PKI-DPAPIMasterKeys | Read/Write | Read |
| ms-PKI-AccountCredentials | Read/Write | Read |
| ms-PKI-RoamingTimeStamp | Read/Write | Read |
| userCertificate | Read/Write | Read |
As in the previous case, every member of the domain administrators group is able to read these attributes irrespective of whether the confidential search flag is applied. This is not a security risk because the domain administrator could also reset the user's password and log on as that user to access all of the user's information.
It is important to understand that even if another Active Directory user is able to read the user's credentials because the domain controller runs on an earlier version than Windows Server 2003 SP1, the user will not be able to decrypt or use the protected credentials. All credentials are encrypted so that only the credential owner is able to decrypt them through DPAPI mechanisms. Nevertheless, it is highly recommended to keep a strong access control list (ACL) on the attributes to provide the highest level of security.
It also depends on the tool that is used whether the subject is able to actually retrieve the value of an attribute. The following table shows the different tool behavior if the security context that is used to run the tool has read permissions on the attribute and the attribute is not empty.
| LDAP Tool
|
ms-PKI-DPAPIMasterKeys ms-PKI-AccountCredentials
|
ms-PKI-RoamingTimeStamp
|
userCertificate
|
| dsa.msc | Attribute and value are not shown. | Attribute and value are not shown. | Shown if advanced view is turned on. |
| ADSIedit.msc | Attribute is shown, but after clicking the Edit button, no value is shown. | Shows attribute, clicking the Edit button shows the value. | Shows attribute, clicking the Edit button shows the value. |
| dsquery.exe | Attribute is shown but no value. | Attribute and value are shown. | Attribute and value are shown. |
| Ldifde.exe | Attribute and value are shown. | Attribute and value are shown. | Attribute and value are shown. |
| Ldp.exe | Attribute and value are shown. | Attribute and value are shown. | Attribute and value are shown. |
The reason ADSIedit and dsquery do not show values for the ms-PKI-DPAPIMasterKeys and ms-PKI-AccountCredentials attribute is because both tools do not support the binary data type. To make the ms-PKI-DPAPIMasterKeys, ms-PKI-AccountCredentials, or ms-PKI-RoamingTimeStamp visible with ldp.exe, these attributes must be added through the menu bar to the list of attributes in the ldp.exe search options.
The following two screenshots—taken with ADISedit—illustrate the user's Active Directory object if credential roaming is enabled but none of the user certificates was published into Active Directory. In that case, credentials will roam but other users do not have access to the certificate owner's certificates so that they cannot retrieve the certificate to send the certificate owner encrypted e-mails, for example.
The figure above shows that credential roaming is enabled
The figure above shows that certificates are not published in Active Directory
Credential roaming supports a number of different items to roam: DPAPI Master keys, the DPAPI Preferred file, certificates, certificate requests, RSA or DSA keys, and on Windows Vista, keys that are generated with ECC. Certificate requests are roamed only if the certificate template or the CA request handling was configured to put certificate requests into a pending state.
In Windows Vista, stored user names and passwords are also roamed. However, user names and passwords are not roamed starting in Windows 7 (http://social.technet.microsoft.com/wiki/contents/articles/4296.aspx).
The following table describes the differences between various operating systems and credential roaming capabilities:
| Windows XP with SP2 and credential roaming update, Windows Server 2003 with Service Pack 1 | Windows Vista and Windows Server 2008 | Windows 7 and Windows Server 2008 R2 | Windows 7 with credential roaming update, Windows 8, and Windows Server 2012 | |
| DPAPI Preferred File | Yes | Yes | Yes | Not by default. If filtering is completely turned off in Group Policy, then it will roam. |
| DPAPI MKs associated with a roamed private key | Yes | Yes | Yes | Yes |
| DPAPI MKs not associated with a roamed private key | Yes | Yes | Yes | Not by default. Can be permitted through Group Policy. |
| Certificates with associated private keys in the local store | Yes | Yes | Yes | Yes |
| Certificates without associated private keys in the local store | Yes | Yes | Yes | Not by default. Can be permitted through Group Policy. |
| Certificates on SC mini-driver smart cards | Yes | Yes | Yes | Not by default. Can be permitted through Group Policy. |
| CAPI RSA, DSA private keys associated with certificates | Yes | Yes | Yes | Yes |
| CNG RSA, DSA, ECDSA, ECDH keys associated with certificates | No, Windows XP and Windows Server 2003 do not support CNG keys | Yes | Yes | Yes |
| Private keys not associated with certificates (either CAPI or CNG) | Yes | Yes | Yes | Not by default. Can be permitted through Group Policy. |
| Certificate requests | Yes | Yes | Yes | Yes |
| Stored user names and passwords | No | Yes | No | No |
Notes:
- The DPAPI Preferred File must not be roamed when DPAPI filtering is on.
- If users in your enterprise network typically enroll multiple certificates on multiple computers or other domain member devices more frequently than the DPAPI rollover period (typically every 90 days), you may want to consider enabling the Roam DPAPI keys that are not used by roamed private keys setting (available starting with Windows Server 2012). While this will cause the DPAPI master key to be refreshed every 90 days in the Active Directory Domain Services (AD DS) database, this may actually reduce the storage requirements in the AD DS database, because one DPAPI master key will be synchronized and stored for all the enrollments during that period, rather than storing multiple master keys generated by multiple different devices. Organizations that use certificates with longer validity periods should probably leave this policy disabled.
To configure credential roaming properly, it is important to understand how many tokens a user has at a time. A new user, who logs on interactively, has only two tokens: the DPAPI Preferred file and one DPAPI master key. Once the user is enrolled for a single certificate, two more tokens are added: the certificate and the private key. A domain user who has one certificate has actually at least four tokens that need to be roamed. Certificate requests are roamed only if they are available in the "Certificate requests" store at the time when credential roaming takes place. Stored user names and passwords are a specific feature of Windows Vista/Windows Server 2008 and are configured for roaming if they are available on the local computer.
DPAPIPreferredfile – This file specifies the most current master key to be used for encryption. The Preferred file is stored as a BLOB in the ms-PKI-DPAPIMasterKeys attribute.
DPAPI master key – Each user account has one or more randomly generated master keys if DPAPI encryption was performed before. The number of master keys depends on the age of the user's profile. Master keys are renewed at regular intervals of 90 days. The interval is hard-coded; therefore, after 90 days, a user has two DPAPI master keys. Each master key counts as a token. All DPAPI master keys are stored as a BLOB in the ms-PKI-DPAPIMasterKeys attribute.
Current certificate – Each user can have one or multiple certificates. Each certificate counts as a token. All certificates are stored encrypted in the ms-PKI-AccountCredentials attribute.
Private key – A user may have one or many private keys. The number of keys is not necessarily equal to the number of certificates since several certificates can technically share one key. All keys are stored encrypted in the ms-PKI-AccountCredentials attribute.
Credential Roaming State File
To keep credentials in the user object's ms-PKI-AccountCredentials attribute synchronous with the local certificate store, the credential roaming code maintains a state file. The state file is used to keep all information that is used to make roaming decisions—whether a credential should be uploaded to Active Directory or downloaded from Active Directory. The state file does not store the credentials themselves, but some of the metadata such as timestamp and hashes. The state file on a Windows Server 2003 SP1 or Windows XP SP2 client computer is located in the following directory.
%USERPROFILE%\Local Settings\Application Data\Microsoft\DIMS
A Windows Vista computer maintains the state file in the following directory.
%LOCALAPPDATA%\Microsoft\DIMS
This directory contains two hidden files. To see the files in the file system, type dir /a at a command-line prompt or enable Explorer to show hidden files. The state.dat is the current state file. The state.da~ is the previous state file.
Client Registry Keys
When Group Policy is applied at a domain computer, a few registry values are set locally under the HKCU\Software\Policies\Microsoft\Cryptography\Autoenrollment registry key. The values mirror the settings that have been set in an enabled Certificate Management Services Group Policy template. If the Group Policy template is set to Disabled or Not Configured, the values do not exist.
The following table shows the values that are available under the key.
| Value Name | Description |
| DIMSRoaming
This DWORD key is defined through the Group Policy Object Editor setting "Specific DIMS and Credential Roaming settings". |
The value represents a bit-mask that is composed of the following bits.
The following bits can only be set for Windows Vista client computers.
These two bits are only interpreted by clients that are running Windows Server 2003 SP1 without the credential roaming software update. All other clients that are enabled for credential roaming ignore them.
|
| DIMSRoamingMaxNumTokens
This DWORD key is defined through the Group Policy Object Editor setting "Maximum number of roaming credentials per user". |
The value defines the maximum sum of credentials (DPAPI Preferred file, DPAPI master key, certificates, keys and certificate requests, stored user names and passwords) to be roaming and can be any value between 1 and 10000.
The absolute minimum value of the DIMSRoarmingMaxNumTokens parameter is 1. However, it is recommended that you configure no less than 200. Note It is highly recommended that the "Maximum number of roaming credentials per user" parameter in Group Policy is set to "generous". This is because you will not know exactly how many DPAPI master keys a user already has since it depends on the age of the account. For a new user, for example, you would have six roaming tokens if you have deployed two certificates: two certificates, two private keys, one DPAPI master key, and one DPAPI master key pointer. If the maximum number of roaming credentials was set to six in Group Policy, after 90 days, Credential Management Services will stop roaming suddenly because a new DPAPI master key is generated automatically. This would extend the number of credentials for that user to seven. |
| DIMSRoamingMaxTokenSize
This DWORD key is defined through the Group Policy Object Editor setting "Maximum size (in bytes) of a roaming credential". |
The value defines to which token size a token is written into the user object of the current user. Every token is measured individually. Therefore, if you pick a relative small token size, it is possible that only the key is roamed but not the certificate, for example. Regarding certificates, the token size varies based on the key size.
The maximum size in bytes of an individual token and can be any value between 1 and 100000 while the default value 65535 represents a reasonable token size. |
| DIMSRoamingMaxTombstoneDays
This DWORD key is defined through the Group Policy Object Editor setting "Maximum tombstone credentials lifetime in days". |
The value defines the number of days after a token marked for deletion is deleted from the user's object. The value is completely independent from the Active Directory tombstone and can be anything between 1 and 3650; 60 is the default. |
Note
A user object can become large if there are a large number of tokens that also have a large token size. The maximum size of the user object's ms-PKI-AccountCredentials attribute is the result of the maximum number of tokens multiplied by the maximum token size.
To disable credential roaming for a user even if credential roaming was turned on through group policies, the following registry key can be set.
HKCU\Software\Microsoft\Cryptography\DIMS\KeyRoaming Disabled = DWORD:0xFFFFFFFF
However, since group policies apply during user logon, credentials may have already roamed before the user has a chance to set this registry key. The key might be useful in test environments to disable credential roaming temporarily.
Roaming Credentials on Windows Server 2003 SP1 or Windows XP SP2 with Software Update Installed
This section documents the steps that credential roaming performs on a Windows Server 2003 SP1 or Windows XP SP2 computer where the software update was installed. The following figure illustrates the components of credential roaming in Windows Server 2003 SP1 or Windows XP SP2.
A user logs on to a domain-joined workstation.
As part of the logon process, Group Policy is applied to the computer user's computer. dimsntfy.dll triggers an event to activate credential roaming.
Because credential roaming has been configured in Group Policy, dimsroam.dll will count the number of tokens in the local certificate store. If there are more roaming tokens locally available than DIMSRoarmingMaxNumTokens (as specified in Group Policy) credential roaming refuses to work. It does not synchronize the local tokens with the tokens in the Active Directory object of the current user.
To reduce the amount of LDAP traffic on the network, credential roaming refrains from reading its attributes as long as possible. First, it checks if the user serial number (USN) or one of the attributes has changed. It then counts the number of tokens that are not "tombstoned" in the Active Directory object of the current user. Also, it checks whether the MaxNumTokens has been exceeded. If the total number of non-tombstoned tokens plus tombstoned tokens exceeds two times the DIMSRoarmingMaxNumTokens (as specified in Group Policy), credential roaming will not work. It does not synchronize any of the local tokens with the tokens in the Active Directory object and vice versa for the current user.
Next, the local tokens are compared with the state file and uploaded into the Active Directory object of the current user. The modified credentials in the Active Directory object of the current user are also compared to the state file and downloaded into the local store.
It may be the case that only one or even both token stores are empty before credential roaming was enabled through Group Policy. If no tokens are locally available or if the tokens are current, no further action is taken. However, if tokens are available in the Active Directory object of the current user and are more recent, dimsroam.dll manages the process of copying these encrypted credentials into the local token store. Note that certificates that are flagged as archived are handled as normal certificates so that they also roam. At any time, the private key material is encrypted with the DPAPI key. Moreover, all communication related to credential roaming between components on the local computer and between the local computer and Active Directory is Kerberos-encrypted and based on signed packets.
dimsroam.dll also deletes certificates that have a tombstone that is older than the configured maximum number of tombstone days. When the roaming code verifies tombstone objects, it takes the current Coordinated Universal Time (UTC) and subtracts the number of tombstone days as specified in the policy. All tombstones timestamps in Active Directory or the state file that are older than the calculated tombstone deletion date are removed. The tombstone timestamp is not adjusted to the normal day cycle. If the verification process takes place at 11 A.M. and the number of tombstone days was set to one, all certificates that have been modified before 11 A.M. yesterday are removed. The tombstone timestamp is maintained as UTC so that it is independent of any time zone setting. Those tokens are deleted from the Active Directory object of the current user and their reference is also removed from the state file.
If auto-enrollment has been configured in Group Policy, the pautoenrol.dll processes auto-enrollment requests after the credential roaming transactions have been processed. If the user has not been enrolled for a particular certificate, that is, it does not exist in either the local personal store on the workstation or in Active Directory, certificate auto-enrollment is initiated. Certificate requests that do not require any certificate manager approval are never roamed to keep the number of credentials in Active Directory as small as possible.
Note
Credential roaming always occurs before auto-enrollment to prevent auto-enrollment from taking place unnecessarily.
While the user is logged on, any token change such as certificate enrollment, renewal, or deletion is replicated into the Active Directory object of the current user. This happens whenever the credentials roaming provider is notified. Notification will occur based on the following events.
A user logs on to the domain.
The user locks or unlocks the machine.
certutil -user -pulse is performed at a Windows Vista or Windows Server 2008 command-line prompt.
A change to a private key or certificate in the user's local certificate store.
Enrolling a certificate manually with the Microsoft Management Console (MMC) Snap-In, certreq.exe, or any other tool.
Importing a certificate to the personal certificate store.
Removing a certificate from the personal certificate store with the MMC Snap-In, certutil, or any other tool.
Receiving a new certificate with auto-enrollment.
Group Policy is applied or refreshed.
Except for Group Policy, credential roaming begins immediately. For Group Policy, an additional latency of up to four hours may occur until the certificate store is refreshed. The delay applies also for a forced Group Policy update. This latency was introduced to avoid high load on the domain controllers if Group Policy is updated or created by an administrator.
Credential Management Services has a hard-coded behavior such that it performs synchronization between the local tokens and the tokens that are stored in the Active Directory user object of the current user after approximately 10 seconds. You may recognize a special behavior if you request, enroll, and accept a large number of certificates within the 10-second waiting time. If a certificate for a pending request is enrolled and accepted within the 10-second waiting time, the certificate request is not roamed into the Active Directory object of the current user because the request is deleted from the Certificate Enrollment Requests container before the synchronization code is activated. If it takes longer than 10 seconds to issue a certificate for a certificate request that is pending, the certificate request is roamed.
When a user logs on to another domain-connected computer, the same Group Policy is applied for the user, and Credential Management Services replicates the tokens according to the steps described previously.
Note
Active Directory replication latencies may apply within a domain. Therefore, a user may not receive roaming credentials if a different domain controller is used for logon.
Roaming Credentials on Windows Vista and Windows Server 2008
The WinLogon has been redesigned starting in Windows Vista and the notification module has been removed from WinLogon for better performance and security. Dimsntfy.dll no longer exists in Windows Vista and later Windows versions. Instead, WMI.JOBS, the new generation of Task Scheduler, is used to trigger Credential Management Services. A new dynamic link library (DLL) called dimsjob.dll replaces dimsntfy.dll as the task handler for Credential Management Services. In Windows Vista, dimsjob.dll, dimsroam.dll, and pautoenr.dll are loaded in the same process—the Task Engine Process (taskeng.exe)
dimsjob.dll registers to the following Task Scheduler events.
| WMI Event
|
Credential Roaming
|
Auto-enrollment
|
| Machine reboot | Yes | Yes (machine) |
| Interactive logon | Yes | Yes (user) |
| Lock and unlock a computer | Yes | No |
| Remote connect and disconnect | Yes | No |
| Local switch between users | Yes | No |
| Timer event every 8 hours | Yes | Yes (user and machine) |
Besides these Task Scheduler events, dimsjob.dll also creates its own listeners to receive the local token store change notifications and Group Policy change notifications, which cannot be provided by the Task Scheduler.
Since Credential Management Services is scheduled by the Task Scheduler, its scheduling parameters can be viewed and changed in the Task Scheduler user interface (UI). The task names are DIMS-SystemTask, DIMS-UserTask, and DIMS-UserTask-Roaming under the Microsoft\Windows\DIMS Task Folder. However, it is recommended that the users not change these task settings unless they are really aware what they are doing.
The general workflow for Credential Management Services is similar to the steps described in the previous section. The main difference between Windows Vista and earlier Windows versions is the exchange of certain components.
Deleting Credentials
After a credential has been added to a credential store, it can also be deleted from that store. Such a deletion can be performed manually, for example, with the Certificate Manager MMC Snap-In, credential manager, or custom program code.
Technically, as a domain or enterprise administrator, it is also possible to remove the credential roaming information from a user's Active Directory object.
The following two sections describe the behavior for both cases.
Deleting Credentials From a Local Store
Once a credential is deleted, the copy of the credential in the Active Directory object of the current user is marked for deletion, together with a timestamp that persists for the credential roaming specific tombstone lifetime. The tombstone lifetime was introduced to allow an administrator to recover a deleted certificate from Active Directory without having to recover the certificate from the CA. Unfortunately, at the current stage, even if recovery is technically possible, Microsoft provides no tool to recover a tombstoned token. A Microsoft Knowledge Base article will be released or this white paper will be updated if such a tool becomes available.
The tombstone lifetime for credential roaming is set in Group Policy and completely independent from tombstone lifetime that applies for Active Directory. The default value for the credential roaming–specific tombstone lifetime is 60 days. The Active Directory tombstone lifetime applies at an object level (for example, a user object), while the tombstone lifetime for credential roaming applies to the information stored in the ms-PKI-AccountCredentials attribute within the Active Directory object.
Also, an RSA or Digital Signature Standard (DSS) key is never deleted when a certificate is deleted—neither in the local store nor in the Active Directory object of the current user. The reason for not deleting keys is that a key can belong to multiple certificates, for example, if a certificate is renewed while the same key material is used, the key would be associated with two certificates. Since the key properties do not store a reference to the certificates that actually use this key, there is no way to know whether another certificate still uses this key. This can commonly happen when a certificate is renewed using the old key. Only a certificate carries a reference to the key container where the related key is stored.
Deleting the Token Store in the Active Directory User Object
Using the LDAP protocol or Active Directory Service Interfaces (ADSI) language, it is possible to delete tokens from a user's object in Active Directory. For information about how to do this, see "Deleting Roaming Credentials from Active Directory".
Since the CSC maintains a consistent state of the last successful synchronization on the local computer where the user has logged on, a deleted token store in Active Directory will be recreated based on the tokens that are available locally.
Again, this feature is only available on computers running Windows XP SP2 or Windows Server 2003 SP1 where the credential roaming software update is installed or computers running on Windows Vista or a later Windows version. The feature is not implemented on Windows Server 2003 SP1.
Conflict Resolution in Windows Server 2003 SP1
Note that this section provides technical background only about conflict resolution as it was implemented in Windows Server 2003 SP1. Even if the functionality is still in the code, it is no longer exposed in the current version of the Group Policy ADM. Conflict resolution was removed from the ADM to avoid interoperability issues and configuration misunderstandings in mixed environments.
Credential roaming has been developed to maintain consistency between certificates and keys on multiple client computers and Active Directory.
Users may have imported certificates and private keys that they own as P12 or PFX file at several computers before credential roaming was activated. This might be because the users have already had to work with certificates on several computers.
Two decisions must be made when a software-based certificate and the corresponding private key are imported. One is if high security is configured to protect the private key so that a pass phrase must be entered at any time when the private key is accessed. The second is if the private key is exportable once it has been imported. During the import process, the keys are marked according to the choices that are made.
Conflict resolution comes into play when a user enrolled for certificates on one computer, has exported the certificates and private key material and finally imported the certificates on another computer, but when credential roaming is not enabled. In this case, it can be that different choices regarding key security and exportability were made on the second computer from on the first computer.
When credential roaming is first enabled on a computer, the second computer may already contain the same certificates in the local store as in the Active Directory object if the user has previously logged on to the first computer while credential roaming was already enabled. However, the key properties for these certificates may differ depending on how certificates and keys were imported. This initial conflict must be resolved.
The following is a record of the steps described previously.
- Initially, credential roaming is not enabled for Bob's user account.
- Bob is enrolled for a certificate on his workstation. The private key security is set to Normal and the key is flagged as Exportable.
- Bob exports the certificate and the related private key into a file.
- He imports the certificate and private key at his laptop computer. During the import, Bob decides to set the private key to High Secure and Non Exportable.
- Credential Management Services is enabled for Bob's user account through Group Policy.
- Bob logs on to his workstation. CSC starts and uploads the certificates into his Active Directory user object.
- Bob logs on to his laptop computer. Credential roaming must resolve a conflict between the certificate store on the laptop computer and the certificates in Bob's user object because the certificate provider information is different.
Assuming certificates from the Active Directory object have already been downloaded to the local computer, the DPAPI master keys must be synchronized first because the private keys in the key containers need the master keys for decryption.
Credential Management Services running on Windows Server 2003 SP1 resolves conflicts between the local certificate store and the certificates that are stored in the Active Directory object of the current user—either in lenient or strict mode. Lenient mode is the default setting that causes the CSC to take the less secure key provider information. However, in strict mode, the better protected key will take precedence over the less secured key provider information.
The following conflict resolution rules are used if credential roaming is used on a Windows Server 2003 SP1 computer without the software update for credential roaming.
Retrieve the creation time from the ms-PKI-RoamingTimeStamp attribute from the Active Directory object of the current user.
If either or both of the time stamps for the conflicting certificates are newer than the creation time in the ms-PKI-RoamingTimeStamp attribute in the Active Directory object of the current user, this means that at least one of the certificates was last modified after the deployment of credential roaming for the domain. If this happens, the last certificate is written to the store.
Otherwise, both the certificates in the Active Directory object of the current user and local store must have been created before credential roaming was deployed. The USER_PROTECTED and EXPORTABLE information flags of the key containers for both certificates are retrieved.
The DIMSRoaming registry key is retrieved to have either the lenient (default) or strict bit set.
The lenient or strict arbitration matrix in the following tables is used to decide which key container has precedence. Note that the lenient arbitration chooses the less secure certificate provider information while the strict arbitration chooses the more secure key property information.
The following table shows the implementation logic if credential roaming works in lenient mode.
Exportable, not protected Exportable, protected Not exportable, not protected Not exportable, protected Exportable, not protected Active Directory Active Directory Active Directory Exportable, protected Local Active Directory Active Directory Not exportable, not protected Local Local Active Directory Not exportable, protected Local Local Local The following table shows the implementation logic if credential roaming works in strict mode.
Exportable, Not Protected Exportable, Protected Not Exportable, Not Protected Not Exportable, Protected Exportable, not protected Local Local Local Exportable, protected Active Directory Local Local Not exportable, not protected Active Directory Active Directory Local Not exportable, protected Active Directory Active Directory Active Directory The time stamps of both the certificates are used to determine which certificate content takes precedence. Once again, the last certificate is written to the store.
The key container that takes precedence is stored in the key property. The certificate and its properties are re-combined into a certificate file to overwrite the certificates in the local certificate store and the Active Directory object of the current user.
The other container is physically left on the system, but becomes orphaned.
Conflict Resolution in Windows Vista, Windows 7, and Windows 8
Starting with Windows Vista, full support for Suite-B algorithms was added. This is achieved by having CNG stack in parallel to the current CryptoAPI (CAPI) stack. The credential roaming feature in starting with Windows Vista and Windows Server 2008 has been updated to roam credentials that have been generated with a CNG algorithm (such as ECC) along with the credentials that were generated with a classic CAPI1 cryptographic services provider (CSP).
The conflict resolution matrix as described in the previous section becomes more complex due to this CNG credential support. To avoid these complexities, the conflict resolution feature has been removed from the Windows Vista credential roaming implementation. Instead, a 'last writer to the Active Directory wins' algorithm is used.
The way this 'last writer to the Active Directory wins' algorithm is as follows:
The user enrolls for a certificate on machine A and the key is password-protected and exportable based on the certificate template settings or as specified during manual certificate enrollment.
The user then exports this certificate and the private key and imports it on machine B. While doing this, the user chooses not to protect this key with a password and marks it as non-exportable.
The administrator enables credential roaming. At this stage, the same private key is available on computer A and B but with different properties that refer to the key.
The user logs on to machine B and the credentials are uploaded to Active Directory.
The user then logs on to machine A and the credentials are synchronized with Active Directory. During this synchronization, it is noted that the machine A certificate and key pair have never been uploaded to Active Directory.
The certificate on machine A is uploaded to Active Directory, thus overwriting the certificate that was uploaded by machine B, along with the external properties that point to the key container.
The key pair (container) on machine A is also uploaded to Active Directory.
The key pair (container) that was uploaded by machine B is also downloaded.
The user then logs back on to machine B.
It is detected that the external properties on the certificate stored in Active Directory are newer than those on the local machine; hence, this certificate, along with the properties, is downloaded. This overwrites the certificate on machine B.
The key pair (container) that was uploaded by machine A is also downloaded by machine B.
The result is that
On both the machines, the certificate points to the container that originally belonged to machine A. The key is password-protected and exportable.
On both the machines, the key pair (container) that originally belonged to machine B, is now orphaned, with no certificates pointing to it.
In this example, if the user had logged on to machine A before logging on to machine B, the situation would be reversed, and the container that originally belonged to machine B would be used by both machines.
Modifications to the Certificate Import/Export Wizard
The resulting orphaned containers as described previously are not an ideal situation. To offset this behavior, the Certificate Import/Export Wizard (pfx wizard) in Windows Vista has been modified. When a pfx/p#12 file is exported on a Windows Vista machine, the key container name is also stored in the resulting file. If this pfx/p#12 file is imported on another Windows Vista, Windows 7, or Windows 8 computer, the same container name is used.
However, the user is still given a choice to password-protect the key and to mark it exportable. Thus, it is possible that the same certificate and key container can exist on two machines, but the key properties are different. In such a situation, the 'last writer to the Active Directory wins' algorithm is again used.
Conflict Resolution in the Credential Roaming Software Update for Windows XP SP2 and Windows Server 2003 SP1
The conflict resolution algorithm is also removed from the software update for credential roaming that introduces this functionality for Windows XP SP2 and Windows Server 2003 SP1 computers that have the credential roaming software update installed. The 'last writer to the Active Directory wins' algorithm is used instead.
The certificate import/export wizard is not modified with the credential roaming software update.
The conflict resolution algorithm that was introduced in Windows Server 2003 SP1 is also removed from the credential roaming software update.
The following table illustrates the conflict resolution behavior in the different credential roaming versions.
| Windows Version | Algorithm Used |
| Windows Server 2003 SP1 | Strict/lenient arbitration as set by Group Policy. In absence of a Group Policy setting, the default is lenient arbitration. |
| Windows Server 2003 SP1/Windows XP SP2 credential roaming update | Last writer to the Active Directory wins. |
| Windows Vista | Last writer to the Active Directory wins. |
| Windows Server 2008 | Last writer to the Active Directory wins. |
Event Log Channel
Starting with Windows Vista, an event log channel for credential roaming is available. This log can be found in the Event Viewer under the Applications and Service Logs. The path to the specific log is Microsoft, Windows, CertificateServicesClient-CredentialRoaming.
System Recovery
The CSC roaming provider includes a registry setting that makes it self-healing if something goes wrong with credential roaming.
When the provider detects that it cannot write the state file at all or cannot update a specific token because the token is corrupt, it will automatically put itself into recovery mode to attempt to heal itself the next time the provider is launched. The intent of the self-recovery mechanism is to force the system into a mode where the remote credentials in Active Directory are considered authoritative and override any corrupted certificates or keys on the local computer.
In addition, whenever the state file is opened on the local client computer, a copy of the file is created when a certificate or key is modified. This prevents any credentials from being lost if the computer is shut down prematurely, for example, because of a power outage.
State File Error Handling and Self-Healing
The state file is crucial to the correct functionality of the synchronization algorithm; therefore, the error conditions in accessing the state file must be handled carefully.
If an attempt to access the state file fails, there will be a pause followed by a follow-up attempt to access the state file. The pause is a hard-coded wait sequence that lasts 1, 10, 50, 100, 1000 milliseconds for read operations, and 1, 10, 75, 250, 750, 1250 milliseconds for write operations.
When writing to the state file, a hash of the file is always created so that file corruption is detected when the state file is read. The hash value is not used for any security operations.
There is always a backup copy of the state file. This backup copy is created or overwritten when the primary copy has been written successfully.
If attempts to read the state file fail even after multiple retries, the read will fall back to the backup copy.
If the state file read fails, roaming is not performed. Instead, the state.dat file is deleted and a registry key is set as documented in the table at the end of this list. In Windows Vista, in addition to the registry key, a global application event log entry is generated from source Microsoft-Windows-CertificateServicesClient.
If the attempt to write the state file fails, a registry entry is updated to indicate that roaming changed to the self-healing state.
When synchronization is invoked the next time, CSC first tries to download the roaming tokens from the Active Directory object of the current user to overwrite the local roaming tokens, and then generates an up-to-date state file. If everything is successful, it clears the self-healing flag and the next synchronization will be performed normally.
The registry values in the following table track the self-healing status under the HKCU\Software\Microsoft\Cryptography\DIMS\KeyRoaming registry key.
| Value | Type | Description |
| Disabled | REG_DWORD |
|
| LastTick | REG_DWORD | When in self-healing mode, this value records the last system tick timer that the self-healing is attempted to dampen the file system noise.
Last tick represents the number of milliseconds that have elapsed since the system was started. |
How to Test System Recovery
During the test phase of a Credential Management Services deployment project, you might have the requirement to test the system recovery behavior to better understand how it works.
To manually enforce a system recovery, set the file properties of the state.dat file to read-only. That will cause an Access denied error when Credential Management Services attempts to synchronize the local certificate store with the net store. An error is logged in the Application event-log with event-id 1007. System recovery is performed after you log off and log back on again.
How to Configure Credential Roaming
To use credential roaming, all of your organization's domain controllers should be running at least Windows Server 2003 with SP1. In addition, clients used for credential roaming must also be running at least Windows Vista, Windows XP SP2, or Windows Server 2003 with SP1. However, it is recommended that your client operating systems be at least Windows 7 with the http://support.microsoft.com/kb/2520487 update applied in order to enable filtering of unnecessary tokens to avoid problems related to Active Directory database (NTDS.DIT) growth.
Note that if you have at least one Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 domain controller in your Active Directory environment, steps 1 to 3 do not apply. In this case, you only have to configure credential roaming through group policies.
Configuration of credential roaming involves several steps.
- Active Directory needs to be prepared to store users' certificates, keys, and DPAPI master keys. To prepare Active Directory, use a tool called KRdeploy, which is available from Microsoft Support Services.
- Excluding directories in roaming profiles If users are using roaming profiles, certain directories have to be excluded from roaming to avoid conflicts with Credential Management Services.
- Installing the Group Policy ADM template Credential Management Services will be enabled through a Group Policy ADM template that sets the appropriate registry values on a client computer.
- Configuring the credential roaming Group Policy settings Digital credential roaming is implemented when a domain administrator defines a Group Policy that allows user certificates in the domain to roam. The new Group Policy setting takes effect the next time Group Policy is refreshed on all computers in the domain.
Using KRdeploy.cmd
The KRdeploy script is available if you have an engagement with Microsoft Consulting Services or you can request the script from Microsoft Customer Support Services. For more information about the request procedure, see the Microsoft Knowledge Base article http://support.microsoft.com/kb/907247
Three related script files need to be run to update the Windows Server 2003 Active Directory schema to create the new attributes for credential roaming, and to set the security descriptor properties on these attributes:
- KRdeploy.cmd – This file is a simple wrapper that calls KRdeploy.js. KRdeploy.cmd is called from the command-line prompt.
- KRdeploy.js – This script is a wrapper around ldifde.exe to extend and verify the schema and also to set and verify Active Directory security rights.
- DIMSroam.ldf – This file contains the schema changes that will be applied.
KRdeply.cmd understands four different options to perform Active Directory operations.
--ldif-import: This option instructs the script to apply the schema change. The distinguished name of the forest root domain must be specified. Also, the LDAP Data Interchange Format (LDIF) file that contains the schema extension must be specified. Sample: KRdeploy.cmd --ldif-import dc=contoso,dc=com DIMSroam.ldf
--set-sd: This option is required to apply security descriptor properties in Active Directory. The security descriptor properties can only be set at a domain level.
The option requires the name of the domain where the security descriptor properties should be set. For example, to apply the security descriptor property for domain contoso.com, you would use a command like the following: KRdeploy.cmd --set-sd dc=contoso,dc=com
--ldif-export: This option might be helpful to verify the schema extension because it allows exporting a given part of Active Directory. In case of Credential Management Services, all changes are applied in the Schema container which is subordinate to the Active Directory Configuration container. The following sample illustrates how to export the schema with KRdeploy.cmd Sample: KRdeploy.cmd --ldif-export DC=Contoso,DC=com CMS-Schema.ldf CN=Schema,CN=Configuration
Note
The last parameter CN=Schema,CN=Configuration is fixed and mandatory. If it is not specified, the export file will contain the content of the forest domain object. In case of Credential Management Services, the domain object's content does not change and no valuable output is generated.
For information about how to interpret the output, see "Verifying the Schema Extension"
--dump-sd: This option is useful to verify if the security descriptor properties have been changed successfully.
The option is able to dump the security descriptor property of the entire domain or a given part of the domain. For example, to dump the security descriptor property on the domain object, use the following command. KRdeploy.cmd --dump-sd dc=contoso,dc=com. For example, to dump the security descriptor property of a certain domain part, use the following command. KRdeploy.cmd --dump-sd dc=contoso,dc=com ou=CMS,ou=Users-All. For information about how to interpret the output, see "Verifying the Security Descriptor Property Settings at a Domain Level"
Preparing Active Directory
To prepare Active Directory, a schema extension must be applied and then a security descriptor property must be set. Both tasks are mandatory and must be performed in order and are only required if you do not have at least one Windows Server 2008, Windows Server 2008 R2, or Windows 2012 domain controller in your domain.
Important: If the security descriptor property is not changed manually in a Windows Server 2003 domain controller environment, credential roaming will not work. The security descriptor is automatically set at a domain level once the adrep /domainprep command to prepare a Windows Server 2008 Active Directory. To learn more about preparing the Active Directory schema, see Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That Runs Windows Server 2008 or Windows Server 2008 R2 (http://technet.microsoft.com/library/cc753437.aspx).
Extending the Active Directory Schema
Note
This section applies to schema versions lower than 34 only. If you have upgraded your schema to a schema version equal to or greater than 34, all schema changes and security descriptor properties are already set.
As mentioned previously, Credential Management Services maintains credentials in Active Directory. Therefore, the related Active Directory attributes must be available as part of the schema. Remember that Schema extensions cannot be undone. Once a schema change has been applied, it cannot be removed; however, in Windows Server 2003, individual schema objects can be disabled.
The schema extension for credential roaming needs to be done only once; however, if applied twice, the existing schema is not hurt. If you are not sure whether the schema extension was done previously, see "Verifying the Schema Extension". If the schema changes are there, you do not have to perform the schema extension as described in this section.
The schema applies to all domains within a forest and therefore is required only once per forest.
To upgrade a Windows Server 2003 schema to support Credential Management Services
- Log on as Enterprise Administrator to a computer that is a member of your Active Directory forest.
- Make the files KRdeploy.cmd, KRdeploy.js, and DIMSroam.ldf available to the computer you logged on to.
- The namespace of the Root domain is required to perform the next steps. To find out the namespace of your root domain, run the following command as a single line at a command-line prompt: ldifde -f RootDSE.txt -d "" -r (objectclass=*) -p Base && findstr /i rootDomainNamingContext RootDSE.txt && del RootDSE.txt The name of the root domain will be shown at the bottom of the command output.
- To update the schema, type the following command at a command-line prompt: KRdeploy.cmd --ldif-import [RootDN] DIMSroam.ldf Replace [RootDN] with the namespace of your root domain as determined in the previous step, for example: KRdeploy.cmd --ldif-import DC=contoso,DC=com DIMSroam.ldf. A message like the following should confirm the successful schema update.
ldifde -i -f "dimsroam.ldf" -c DC=X "dc=contoso,dc=com"
Connecting to "DC1.contoso.com"Logging in as current user using
SSPIImporting directory from file "dimsroam.ldf"Loading entries8 entries
modified successfully.
The command has completed successfully
.........
When you are finished extending the schema, the change is populated throughout your Active Directory forest depending on your replication schedule. Clients will only be able to roam their credentials if their current domain controller has already received the schema change. To verify the state of a domain controller, check the schema version in the domain controller's registry.
To do this, see the Microsoft Knowledge Base article at http://support.microsoft.com/kb/556086.
Verifying the Schema Extension
To verify the successful schema change, it is recommended that you use the Active Directory Schema MMC Snap-In which is already part of Windows Server 2003. The schema verification can be performed with normal user permissions on any computer that is a member of the forest and has the Schema Management MMC Snap-In registered. In larger environments, it might be a good idea to verify the schema on several domain controllers to ensure that Active Directory replication deploys the schema change properly within the Active Directory forest.
To perform the verification
Log on with local administrator permissions to a computer that is a member of the Active Directory forest.
To register the Schema Management MMC Snap-In, type the following command at a command-line prompt, and then press Enter.
regsvr32 schmmgmt.dll
To open the MMC, type mmc.exe at a command-line prompt, and then press Enter.
In the MMC, click File, Add/Remove Snap-In.
Click Add, and then select the Active Directory Schema Snap-In. Click Close, and then click OK.
In the left pane, expand the Active Directory Schema node, and then click Attributes.
In the right pane, click the column heading Name to order the attributes alphabetically.
Make sure that the following attribute names appear in the right window pane.
• msPKIRoamingTimeStamp
• msPKIDPAPIMasterKeys
• msPKIAccountCredentials
If you do not find the specific attributes in the Active Directory schema, the schema extension was unsuccessful. If you do not see the attributes on the schema master, something went wrong with the schema extension. If the attributes are visible at the schema master but not on other domain controllers, troubleshoot Active Directory replication issues.
Changing Attribute Security
Credential roaming is storing user credentials in the msPKIDPAPIMasterKeys and msPKIAccountCredentials attributes in the user object. Although the credentials are DPAPI–protected, with the default capability of Active Directory for authenticated users to read attributes of other users, the default behavior presents an unacceptable attack surface risk. This is especially true if Active Directory security was set to Pre-Windows 2000 Compatible Access during the domain controller promotion (dcpromo) process.
Specifically, a user may read the stored credentials of another user, download them, and perform a theoretical brute force attack on these credentials at their leisure.
Changes to the security descriptor properties must be applied on a per domain basis within the forest. That means the following steps need to be performed in every domain within a forest after the schema has been extended and replicated throughout the entire forest. The security descriptor property is inherited from all objects in the domain. Remember that the security descriptor is already set if you have at least one Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 domain controller in your domain.
Log on as Domain administrator to the domain.
At a command-line prompt, type
krdeploy.cmd --set-sd [DomainDN]
Replace [DomainDN] with the namespace of your root domain, for example:
KRdeploy.cmd --set-sd DC=child,DC=Contoso,DC=com
Log off the computer.
Note
In a multi-domain Active Directory environment, repeat the previous steps for every domain where the Certificates Services Client Group Policy is deployed.
Verifying the Security Descriptor Property Settings at a Domain Level
To maintain appropriate security of user certificates and keys, it is important to apply the security descriptor property.
Credential roaming uses a fixed global unique identifier (GUID) to set the security descriptor property. The GUID is also specified in the dimsroam.ldf file. During the verification process, it might be convenient to copy the GUID from that file and use it as a search string in the krdeploy.cmd output as described in the following step-by-step instructions.
To verify the security descriptor property settings
Log on to the domain as a user. Domain administrator permissions are not required to verify the security descriptor property.
Make the krdeploy.cmd file available to the computer you are currently logged on to.
To verify the security descriptor property at a domain level, enter the following command at a command-line prompt.
krdeploy.cmd --dump-sd [DomainDN] / >> csc-sd.txt
Replace [DomainDN] with the namespace of the domain where the security descriptor property was applied, for example:
krdeploy.cmd --dump-sd DC=child,DC=contoso,DC=com / >> csc-sd.txt
Open the newly created csc-sd.txt file with Notepad.
In Notepad, search for the 91e647de-d96f-4b70-9557-d63ff4f3ccd8 string.
If the string is found and the lines above the string look like the following output, the security descriptor was successfully applied at a domain level.
trustee = NT AUTHORITY\SELF
type = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT
access = ADS_RIGHT_DS_READ_PROP ADS_RIGHT_DS_WRITE_PROP
ADS_RIGHT_DS_CONTROL_ACCESS
aceflags = ADS_ACEFLAG_INHERIT_ACE
objtype = {91E647DE-D96F-4B70-9557-D63FF4F3CCD8}
Verifying the Security Descriptor Property for a Certain User
To feel confident, you might want to verify if the security descriptor property settings are applied properly on an individual user object, such as the account of a senior manager of your company. You can use a command-line tool called dsacls.exe, which is part of the Windows Server 2003 support tools to perform this verification. The dsacls.exe tool is built-in starting with Windows Server 2008.
To check the security settings for a user at a command-line prompt
At a command-line prompt, type
dsacls [CN_of_the_user]
For example, use
dsacls "cn=User 1,ou=MyOU,DC=contoso,DC=com" | find "Private Information"
Verify that the output is identical.
Allow NT AUTHORITY\SELF SPECIAL ACCESS for Private
Information < Inherited from parent>
Allow NT AUTHORITY\SELF SPECIAL ACCESS for Private
Information < Inherited from parent>
If the output shows nothing, the confidential flag was not applied to this user and any authenticated user is able to read the specific attributes for credential roaming.
Excluding Directories in Roaming Profiles for Windows XP SP2 and Windows Server 2003 SP1 Computers
In managed environments, both roaming user profiles and credential roaming should not be configured for the same user if those users work on Windows XP SP2 or Windows Server 2003 SP1 computers.
Excluding directories manually in roaming profiles is not required if the Group Policy is configured with a computer running Windows Vista or a later Windows version because the roaming profile exceptions are configured automatically. This is done even if roaming user profiles are not enabled.
Although the two capabilities are not mutually exclusive, unexpected results can occur if both are used by a given user. Tokens might be lost or reappear. For example, if certificates and private keys are stored in both Active Directory and as part of their roaming user profile, the user may end up using less current tokens. The reason for this behavior is that the credential roaming state file maintains the state for all tokens that are part of the user profile. A roaming profile might change what was remembered previously in the state file. That may cause inconsistencies between the actual state of tokens and the state file.
CCredential roaming also does not work with folder re-direction. This is when the user is not using roaming profiles but certain configuration folders within the user profile are re-directed on file servers. If any of the following folders are re-directed, and credential roaming is enabled, the user can also face unexpected results.
Note
This issue does not occur in Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008. Folder redirection in these operating systems automatically excludes the listed folders.
Organizations that have to use both roaming user profiles and credential roaming at the same time should configure an exclusion list in Group Policy for the roaming folders required for credential roaming.
Note
The directory exclusion should be configured together with the CSC Group Policy to ensure that the right directories are excluded when the credential roaming configuration applies the first time.
If you have already deployed roaming profiles, you can safely configure the exclusion, and credential roaming will work as expected. Even if certificates already exist in a roaming profile, they are not updated in the roaming profile anymore if the following directories are excluded from the roaming profile. However, existing certificates in the roaming profile are uploaded into the Active Directory object of the current user and continue to roam from that point on.
The exclusive list can be configured through the Group Policy Object Editor. The applicable setting is called "Exclude directories in roaming profile" and is found under the following container in the Group Policy Object Editor MMC Snap-In: User Configuration\Administrative Templates\System\User Profiles/p>
To configure the Group Policy exclusions list setting, add the following directory names as a single line to your exclusion list policy.
The following paths must be excluded from roaming for computers running earlier Windows versions than Windows Vista.
- Application Data\Microsoft\Crypto
- Application Data\Microsoft\Protect
- Application Data\Microsoft\SystemCertificates
Although it is possible to detect that a user has a roaming profile, it is not possible to detect that an exclusion list is in place. Therefore, it is not possible for the Certificate Services Client–Credential Roaming provider to detect whether the user is using a safe configuration. The Certificate Services Client–Credential Roaming provider will function even if a user has a roaming profile, and assumes that the administrator has created an exclusion list.
Installing the Group Policy ADM Template on a Windows Server 2003 Computer
The administrative template is not part of the default Windows Server 2003 installation. You must add the script manually.
To add the script manually: Download the DIMS.adm file from the Microsoft Web site at
To add the DIMS.adm file to Group Policy
On the computer that you are going to configure Group Policy for DIMS, log on with permissions to maintain group policies. By default, a domain administrator has this permission.
Make the DIMS.adm file available to the computer that you want to configure Group Policy for the Certificate Services Client–Credential Roaming provider.
Open the Active Directory Users and Computers MMC Snap-In by clicking the Start button, and then clicking Run. Type dsa.msc, and then press Enter.
Depending on the OU where you want to apply the Certificate Services Client–Credential Roaming provider configuration settings, select the appropriate OU in the left pane, right-click, and then select Properties.
With the Properties window open, click the Group Policy tab.
Select an existing policy or create a new one, then click Edit.
IIn the left pane, expand User Configuration\Administrative Templates.
Note
Make sure that you have selected the User configuration container. If you add the template to the computer configuration, the Certificate Services Client- Credential Roaming container will not appear under the Administrative Templates container.
Right-click Administrative Templates, and then select Add/Remove Templates. /li>
Click Add.
NNavigate to the folder where the DIMS.adm file is located. Select the DIMS.adm file, click Open, and then click Close. Certificate Services Client–Credential Roaming will now appear as a template under Administrative Templates.
Repeat the previous steps for every Group Policy where you want to configure Credential Management Services.
Removing the administrative template at a later stage does not change or disable the configuration for credential roaming. To disable the credential roaming configuration, see "Deleting Roaming Credentials from Active Directory"./p>
Configuring Group Policy for Credential Roaming
The Credential Management Services policy can be configured using the Group Policy Object Editor. In environments where there are multiple different operating systems, you should always use the most recent operating system version of the Group Policy Object Editor to make changes.
Due to the implementation history of the Certificate Services Client–Credential Roaming provider, the availability of settings in the Group Policy user interface has changed two times. The majority of settings that were available in the administrative template in Windows Server 2003 SP1 were removed from later versions of the template to avoid interoperability issues.
User Interface Label |
Available in Windows XP or Windows Server 2003 Group Policy Object Editor |
Available starting in Windows Vista or Windows Server 2008 Group Policy Object Editor |
Roam all using strict arbitration rules Description This setting applies strict arbitration rules to resolve conflicts between the local certificate store and the Active Directory object of the current user. If conflict resolution must be performed, the stronger protected certificate wins. Applies to Sets a bit in the DIMSRoaming registry key. Respected on Only respected on computers running Windows Server 2003 SP1. All other Windows versions ignore this setting. |
Only available in the administrative template that was published at the same time as Windows Server 2003 SP1. Not exposed in the current ADM template. |
Not available Will disable existing setting |
Roam all X.509 certificates and keys Description Windows XP and Windows Server 2003 computers will roam any DSA or RSA keys together with certificates. In Windows Vista, keys that use the ECC algorithm are also roamed. Applies to Sets a bit in the DIMSRoaming registry key. Respected on This setting is respected on all Windows versions that support Credential Management Services. |
Only available in the administrative template that was published at the same time as Windows Server 2003 SP1. Not exposed in the current ADM template. |
Not available Always roam all certificates and keys |
Roam encryption certificates and keys only Description Select this option if you do not want to roam certificates where the private key is not marked as AT_SIGNATURE. To find out the capabilities of a private key, see "Verifying the Key Specification of a Given Certificate". Applies to Sets a bit in the DIMSRoaming registry key. Respected on This setting is respected on all Windows versions that support Credential Management Services. |
Only available in the administrative template that was published at the same time as Windows Server 2003 SP1. Not exposed in the current ADM template. |
Not available Always roam all certificates and keys |
Roam encryption only with strict arbitration Description Signing certificates are excepted from roaming. For all other certificates, strict arbitration is used to resolve synchronization conflicts. If a conflict occurs, the stronger protected certificate wins. Applies to Sets a bit in the DIMSRoaming registry key. Respected on This setting is only respected on Windows Server 2003 SP1 computers. All other Windows versions ignore this setting. |
Only available in the administrative template that was published at the same time as Windows Server 2003 SP1. Not exposed in the current ADM template. |
Not available Will disable existing setting |
Roam CredMan Credentials Description All credentials that are maintained with credential manager are roaming between Windows Vista computers. Applies to Sets a bit in the DIMSRoaming registry key. Respected on This setting is only respected on Windows Vista computers. All other Windows versions ignore this setting. |
Not available |
Not available Always roam all certificates and keys |
Maximum tombstone credentials lifetime in days Description This setting controls when a credential marked for deletion is finally deleted from an Active Directory object. Applies to Sets the DIMSRoamingTombstoneDays registry key. Respected on This setting is respected on all Windows versions that support Credential Management Services. |
Yes |
Yes |
Maximum number of roaming credentials per user Description This setting controls how many credentials a user might have until credential roaming stops working. Applies to Sets the DIMSRoamingMaxNumTokens registry key. Respected on This setting is respected on all Windows versions that support Credential Management Services. |
Yes |
Yes |
Maximum size (in bytes) of a roaming credential Description This setting defines the upper size limit in bytes for a roaming credential. Applies to Sets the DIMSRoamingMaxTokenSize registry key. Respected on This setting is respected on all Windows versions that support Credential Management Services. Warning You should never reduce the MaxTokenSize once you have enabled a Group Policy for credential roaming. For more information about the DIMSRoamingMaxTombstoneDays client registry key, see the warning in Client Registry Keys. |
Yes |
Yes |
In a an environment with multiple different operating system versions, you must not add the administrative template for credential roaming if you are maintaining group policies on computers starting with Windows Vista or Windows Server 2008. Since the built-in policy for X.509 certificate and key roaming configures exactly the same registry keys as the former administrative template, you do not need to have the administrative template to configure the policy properly.
Configuring the DIMS Group Policy on a Windows Server 2003 or Windows XP ComputerConfiguring the DIMS Group Policy on a Windows Server 2003 or Windows XP ComputerAfter the DIMS.adm file has been added to Group Policy, you have to configure the actual settings. NOTE: Use the latest DIMS.adm file.
To configure the settings
- In the Group Policy Editor, with the Administrative Templates folder open, select Credential Management Services.
- In the right pane, select and right-click Credential Roaming, and then click Properties.
- Under Credential Roaming, click Enabled.
- Enter the Maximum tombstone credentials lifetime in days, Maximum number of roaming credentials per user, and the Maximum size (in bytes) of a roaming credential.
- When you are finished, click OK.
- Close the Group Policy Object Editor.
- To accept the new domain Group Policy settings properties and close Active Directory Users and Computers, click OK. New domain Group Policy settings are not applied to clients until a Group Policy update has been completed— typically every eight hours.
Configuring Group Policy for Credential Roaming Starting with Windows Vista or Windows Server 2008 Computers
Group Policy for credential roaming has become a core part of Group Policy starting in Windows Vista and Windows Server 2008. Therefore, the Group Policy Object Editor maintains the configuration for credential roaming in the user's security settings container. Starting in Windows Vista or Windows Server 2008, a dedicated administrative template for the Certificate Services Client–Credential Roaming provider is no longer required.
If you have a mixed environment where you have created previously Group Policy on a computer running Windows XP or Windows Server 2003, you will still see the administrative template for the Certificate Services Client–Credential Roaming provider together with the built-in setting.
In the following screen shot, the Group Policy Object Editors starting in Windows Vista or Windows Server 2008 will also show the administrative template if the policy was previously configured on a Windows XP or Windows Server 2003 SP1 computer.
The Roam stored usernames and passwords setting controls whether stored user names and passwords are roaming between client computers running on Windows Vista or later Windows versions. In a mixed environment, computers that are running earlier Windows versions than Windows Vista ignore this setting. In Windows 7 roaming usernames and passwords was removed from credential roaming. When CR is enabled, only the user’s Windows Vista machines will roam user names and passwords stored in their Credential Manager with each other. It is possible to roam user names and passwords on Windows 7 using Roaming User Profiles (RUP) and turning off credential roaming. When RUP and credential roaming are both enabled on Windows 7 usernames and passwords are not roamed by RUP. For more information please see the KB article KB2607862
To configure the Certificate Services Client–Credential Roaming provider policy starting on a Windows Vista computer
- Log on to the computer with permissions to manage the previously created Group Policy for DIMS clients.
- To open the MMC, type mmc.exe at a command-line prompt, and then press Enter.
- On the MMC menu, click File, and then click Add/Remove Snap-In.
- From the list of available snap-ins, select Group Policy Object Editor, and then click Add. The Group Policy Wizard opens.
- Click Browse to select the CSC policy that was previously created.
- Select your Credential Management Services policy, click OK, and then click Finish. Click OK to close the Add or Remove Snap-Ins dialog box.
- In the MMC Snap-In, in the left pane, expand User Configuration, Windows Settings, Security Settings, and then Public Key Policies.
- In the right pane, select X.509 certificate and key roaming. On the MMC menu, click Action, and then click Properties.
- In the X.509 certificate and key roaming Properties, select Roam stored usernames and passwords, and then click OK.
- Close the MMC Snap-In and log off. The new setting will apply to all Windows Vista client computers according to their Group Policy update cycle.
Verifying the Certificate Management Services Group Policy at a Client
There are various ways to verify the local Certificate Services Client–Credential Roaming provider configuration at a client. The most common way to examine the configuration is by looking in the registry. Use regedit.exe or the following command on any Windows computer that supports the Certificate Services Client–Credential Roaming provider to retrieve the configuration from the registry.
reg query HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment /s
On a computer running Windows Vista, you can also use the Resultant Set of Policy (rsop.msc) to examine the Certificate Services Client–Credential Roaming provider configuration. Regardless of whether the administrative template or Group Policy that is built into Windows Vista and later Windows versions was used to configure the policy, the configuration information is always found in the User Configuration, Windows Settings, Security Settings, Public Key Policies, Certificate Services Client–Credential Roaming.
Note that neither the Resultant Set of Policy nor gpupdate on Windows XP SP2 or Windows Server 2003 SP1 is able to show the actual configuration values for the Certificate Services Client–Credential Roaming provider property. The recommended way to verify the client configuration on these systems is to look in the registry.
If you expect a different client behavior than the actual configuration mirrors, do the following:
• Perform a gpresults /v command at a client computer to see which credential roaming configuration applies and where it comes from.
• Once you have determined the Group Policy that has the credential roaming configured, verify the policy. If you have Windows Vista available, use this client for the verification.
• Verify the settings under User Configuration, Windows Settings,Security Settings, Public Key Policies, and Certificate Services Client – Credential Roaming, and make sure that there is no classic Administrative Template for Client. Configuring the credential roaming feature through the built-in and classic user interface will cause configuration conflicts.
Deploying Group Policy for Credential Roaming
Before deploying Group Policy to enable credential roaming for client computers, it is highly recommended that you plan the estimated growth of the Active Directory database.
Every item that is able to roam with Credential Management Services needs to be stored in a user object. This causes growth of the user object.
The following table shows estimated sizes of tokens. Remember that the size of certificates will vary depending on the attributes that are part of a certificate. You may have to examine the sizes of customized certificates by yourself. One way to determine the size of a certificate is to export it to a file with the Certificate Manager MMC Snap-In.
Item |
Size |
512-bit RSA key |
Approximately 1 kilobyte (KB); the size may vary depending on the CSP |
1024-bit RSA key |
Approximately 1.5 KB; the size may vary depending on the CSP |
2048-bit RSA key |
Approximately 2 KB; the size may vary depending on the CSP |
Certificate |
Approximately 2 KB; the size will vary depending on the number of attributes and the information stored in the attributes. A long distinguished name or common name will extend the size of a certificate, for example. |
Certificate request |
Approximately 1 KB; the size will vary depending on the amount of information stored in the certificate request. A long distinguished name or common name will extend the size of a certificate, for example. |
DPAPI master key |
388 bytes for local user accounts 664 bytes for domain accounts on Windows XP 740 bytes for domain accounts on Windows Vista |
DPAPI Preferred file |
24 bytes |
Store username and password |
Approximately 400 bytes |
Before deploying credential roaming, you should carefully calculate the amount of data that will be added to your Active Directory domain environment. The following formula provides an upper-bound calculation of how much data your domain controllers have to handle when credential roaming is enabled. The result of the formula is the amount of data in kilobytes that will be stored in Active Directory. The actual amount of data can be less if certificate renewal uses existing key material and it can be more if filtering is turned off. In the case where filtering is turned off you will have to add the DPAPIPreferredFile to the calculation below and account for smartcard certificates, DPAPI keys that do not protect a roamed private key and other keys that are not associated with certificates.
(((CertificateSizeInByte + KeySizeInByte) * (#UserCertificates * #PastCertificateRenewals * #Machines) + (DPAPIkey * ProfileAgeInYears * 4)) / 1024
Formula Parameters Description
Formula Value |
Description |
CertificateSizeInByte |
This parameter represents the size of a certificate. Calculate the sum of certificate sizes if a user has multiple certificates. |
KeySizeInByte |
This parameter represents the size of a key. Calculate the sum of key sizes if a user has multiple keys. |
#UserCertificates |
This is the number of certificates that users hold. Users may have enrolled for more certificates than the number of certificate templates for which they have enrollment permissions if manual enrollment was performed. |
#PastCertificateRenewals |
This parameter represents the number of certificate renewals. If you have different renewal intervals, you have to calculate the total number of certificates for each certificate type individually. |
#Machines |
This is the number of computers users log on to while certificate roaming is enabled. After enabling certificate roaming, Certificate Management Services will synchronize any locally existing certificates with the user's Active Directory object. |
DPAPIkey |
The DPAPIkeySizeInKByte is 664 or 740 bytes. |
ProfileAgeInYears |
The age of a user profile has an impact on the number of DAPI master keys that exist. A new DPAPI master key is generated every 90 days so that four DPAPI master keys are created per year. |
DPAPIPreferredFile |
The DAPIpreferredfile has a fixed size of 24 bytes. |
You also have to consider that the byte amount of roaming credentials applies per user so that you have to multiply the amount per user by the number of users that are participating in credential roaming. Imagine that if you have deployed a certificate for EFS, one for S/MIME encryption, and one for S/MIME signing per user two years ago. The default validity time of a certificate is one year. You assume a profile age of three years. An average user was logged on to two computers in this example. Since the number of stored user names and passwords is a bit unpredictable, you assume 10 stored user names and passwords per user.
((2048 + 1536) * (3 * 2 * 2) + (664 * 3 * 4) ) / 1024 = 49.7 Kbyte per user (rounded)
If you deploy Group Policy for credential roaming at a domain level to 10,000 users, during the logon hours between 7 A.M. and 9 A.M., for example, approximately 497 MB of roaming credentials have to be carried by your domain controllers. Also, consider the additional Active Directory replication traffic that will occur.
Depending on your domain controller infrastructure, it might be a wise to deploy Group Policy to enable credential roaming in parts. Even if applied at a domain level, you can use a security group or a WMI query to control the appliance of Group Policy.
Note: The amount of roaming data will grow slowly when new certificates are enrolled and new DAPI master keys are created.. However, since these events trigger over time, heavy load on the domain controllers is not expected. With filtering enable you minimize the number of DPAPI Keys you roam if you roam all at once.
Changes after Credential Roaming is Configured
This section provides important information about a changed system behavior after credential roaming has been enabled. Ensure that you understand these implications properly.
Certificates That Use a CNG Key Provider Are Roamed to Windows XP or Windows Server 2003 Computers
Credential roaming usually avoids roaming of certificates that are associated with a CNG key provider to Windows XP or Windows Server 2003 computers. This functionality is based on the information that is available in the certificate's key properties.
If a certificate has no key proprieties and, thus, is not associated with a private key, the credential roaming code cannot determine the key or cryptographic service provider that was used. If no provider information is found, the default Microsoft Enhanced Cryptographic Provider 1.0 is assumed. That might cause unintended roaming of certificates that have been created with a CNG provider. A Windows XP or Windows Server 2003 computer will receive such a certificate but can do nothing with it. Further, if auto-enrollment was configured, the auto-enrollment code will set the archive bit on such a certificate so that it is hidden from the user since it cannot be used for encryption or signing operations anyway.
Certificates That Are Generated with RSA or DSS Certificate Service Providers Are Unexpectedly Archived
In the case where you have multiple enterprise CAs that have a certificate associated with a RSA/DSS or CNG key, you may unexpectedly see user certificates that carry the archive bit.
This situation can occur if the following conditions are met.
- You have at least two enterprise-issuing CAs in your forest where one CA has a certificate that was generated with a CSP (like the Microsoft Enhanced Cryptographic Provider 1.0) and one CA where the certificate is associated with a CNG key, like ECC.
- Both enterprise CAs issue certificates from a template where a CSP, like Microsoft Enhanced Cryptographic Provider 1.0, is configured.
- The user is configured to enroll a certificate using a CSP through auto-enrollment.
- Auto-enrollment of the user certificate occurs on a Windows Vista or Windows Server "Longhorn” computer.
- Certificate roaming is enabled for the user so that the certificate roams from the Windows Vista or Windows Server "Longhorn” computer to a Windows XP or Windows Server 2003 computer.
- Auto-enrollment is configured for the user. In this case, the auto-enrollment code on a Windows XP or Windows Server 2003 computer will not be able to verify the certificate chain of the user certificate because it does not know how to build a chain that contains a CNG certificate. The auto-enrollment code will set the archive bit on the certificate.
- The auto-enrollment code on Windows XP will determine that, for the given certificate template, no valid certificate exists. A new certificate is requested from a (non-CNG) CA that carries a certificate that is understood by Windows XP or Windows Server 2003.
IIf all of the previous conditions are met, the user will have two certificates and two keys for the same purpose. However, the certificate that was issued from the CNG CA is archived.
Note
To avoid this issue, you should not issue certificates that use a CSP from a CA that carries a CNG certificate. In a mixed environment, issue CNG certificates from a CNG CA, and RSA/DSS certificates from a CA that carries a certificate that was created with a CSP.
Smart Card Certificates Become Available in a Different User Profile
In certain scenarios, it will happen that certificates that are stored on a smart card start roaming into a different user profile. To cause such a situation, the following conditions must be met.
- The smart card of Alice sticks in the smart card reader, which is available in Windows.
- Bob is using Alice's workstation to perform an interactive logon with its user name and password
In this case, the CSC will read the certificates (not the private keys) from the smart card and publish them into Bob's personal certificate store even if the certificates belong to Alice. If Bob has credential roaming configured, Alice's certificates will start roaming with her user profile. Without having credential roaming in place, the same behavior will occur except that the certificates do not roam with Alice's profile unless she has a roaming profile.
TThe same issue will happen if Bob logs on to a terminal server session while Alice is still logged on and the smart card reader is mapped through the terminal server client. In this case, Bob is not locally logged on to Alice's computer but Bob's terminal server session will have access to the certificates which are stored on the smart card. Again, Alice's smart card certificates will become available in Bob's user profile and will start roaming if credential roaming was configured.
Note
Users who often log on to an interactive session through a terminal server, while their smart card is mapped through the terminal server client, should not have credential roaming configured—especially if different user credentials are used to log on. Otherwise, credentials that are stored on a smart card will roam unnecessarily and unintended throughout Active Directory.
Decommissioning Credential Roaming
IIf you have deployed credential roaming in your Active Directory environment, there may also be the requirement to stop credential roaming for the entire domain or a certain OU.
Decommissioning credential roaming comprises two steps.
- Disable Group Policy for credential roaming.
- Delete roaming credentials from Active Directory.
These two steps must be performed in order. If you do not disable Group Policy before cleaning Active Directory, the credentials from any local certificate store where the client logs on will come back to Active Directory.
Deactivating Group Policy for Credential Roaming on a Windows Server 2003 or Windows XP Computer
If you maintain Group Policy for credential roaming from a Windows XP or Windows Server 2003 computer, the only choice to disable credential roaming is through the administrative template.
If you are using a shared Group Policy that also consists of other configuration settings than those for credential roaming, follow these steps to deactivate credential roaming.
TTo deactivate credential roaming
- Log on to a domain computer with permissions to configure Group Policy that has the configuration settings for credential roaming. /li>
- Open the Active Directory Users and Computers MMC Snap-In by clicking the Start button, and then clicking Run. Type dsa.msc, and then press ENTER.
- Depending on the OU where you want to apply the credential roaming configuration settings, select the appropriate OU in the left pane, right-click, and then click Properties.
- With Properties open, click the Group Policy tab.
- Select the policy that should be deactivated, and then click Edit.
- In the left pane, expand User Configuration\Administrative Templates.
- With Administrative Templates open, select Credential Management Services. If you are using an old version of the DIMS.adm file, the container is named Certificate Services Client.
- In the right pane, select and right-click X.509 certificate and key roaming. Click Properties.
- Under X.509 certificate and key roaming, click Disabled.
Deactivating Group Policy for Credential Roaming
As mentioned previously, the policy for credential roaming is a core part of the Security Settings in the Group Policy Object Editor in Windows Vista or later Windows versions. Therefore, the way to deactivate credential roaming in Group Policy settings is slightly different than in previous Windows versions.
TTo disable credential roaming in group policies from a computer running Windows Vista
- Log on to a Windows Vista, Windows 7, or Windows 8 computer that is a domain member with permissions to configure Group Policy that has the configuration settings for credential roaming. /li>
- Start the Group Policy Object Editor MMC Snap-In by clicking the Start button, and then clicking Run. Type mmc.exe, and then press ENTER.
- In the Group Policy Object Editor, click Add/Remove Snap-In on the File menu.
- In the list of available snap-ins, select Group Policy Object Editor, and then click Add.
- Use the Browse button to select the Group Policy Object that contains the configuration for credential roaming. Click Finish, and then click OK.
- In the MMC Snap-In in the left pane, expand the Group Policy Object, User Configuration, Windows Settings, Security Settings, and Public Key Policies.
- In the right pane, select X.509 certificate and key roaming, and then click Properties on the Action menu.
- On the General tab, set the policy to Disabled.
Deleting Roaming Credentials from Active Directory
IIt might be the case that Credential Management Services was accidentally enabled for a user group where it was not intended to roam credentials.
In this case, you must use the ldifde.exe command to remove the Credential Management Services specific attributes from the Active Directory user objects.
Disclaimer: The following step-by-step instructions are not supported under any Microsoft standard support program or service. The instructions are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the step-by-step instructions and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the instructions be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the instructions or documentation, even if Microsoft has been advised of the possibility of such damages.
To remove roaming credentials from a specific user object
Log on as domain administrator to a Windows Server 2003 computer since the ldifde.exe command is not available on Windows XP or Windows Vista. /li>
To determine the common name of the user, open Active Directory Users and Computers MMC Snap-In by typing dsa.msc at a command-line prompt, and then press ENTER.
Search for the user and make a note of the user name as it appears in the Name column.
Open a command prompt.
At the command-line prompt, type the following command as a single line, and then press ENTER.
- **ldifde.exe -f dimsdelete.ldf -r "(cn=USERNAME)" -l dn **
- You must replace USERNAME with the name that was noted in step three. You can specify any valid LDAP filter at the -r parameter. Use the optional -s parameter with a fully qualified host name to connect to a dedicated domain controller.
The command will create the dimsdelete.ldf text file that looks like the following sample output.
- dn: CN=u1,OU=DIMS,DC=child,DC=contoso,DC=com
- changetype: add
Use Notepad to open the dimsdelete.ldf file.
Edit the file as follows:
- Replace the word add with modify.
- Append the following lines to the existing text.
- delete:msPKIAccountCredentials
- -
- delete:msPKIRoamingTimeStamp
- -
- delete:msPKIDPAPIMasterKeys
- -
Verify that your modified dimsdelete.ldf file looks like the following sample.
- dn: CN=u1,OU=DIMS,DC=child,DC=contoso,DC=com
- changetype: modify
- delete:msPKIAccountCredentials
- -
- delete:msPKIRoamingTimeStamp
- -
- delete:msPKIDPAPIMasterKeys
- -
To perform the actual delete operation, type the following command as a single line, and then press ENTER.
- ldifde.exe -i -f dimsdelete.ldf
To verify that the attributes have been deleted, use the following command.
- ldifde.exe -f dimsverify.ldf -r “(cn=USERNAME)” -l msPKIAccountCredentials,msPKIRoamingTimeStamp,msPKIDPAPIMasterKeys
- Note: You must replace USERNAME with the user name you want to verify.
The dimsverify.ldf file should not show any values for the DIMS–specific attributes.
To delete the Credential Management Services–specific information from multiple user objects, you can extend the ldf- file in such a way that a delete section exists for every user as shown in step 9. Note that you have to add two empty lines before every line that starts with "dn:".
You could also use an ADSI script to perform the deletion. For a script sample about how to modify certain attributes of a user object, see Using the LDIFDE Utility..
Troubleshooting
This section discusses methods that you can use to verify and resolve credential roaming issues.
Verifying the Key Specification of a Given Certificate
The key specification may not match the actual key usage that is set in a certificate. For example, if you look to a certificate, the key usage attribute may show Key Encipherment; however, looking closer at the key properties, you will discover that the key can also be used for signing operations (AT_KEYEXCHANGE).
Key properties are defined when a key is generated. If the application that calls the certificate service provider sends the wrong key properties to the CSP, key properties and the key usage attribute can mismatch.
To examine the key usage attribute and the key property for a given certificate, you should use the certutil command, which is part of the Windows Server administrative tools and also part of Windows Vista.
To examine the key usage attribute and the key property for a given certificate
To dump all certificates including the key properties that are available in your current user certificate store, perform the following command at a command-line prompt.
certutil -v -store -user My > mystore.txtYou may see a window popping up that asks for the pass phrase which protects the private key or you are asked for the PIN if you have certificates that are stored on a smart card. Hit the ESC key to cancel these dialogs, since you don't have to have access to the private key to read the key properties.
Once the command has finished, open the mystore.txt file in Notepad.
Search for 2.5.29.15 in Notepad to find the Key Usage attribute as specified for Certificate 0.
Once found, make a note of the Key Usage attribute, such as Key Encipherment or Digital Signature.
Search for KeySpec, which is part of the CERT_KEY_PROV_INFO_PROP_ID section. The KeySpec is represented as a hexadecimal value. Make a note of the KeySpec value.
Open the Microsoft Windows Calculator. Make sure that Scientific is enabled in the View menu.
Click the Hex button, and then enter the previously remembered KeySpec value.
Click the Bin button to convert the hexadecimal value to a binary value.
If the right-most digit is a 1, the key can be used for encryption operations (AT_KEYEXCHANGE).
If the second digit from the right is 1, the key can be used for signing operations (AT_SIGNATURE).
Compare the KeySpec with the Key Usage attribute and make sure that both match logically. For example, a certificate with Key Usage equal to Code Signing should have an associated key with KeySpec equal to AT_SIGNATURE.
Verifying Which Credentials Are Stored in the Local Credential Manager Store
The user interface that maintains stored user names and passwords is difficult to find in Windows. The easiest way to open credential manager is with the following case-sensitive command.
rundll32.exe keymgr.dll,KRShowKeyMgr
Credentials Do Not Become Available on a Computer at All
If you are missing certificates that were available on the computer you were previously logged on to, but those certificates are not available at your current computer, perform the following verifications.
Make sure that the credential roaming Group Policy was applied to the local computer. To do this, open the registry editor and verify if the keys (described in Client Registry Keys) exist. If they do not exist, you have to fix a Group Policy problem.
Verify if there are any credentials available in the user's Active Directory object. Use ADSIedit or ldifde.exe to look at the right attributes that are stored in the user's Active Directory object. For verification, use the following command as a single line at a command-line prompt as Domain Administrator on a Windows Server 2003 computer.
ldifde.exe -s %LOGONSERVER% -f cscverify.ldf -r "(cn=USERNAME)" -l
msPKIAccountCredentials,msPKIRoamingTimeStamp,msPKIDPAPIMasterKeys
Replace the word USERNAME in this command with the user name where credential roaming does not work. To ensure that Active Directory replication was already performed, use the -s option in the command and replace %LOGONSERVER% with the server the user actually logs on to. Make sure that the cscverify.ldf file shows values for the exported attributes.
If Group Policy has been applied, verify that the DIMSRoarmingMaxNumTokens and the DIMSRoamingMaxTokenSize registry keys are set properly. Make sure that those values are not set to small. If necessary, increase one or both values.
Verify that the CSC credential roaming provider has not put itself into system recovery mode. To do this, check the registry keys as described in "System Recovery".
Certificates Become Unusable or Renewed After an Export/Import Operation
A certificate will lose its association with the private key if the following conditions are met.
A certificate in the user's personal store that is associated with a private key is exported to a PKCS#10 file (CER or DER).
The same certificate is deleted from the personal store after it was exported. The private key remains on the system and continues to roam.
The certificate is imported in to the personal store again. At this stage, the certificate is not re-associated with the still existing key. This means that the certificate starts roaming independently from the key.
If auto-enrollment recognizes a certificate without a key associated in the personal store, it will mark the certificate as archived and try to re-enroll for a new certificate of the same type based on the template name in the certificate.
To re-associate a certificate with a key, you can use certutil with the -repairstore option.
To repair a certificate
Determine the serial number of the certificate that you want to repair. To see the serial number, double-click the certificate in the certmgr.msc MMC Snap-In.
At a command-line prompt, perform the following command.
certutil -user -repairstore My "{Serialnumer}"
For example:
certutil -user -repairstore My "1dca482e000000000098"If the certificate was not generated with the default Microsoft Enhanced Cryptographic Provider 1.0, you must also specify the name of the CSP as an command-line option.
FFor example:
certutil -user -CSP " Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider" -repairstore My "1dca482e000000000098"
List of Certificates in the Certificate Manager and Internet Explorer Is Different
Windows provides several mechanisms to manage certificates. One common interface is the certificate management in Microsoft Internet Explorer; another one is the Certificate Manager MMC Snap-In itself.
You may see differences between the certificates in the Personal user certificate store if you use both interfaces. Certificate manager shows all certificates in the Personal store—regardless of whether they have an associated private key. In contrast, the certificate management in Internet Explorer shows only those certificates that have an associated private key. If you have imported certificates into the user's Personal store, you will see fewer certificates in Internet Explorer than in the Certificate Management MMC Snap-In. For more information, see the Microsoft Knowledge Base article at
http://support.microsoft.com/?id=305833
Best Practices
Work to do: Copy from http://technet.microsoft.com/en-us/library/cc700812 and update here
Terminology
| Abbreviation | Description |
| CSC | Certificate Services Client is a core part of Microsoft® Windows® that manages certificate handling, like certificate enrollment, including auto-enrollment and credential roaming. |
| Certificate | An X.509 certificate is a digital file that can be used for various secure operations such as data signing or encryption. For more information about certificates, see "How Certificates Work” at the Microsoft Web site http://technet2.microsoft.com/windowsserver/en/library/fb3df0cd-0aae-472b-9e9c-bb8ca878bc341033.mspx |
| Key | According to the X.509 standard, there is always a public and a private key. The public key is part of a certificate, while the private key is stored separately. Here, key refers to the private key. |
| Token | This term is used when data protection application programming interface (DAPI) master keys, the DPAPI Preferred File, certificates, private keys, or certificate requests are discussed in general. A token is a single unit that is maintained individually. |
| Stored user names and passwords | Account information that is maintained with credential manager is called stored user names and passwords in this white paper. |
| Credential | Tokens and stored user names and passwords are called credentials. This might not be completely consistent with other Microsoft documentation but is most suitable for this white paper. |
| CNG (Crypto Next Generation) | Next Generation (CNG) API is the long-term replacement for the CryptoAPI. CNG is designed to be extensible at many levels and cryptography agnostic in behavior. For more information, see the Microsoft Web site |
| DPAPI | This term refers to the Microsoft data protection API, which is documented in detail at http://msdn2.microsoft.com/en-us/library/ms995355 |
| DIMS | This is the former name of credential roaming; it translates to Digital ID Management Service. Credential roaming is now part of the CSC. You may continue to see the acronym "DIMS” because it is used in Windows code such as in file names, registry hives, and the Eventlog. |
| Software update | This is any update, update rollup, service pack (SP), feature pack, critical update, security update, or hotfix that is used to improve or fix a software product that is released by Microsoft Corporation. A Microsoft software update is accompanied by a Microsoft Knowledge Base article. For more information, see the Microsoft Knowledge Base article "Description of the standard terminology that is used to describe Microsoft software updates" at http://support.microsoft.com/?id=824684. |
Appendix
Work to do: Copy from http://technet.microsoft.com/en-us/library/cc700816 and update in this section