Configuring and Troubleshooting Certificate Services Client–Credential Roaming
This section clarifies a number of technical terms that are used throughout the white paper.
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
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
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
This white paper is about certificate, key, and stored user names and password roaming in Microsoft Active Directory domain environments. It is assumed that every computer that participates in identity roaming is a domain member.
A growing number of managed environments rely on certificates to secure critical transactions such as signing, encrypting, and decrypting e-mail or authenticating identity on wireless networks. But many organizations require users to log on to and use more than one computer. For example, a user logs on to the following:
Multiple workstations, as in the case of nurses and doctors in hospitals.
A portable computer and one of more workstations, as in the case of consultants and sales people.
A variety of servers, workstations, and portable computers, as in the case of network administrators.
By default, Windows creates a local user profile once a user logs on to a computer for the first time. When a user logs on to a computer again, the existing local profile is reused to set the desktop environment, certificates, private keys, and all other user-specific configuration.
Thus, a typical managed user who has been issued certificates automatically for signing e-mail, encrypting and decrypting documents, and authentication may suddenly have separate sets of certificates and private keys on each computer's local profile. Two local profiles that have been created by the same user but on different computers may contain totally different configuration information. In that case, Windows would interpret both profiles of the same user in the same way as the profiles would belong to two different users.
For example, instead of having to manage three certificates per user, administrators can suddenly be faced with managing six, nine, or even more certificates issued to the same user. Every different set of certificates would be stored in a different local user profile. Users who use a private key stored in a local profile on one computer may end up using separate keys on other computers that they log on to. And if the user leaves the organization, each set of certificates needs to be revoked and added to a certificate revocation list. This system behavior might cause a certificate management burden and decrease overall usability.
Also, if key recovery was not configured, a user may lose certificates and keys if a local user profile gets lost. In that case—even if encrypted data is still accessible to the user—there is no way to access the data once the private key and the encryption certificate are lost.
Until now, the only option available in managed environments was to use roaming user profiles or smart cards to move a single set of certificates and private keys to whatever domain-joined computer a user is logged on to. Both solutions are very expensive from a deployment and maintenance standpoint. Also, roaming user profiles involve more data, more scalability issues, more network traffic, and more time than is acceptable if an organization only wants to make a handful of certificates available on different client computers. In addition, roaming user profiles do not meet the high security requirements associated with user credentials.
Ideally, administrators should not have to issue and manage multiple sets of certificates for each user. Users should not have to enroll for a new set of certificates every time they log on to a different domain-joined computer. Applications that are dependent on X.509 certificates should be able to rely on Active Directory to make these certificates available on any domain-joined Windows computer the user logs on to. And above all, the certificates and private keys that are available for roaming will always remain secure, whether stored on a local computer, in Active Directory, or while transmitted across the network.
The new credential roaming functionality solves these problems by making it possible to roam only the user's credentials in a manner that is extremely secure, easy to implement and manage for administrators, and transparent to the user.
Important Credential roaming has some requirements regarding the domain controller and client infrastructure. Because of security reasons, credential roaming is recommended in pure Microsoft Windows Server® 2003 SP1 domain controller environments. Any computer that runs on Microsoft Windows XP SP2 or Windows Server 2003 SP1 and has the credential roaming software update installed is running Microsoft Windows Vista™ or Windows Server "Longhorn" is able to maintain certificates as a Credential Management Services client.
CSC, which includes credential roaming, has a very tight integration with Active Directory and group policies for security and management functionality. Therefore, Active Directory is the only directory service that works with the CSC. You cannot use Lightweight Directory Access Protocol (LDAP) services like Active Directory Application Mode (ADAM) with the CSC.
About Credential Roaming
Until now, user certificates and private keys in Microsoft Windows® 2000 and later Windows versions have become part of the user profile after they are issued and placed in the user's certificate store. Unfortunately, from a roaming standpoint, a user profile can consist of much more information, for example, application data, such as documents and spreadsheets, and system configuration data, such as a user's Favorites and Start menu. This causes the profile to become very heavy. User profiles can easily exceed 50 megabytes (MB). Also, a user profile can be accessed by any person with the appropriate administrative power. This enables administrators to reclaim a user's data, for example, if they leave the organization. In addition, roaming profiles are based on a file server model, which makes them vulnerable if the server becomes unavailable or is compromised.
Digital certificates and private keys involve comparatively small amounts of data that needs to be stored in a secure manner. With the credential roaming functionality in the CSC, managed environments can now store X.509 certificates, certificate requests, and private keys specific to a user in Active Directory, independently from the profile.
The credential roaming implementation in Windows Vista™ and Windows Server® "Longhorn" is additionally able to roam stored user names and passwords. Users typically maintain stored user names and passwords of certain Web sites or file servers that do not have a default trust relationship with the user's computer. With credential roaming, once a domain user chooses in a Windows authentication dialog box to cache or 'remember' the current credentials, the user will have the same experience on any domain-joined computer that the user logs on to. For more information about managing stored user names and passwords, see the Microsoft Knowledge Base article "How To Manage Stored User Names and Passwords on a Computer in a Domain in Windows XP” at
A user Group Policy enables downloading credentials to a local computer whenever a domain user logs on, and it maintains its integrity under any conditions, such as when credentials are updated locally and when users log on to more than one computer at a time. Credential roaming just keeps the user's local credentials in sync with the credentials stored in the Active Directory object of the current user.
Besides Credential roaming, Certificate Management Services is also responsible for certificate auto-enrollment.