Product Documentation

Planning for Multiple Primary Authentication and User Credential Protection

Feb 06, 2011

When you create or edit a user configuration, you can select user credential protection methods depending on the authentication schemes you use in your enterprise.

The following user configuration property pages enable you to tune the Single Sign-on Plug-in software behavior and credential data protection method used when users implement one or more primary authentication methods.

Data Protection Methods Page

The user configuration Data Protection Methods properties page enables you to select single or multiple primary authentication data protection methods. Additionally, you can also regulate administrator access to user credential data to help prevent administrators from impersonating a user and gaining unauthorized access to user information.

Secondary Data Protection Page

For added security when users change their primary authentication (for example, a domain password is changed or smart card is replaced), the user configuration Secondary Data Protection properties page enables you to require users to reauthenticate and verify their identities before unlocking their application credentials.

Security Versus Usability

Two key questions to ask when deciding which options to choose on these two user configuration property pages is:
  • Which authentication types are used in my environment for the users I am administering in this user configuration?
  • How can I balance security requirements for the enterprise and usability for all users?

Consider also that the following choices are not mutually exclusive and that you can use a mix of them in your enterprise (that is, multiple primary authentication). Your decision is ultimately based on your need for security versus ease-of-use for your enterprise users.

User Impersonation

If you want to disallow administrator access to user credentials, select Yes for the Do you need to regulate account administrator access to user data? option. Credentials are protected against administrators seeking to impersonate a user and to gain access to user information.

Yes is the default setting for the Data Protection Methods page. With this configuration, the account or other administrator does not have access to user passwords or user data. This setting helps prevent an administrator from impersonating a user. The administrator cannot log on as the user with this default setting and possibly access data located in the user local credential store.

The Yes setting disables the use of the Microsoft Data Protection API option on this page and the Do not prompt users; restore primary data protection automatically option on the following Secondary Data Protection page. Smart cards and roaming profiles are not allowed in this case, and credentials are not restored automatically upon a password change without authentication or verification.

Select No if you want to allow use of all the multiple authentication features available from this page and the Secondary Data Protection page (including the ability to restore credentials automatically without reauthentication or identity verification).

User Name and Password

The simplest implementation is the default setting for the Data Protection Methods page: a password-only environment. The default setting lets your users employ their user name and password while protecting their credentials against unauthorized access by administrators.

Important: The security of this setting choice depends on the relative strength of your domain password policy. The stronger (or more complex) the password requirement, the more secure this choice is.
Option Description
Do you need to regulate account administrator access to user data? See User Impersonation.
Users authentication data Selected. A user secret is used to access and help protect user data. In this case, the user secret is a password. Password security can be derived from the user’s typed domain password or a one-time password from token, proximity, or biometric devices.

Smart Cards with Certificates and User Authentication Data

Use Smart Cards Certificate and Users' authentication data if you combine smart cards with embedded certificates or digital signatures and user authentication data in your enterprise. Combining smart cards with a user name and password for authentication is the most secure choice for protecting user authentication data.

Select the Smart Card Certificate option if you use smart cards with Hot Desktop.

To use smart cards in a Windows Server 2008 or Windows Vista environment, your central store must be created with or updated by a Single Sign-on 4.5 (formerly Password Manager) or later console and Microsoft Data Protection API (requires roaming profiles) must be selected in your user configurations.

Option Description
Do you need to regulate account administrator access to user data? See User Impersonation.
Users' authentication data Selected.

A user secret is used to access and help protect user data. In this case, the user secret is a password.

Password security can be derived from the user’s typed domain password or a one-time password from token, proximity, or biometric devices.

Smart Card Certificate Selected.

In this case, the user secret is protected by the encryption and decryption provided by the card’s security certificate.

Smart Cards with PINs

If you use smart cards that do not support security certificates as the primary authenticator in a Windows domain or you do not use roaming profiles, use the Allow Smart Card PINs option. When you select this option, the encryption keys used to protect secondary credentials are derived from the smart card PIN.

Consider enforcing the use of a strong PIN. In some enterprises, smart card PINs are four-digit numbers that do not provide as strong a level of protection as, for example, an eight-character password and might be more vulnerable to attack. Use the PIN as password option only if your organization enforces a smart card PIN policy that requires a mixture of letters and numbers, and requires a minimum length of eight characters.

Option Description
Do you need to regulate account administrator access to user data? See User Impersonation.
Users authentication data Selected. A user secret is used to access and help protect user data. In this case, the user secret is a personal identification number (PIN).
Allow Smart Card PINs Selected. Allow the Smart Card PIN to be used as the user secret for protection. Use this only if your enterprise or environment has a “strong PIN” policy

This option is supported by Version 4.1 of the Single Sign-on (formerly Password Manager) plug-in if you select Use data protection as in Single Sign-on 4.1 and previous versions and PIN as password, if you plan to use legacy plug-ins.

Roaming Profiles (Microsoft DPAPI)

Select No in response to Do you need to regulate account administrator access to user data? to enable the use of the roaming profiles and Microsoft Data Protection API in your environment. This option is the next-most secure option after smart cards with certificates and user authentication data.

Select this option if you are using roaming profiles implementing a Kerberos network authentication protocol for users. This option works only if roaming profiles are available. If you are storing roaming profiles on workstations, you must select this option.

Single Sign-on derives the encryption keys that protect secondary credentials from the user’s primary password. However, if a user uses a smart card for primary authentication, a primary password does not exist and cannot be used. In this case, the best plug-in option is Microsoft Data Protection API. This option uses the Microsoft DPAPI to derive encryption keys and protect secondary credentials. This encryption mechanism uses the user’s Windows or domain credentials to derive the encryption keys.

If users employ passwords to access their computers and a Kerberos network authentication protocol to access XenApp servers, select:
  • No in response to Do you need to regulate account administrator access to user data?
  • Users authentication data
  • Microsoft Data Protection API

This method also allows the use of user credentials and smart cards to log on.

To use smart cards in a Windows Server 2008 or Windows Vista environment, your central store must be created with or updated by a Single Sign-on 4.5 (formerly Password Manager) or later console and Microsoft Data Protection API (requires roaming profiles) must be selected in your user configurations.

This method is supported by Version 4.1 of the Single Sign-on Plug-in and is supported on Windows XP and Windows 2003 Server platforms. Select Use data protection as in Single Sign-on 4.1 and previous versions and DPAPI with Profile if you plan to use legacy plug-ins.

Blank Passwords

Allowing the use of a blank password should be considered a special case and should only be used in low security environments that require extreme ease of use. One scenario is when a common workstation is placed on a factory floor and is accessed by many users. You can still use Single Sign-on to control access to applications but the user credentials to access the workstation include a blank password.

Important: If you do not select this option and a blank password is allowed in your environment, the plug-in software does not derive a user secret or otherwise perform any data protection with the blank password.
Option Description
Do you need to regulate account administrator access to user data? See User Impersonation.
Users authentication data

Selected.

A user secret is used to access and help protect user data. In this case, the user secret is a password.

Allow protection using blank passwords

Selected.

When you select this option and the plug-in software detects that the user has a blank password, a user secret for data protection is derived from the user ID.