Click to Rate and Give Feedback
TechNet
TechNet Library
Security Guidance
Client Security
 Configuring and Troubleshooting Cer...

  Switch on low bandwidth view
Implementation Differences Between Windows Server 2003 SP1, Windows XP SP2, Windows Vista, and Windows Server 'Longhorn'
Configuring and Troubleshooting Certificate Services Client–Credential Roaming

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.

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

 

Windows Server 2003 SP1

Windows XP SP2 software update, Windows Server SP1 software update

Windows Vista/Windows Server "Longhorn"

Identity Roaming

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

Last writer wins

No

Yes

Yes

Implementation

Part of Winlogon

Yes

Yes

No

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.

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

Active Directory

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.

Not required

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

To maintain gender-equality, the names Alice and Bob are used in the following scenarios.

Accessing Secured Information from Multiple Computers

This scenario is about accessing secured e-mail from multiple computers.

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

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

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

Figure 1: Certificate Roaming on Multiple Computers

Figure 1: Certificate Roaming on Multiple Computers.

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.

Figure 2 illustrates this scenario.

Figure 2: Credential Roaming in a Wireless Network Scenario

Figure 2: Credential Roaming in a Wireless Network Scenario

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.

For more information, see Smart Card Certificates Become Available in a Different User Profile.

Related Links

© 2009 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement
Page view tracker