Considerations for implementing Credential Roaming

Credential Roaming is the replacement or alternative to using Roaming Profiles (or RUP - Roaming User Profiles). The biggest drawback to using RUP has always been that the profile tends to grow bigger as time goes by (raise your hand if you've ever saved a file on your desktop).

One of the primary reasons for using RUP has been to allow users to log on to different workstations or servers and let their credentials (certificates, keys, etc.) roam with them. using RUP with multiple workstations at the same time is however not a practical setup (you'll likely end up with conflicts when the two profiles get reconciled at logoff).

The workaround of using Folder Redirection to redirect the users' home folders, desktop and documents partially addresses the issue but the remaining challenge is how to get your certificates and keys to roam with the user. 
This is where Credential Roaming (CR) comes into the picture, as it allows you to roam credential data while using Local Profiles for users.

There are however, some caveats that should be considered before implementing Credential Roaming:

- The NTDS.dit database on your DC’s *will* grow.
Exactly how much it will grow will depend on how much credential data your users have and how many users you enable CR for.

- Many applications use relatively short-lived keys that will also be roamed by CR
They will be roamed while they are valid + the duration that you specify in Maximum Tombstone Credentials Lifetime in Days . This will increase as more applications start using CryptoAPIto store user data .

- The default limit for the amount of roamed credentials for each user is 128 Mb.
This is calculated from the default maximum amount of roamed credentials or tokens (DIMSRoamingMaxNumberTokens which defaults to 2000) multiplied by the default maximum size for each token (DIMSRoamingMaxTokenSize which defaults to 64k).

Modifying the defaults is certainly an option but you need to weigh the pros and cons of doing so and examine the current requirements of your users, set the values too low and Credential Roaming will stop for a user that reaches the limits.

A typical token today (public or private key) is around 2k, this will vary depending on key size and contents (see table below).  In addition to this, a new DPAPI master key will be created at every password change and this will roam as well.

Given the numbers above, it is not unreasonable to estimate that you could potentially be looking at an NTDS.dit growth (sometimes also referred to as NTDS.dit bloat) that could double or triple the current size of the Active Directory database on the DC’s if you enable Credential Roaming for all users and have applications that are heavy users of CryptoAPI.

Configuring and Troubleshooting Certificate Services Client–Credential Roaming
http://technet.microsoft.com/en-us/library/cc700848.aspx
Support Webcast: Credential Roaming Basics
http://support.microsoft.com/?id=935441

From http://technet.microsoft.com/en-us/library/cc700821.aspx:

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.

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, for example.

(((CertificateSizeInByte + KeySizeInByte) * (#UserCertificates * #PastCertificateRenewals * #Machines) + (DPAPIkey * ProfileAgeInYears * 4) + DPAPIpreferredfile + (#StoredUserNamesAndPasswords * 400)) / 1024

Formula Parameters Description

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) + 24 + (10 * 400)) / 1024 = 54 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 540 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, new DAPI master keys are created, or a user adds a stored user name with password to credential manager. However, since these events trigger over time, heavy load on the domain controllers is not expected.

Further reading:
http://blogs.technet.com/askds/archive/2009/01/06/certs-on-wheels-understanding-credential-roaming.aspx