Share via

Certs On Wheels: Understanding Credential Roaming

  • Article

Hi. Jim here again from the Directory Services team. Today I will break down some of the core components of credential roaming and how it functions. To secure critical transactions such as signing, encrypting, and decrypting e-mail or authenticating identity, many environments rely on certificates. The user certificates and the associated private keys are linked to the local profile on whatever machine the user logs onto. Let’s talk about the local user profile briefly. When a user logs onto a computer for the first time a local profile is created for that user. This profile sets the desktop environment, certificates, private keys, and all other user-specific configuration information. When the user logs back onto the same machine this profile is reused.

You can see where I am going here. What if the user logs onto multiple machines? In this scenario a user could end up having separate sets of certificates and private keys on each computer's local profile. Administrators would have to manage multiple certificates stored on multiple machines in multiple profiles. What if a profile on one machine gets deleted? What if that deleted profile contained certificates and private keys used to decrypt data? What if the user leaves the company? I hope you have key recovery configured.

Enter Credential Roaming –

Credential roaming functionality addresses these concerns by making it possible to roam only the user's credentials in a manageable, secure manner that is ultimately transparent to the user. For the purpose of this post we will only be discussing the roaming of certificates and private keys. The credential roaming implementation in Windows Vista and Windows Server 2008 is additionally able to roam stored user names and passwords. For more information on this go here - "How to Manage Stored User Names and Passwords on a Computer in a Domain in Windows XP” at:

https://support.microsoft.com/?id=306992

Remember, credential roaming only supports x.509 v3 certificates and RSA or DSA key pairs that are stored in the user’s credential store. Only credentials in the user’s MY and REQUEST stores are roamed.

Ok, Ok, enough already. Let’s get into how credential roaming works in a nutshell. What you need first is a functioning, healthy Active Directory environment. This is crucial as credential roaming relies on group policy, auto enrollment and healthy Active Directory and SYSVOL replication. Windows Server 2003 SP2 and XP SP3 both support credential roaming. The update below must be applied to XP SP2 computers as well as Windows Server SP1 machines to facilitate credential roaming.

907247 Description of the Credential Roaming service update for Windows Server 2003 and for Windows XP - https://support.microsoft.com/default.aspx?scid=kb;EN-US;907247

After you have verified you are running the correct versions of Windows and you have deployed the 907247 update, you can begin the initial configuration of credential roaming in your organization. In order to receive the script necessary to modify your Active Directory schema you must 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

https://support.microsoft.com/default.aspx?scid=kb;en-us;907247&sd=tech

I will not be covering the initial credential roaming configuration as the steps for configuration are explained here in exhaustive detail:

Configuring and Troubleshooting Certificate Services Client–Credential Roaming - https://technet.microsoft.com/en-us/library/cc700821.aspx

Once credential roaming functionality has been configured in your Active Directory environment, here is what happens on an XP computer with the 907247 update installed. This also assumes healthy active directory replication and successful group policy application in regard to credential roaming policy specifically.

1. A user logs on to a domain joined computer.

2. Group policy applies successfully and includes the policy setting for credential roaming.

Here is the location in the registry where the Credential Roaming Group Policy settings are written:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Cryptography\Autoenrollment
AEPolicy REG_DWORD 0x7
DIMSRoaming REG_DWORD 0x1
DIMSRoamingTombstoneDays REG_DWORD 0x3c
DIMSRoamingMaxNumTokens REG_DWORD 0x7d0
DIMSRoamingMaxTokenSize REG_DWORD 0xffff

3. Coinciding with Winlogon and Userinit.exe the dimsntfy.dll (which has been updated by the 907247 update) sets off an event to activate credential roaming. The dimsntfy.dll lives within the WINDOWS\system32 folder.

4. Also located in the WINDOWS\system32 folder, the Dimsroam.dll (also updated by the 907247 update) is the Key Roaming DIMS Provider DLL. The Dimsroam.dll is compelled by group policy to count the number of tokens in the local certificate store. The maximum number of tokens allowed to roam can be configured within the following credential roaming group policy setting.

image

If there are more tokens available then what is specified (In the above screenshot the default maximum of 2000 per user is set) credential roaming will not work. If the total number of non-tombstoned credentials plus tombstoned credentials is less than two times the number indicated in the group policy setting above, then the credential roaming series of events proceeds on its merry way.

(Non Tombstoned + Tombstoned) < 2000 x 2 = credential roaming works

(Non Tombstoned + Tombstoned) > 2000 x 2 = credential roaming fails

You do the math ; )

5. The local credentials of the user and the credentials within the Active Directory object of the user are compared against the state.dat file. The state.dat is the current state file. The state.da~ is the previous state file. When credential roaming reconciles new certificates from Active Directory to the local store and from the local store back up to Active Directory the state.dat file records those transactions. Each time this occurs the original state.dat file is renamed to state.da~ and a new state.dat is created. Both the state.dat and the state.da~ files are located here on a Windows XP machine:

C:\Documents and Settings\”username”\Local Settings\Application Data\Microsoft\DIMS

The security on this directory by default is as follows:

  DomainName\UserName: F (Full Control – Inherited)
  NT AUTHORITY\SYSTEM: F (Full Control – Inherited)
  BUILTIN\Administrators: F (Full Control – Inherited)

On a Vista machine, it is located here –

  %LOCALAPPDATA%\Microsoft\DIMS

Any modification to these permissions may affect the functionality of credential roaming. I will speak more of this in a forthcoming credential roaming troubleshooting post. I must also point out in regard to Vista that the NTDS.DIT file on domain controllers grows continually larger after enabling credential roaming for Windows Vista clients. Please see the following for information on the hotfix, or install Vista Service Pack 1 to proactively avoid this issue:

934797 - The size of the Ntds.dit file on the domain controller grows continually larger after you enable the "Credential Roaming" feature for Windows Vista-based client computers in the domain

https://support.microsoft.com/default.aspx?scid=kb;EN-US;934797

Let’s press on shall we…

If there has been a modification of the certificates in the local store or the user object in Active Directory, the changes are either downloaded to the store or uploaded to Active Directory.

The reconciliation of the local store with Active Directory and vice versa is handled by the dimsroam.dll. The private key material is encrypted the DPAPI key and all credential roaming communication between the computer and Active Directory is Kerberos encrypted.

The dimsroam.dll also deletes certificates that are older than the tombstone lifetime in days set in the credential roaming group policy. These certificates with an older tombstone are deleted from both Active Directory and the user’s local store. Any reference to them is also removed from the state.dat file. The Tombstone value should be a value long enough so that the user is able to logon to all machines that they use so that the certificate is deleted from all the respective local certificate stores upon logon. If this value is too low, then previously deleted certificates can be put back into the AD Credentials store and cause the certificate to be repopulated on all machines that the user logs onto.

image

6. The maximum size of the user object's credentials attribute is the result of the maximum number of tokens multiplied by the maximum token size. A user object can become large if there are a large number of tokens that also have a large token size. With certificates the token size will vary depending on the key size. The size above (65535) is default. It is conceivable that a user’s credential size would be larger than what is defined in the policy, thus causing credential roaming to fail for that user.

7. If auto-enrollment is configured in group policy the pautoenrol.dll kicks off AFTER credential roaming code is finished. This prevents auto-enrollment from taking place needlessly. If auto-enrollment was to take place before credential roaming it is conceivable that a user logging on to a different machine would enroll for a certificate already procured on another machine and waiting to be roamed.

The Dimsroam.dll will fire off the credential roaming series of events described to this point when the following occurs:

  • At user logon and logoff.
  • The user locks or unlocks the machine console.
  • certutil -user -pulse is performed at a Windows Vista or Windows Server 2008 command prompt.
  • A change is made to the user's local certificate store by removing a certificate from the personal store, importing a certificate to the personal store, manually enrolling for a certificate with the MMC or certreq.exe, receiving a new certificate via auto-enrollment and a group policy refresh.

In addition Credential Roaming also roams the DPAPI master keys. For more explanation of the Windows Data Protection API (DPAPI) go here. For group policy only there may be a latency of up to four hours before the certificate store is refreshed. This is by design and was introduced to reduce high load on domain controllers when group policy is updated or created. Like anything else, credential roaming deployments require careful consideration and testing before enterprise wide roll outs. Go here for more exhaustive information on all things credential roaming.

- Jim “Lord of the Strings” Tierney

Comments