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

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.

For more information about certificate stores, under the "Local Certificate Storage" heading, see
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/3f5fdc52-8623-4336-840d-e90b2399c854.mspx

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
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/e3525d00-a746-4466-bb87-140acb44a603.mspx

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

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.

Definition of Credentials

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.

Thus, Windows Server 2003 SP1 and Windows XP SP2 with the credential roaming software update support five items, while Windows Vista supports six items with credential roaming.

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 "Longhorn" and are configured for roaming if they are available on the local computer.

• DPAPI Preferred file – 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.

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.

Figure 3 illustrates the components of credential roaming.

1. A user logs on to a domain-joined workstation.

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

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

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

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

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

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

Important  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 "Longhorn"

The WinLogon has been redesigned 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) (Figure 4).

For more information about how Microsoft Windows Management Instrumentation (WMI) notification works, see the Microsoft Web site at
http://msdn.microsoft.com/msdnmag/issues/01/09/AppLog/default.aspx

dimsjob.dl l registers to the following Task Scheduler events.

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.

A special situation may occur if a user has logged on to multiple computers and left copies of tokens in the local user profile while some tokens have also been deleted in some of the local profiles. The CSC is smart enough not to let tokens reappear in the Active Directory object of a user even if the tombstone time is over and the user logs on to a computer that still has a local copy of a certificate that was previously deleted on a different computer.

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.

1. Initially, credential roaming is not enabled for Bob's user account.

2. Bob is enrolled for a certificate on his workstation. The private key security is set to Normal and the key is flagged as Exportable.

3. Bob exports the certificate and the related private key into a file.

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

5. Credential Management Services is enabled for Bob's user account through Group Policy.

6. Bob logs on to his workstation. CSC starts and uploads the certificates into his Active Directory user object.

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

1. Retrieve the creation time from the ms-PKI-RoamingTimeStamp attribute from the Active Directory object of the current user.

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

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

4. The DIMSRoaming registry key is retrieved to have either the lenient (default) or strict bit set.

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

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

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

8. The other container is physically left on the system, but becomes orphaned.

Conflict Resolution in Windows Vista

Windows Vista fully supports Suite-B algorithms. This is achieved by having CNG stack in parallel to the current CryptoAPI (CAPI) stack. The credential roaming feature in Windows Vista and Windows Server "Longhorn" 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:

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

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

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

4. The user logs on to machine B and the credentials are uploaded to Active Directory.

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

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

   2. The key pair (container) on machine A is also uploaded to Active Directory.

   3. The key pair (container) that was uploaded by machine B is also downloaded.

6. The user then logs back on to machine B.

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

   2. The key pair (container) that was uploaded by machine A is also downloaded by machine B.

7. The result is that

   1. On both the machines, the certificate points to the container that originally belonged to machine A. The key is password-protected and exportable.

   2. 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 in Windows Vista

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

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.

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

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

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

4. If attempts to read the state file fail even after multiple retries, the read will fall back to the backup copy.

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

6. If the attempt to write the state file fails, a registry entry is updated to indicate that roaming changed to the self-healing state.

7. 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\KeyRoamin g registry key.

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.

Top Of Page

Related Links

• Understanding credential roaming
• Using credential roaming

Top Of Page