8.3 Configuring SecureLogin for Smart Cards

No two organizations have the same environment and requirements, SecureLogin includes a number of options that determine SecureLogin's behavior, such as how single sign-on data is encrypted (that is, using the smart card or a passphrase question and answer) and how to handle scenarios such as lost cards.

To configure the preferences, use the iManager in eDirectory environments, MMC plug-in for Active Directory environments, and SecureLogin Manager in LDAP v3-compliant directories such as Sun*, Oracle*, and IBM*.

  1. Access the Administrative Management utility of Novell SecureLogin.

    For information on accessing the Administrative Management utility see, Section 1.2, Starting the Administrative Management Utilities and, or, Section 1.3, Accessing the Single Sign-On Plug-In Through iManager.

  2. Click Preferences. The Preferences Properties table is displayed.

  3. In the Setting Description column, go to Security and select the appropriate preferences.

  4. Click Apply.

  5. Click OK.

The following sections explain the various security preferences:

8.3.1 Requiring a Smart Card for SSO and Administration Operations

The Require smart card is present for SSO and administrative operation option determines if a user's smart card must be present before allowing a single sign-on session or administration function. This option also checks to see if a smart card has been removed after the start of a single sign-on session, which prevents the swapping of smart cards to copy a user’s credentials.

Figure 8-2 Requiring a Smart Card for SSO and Administration Operations

If the smart card is removed after the single sign-on session has started, and then reinserted, the card serial number is checked to validate that the card now being used is the same card used to initiate the single sign-on session.

For a new user if the credentials are stored on smart card with the certificate selection criteria is set as a friendly name, SecureLogin fails to launch. It displays a message indicating that, The smart card does not contain any certificates that match the certificate selection criteria is displayed. The user is forced to click OK, log out and log in again with either smart card or username.

This occurs because when a new user log in to Windows for the first time, Windows tries to set up the user’s desktop. So, there is a delay in propagating the certificate from the smart card to the local store. As a result, the certificates are not available when SecureLogin launches and there is a delay in launching SecureLogin.

To launch SecureLogin successfully on the first attempt, change the value of FindCertificateRetryNumber and FindCertificateRetryInterval registries. These registries allow SecureLogin to retry finding certificate in the local store in a fast user switching environment or slow Windows startup.

The FindCertificateRetryNumber registry controls the number of times SecureLogin retries for the certificate. The FindCertifcateRetryInterval registry specifies the interval (milliseconds) to wait between each try.

  1. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Protocom\SecureLogin

  2. Set the DWORD value of FindCertificateRetryNumber to:

    If set to

    Then

    4

    Novell SecureLogin installer sets the value to four during installation.

    This means that SecureLogin tries four times with default interval of four seconds in between each try.

    1

    Set the value to 1 to stop the retry.

    This is also the minimum number of retries.

    This is also the default behavior if the setting is removed from the registry.

    360

    This is the maximum number of retries.

    SecureLogin reverts to this value if the value specified in the registry is greater than the maximum retries.

  3. Set the DWORD value of FindCertificateRetryInterval to:

    If set to

    Then

    5000

    This is default value if setting is not specified in the registry.SecureLogin installer does not populate this setting during installation.

    6000

    The maximum value for the interval.

    SecureLogin reverts to this value if the value specified in the registry is greater than the maximum.

SecureLogin launches successfully on subsequent logins because Windows is not required to set up the user desktop and the certificate propagation happens before SecureLogin launches.

NOTE: If the Lost card scenario option is set to Allow passphrase, then the Require smart card is present for SSO and administration operations option is dimmed and not available.

If Lost card scenario is set to Require smart card, then the Require smart card is present for SSO and administration operations option is available and defaults to Yes.

If you select No, the user's smart card is not required for single sign-on and administration operations.

If you select Yes, the user's smart is required for single sign-on and administration operations.

If the Default option is selected, this option is set to No. Alternatively, the user's credentials inherit the Require smart card is present for SSO and administration operations option set by the higher-level container.

IMPORTANT:Any changes to the Require smart card is present for SSO and administration operations preferences requires SecureLogin to be closed and restarted before the changes takes effect.

You can manually disable inheritance of higher-level options by selecting the Yes option for Stop walking here (SecureLogin Administrative Management utility > Preferences > General options.)

8.3.2 Storing User Credentials on Smart Card

Use the Store User credentials on smart card option to select how user credentials are stored.

Figure 8-3 Storing User Credentials on Smart Card

If you select No, the user's credentials are stored in the user's local (off-line) cache.

If you select Yes, the user's single sign-on credentials, including usernames and passwords, are stored on the smart card in a secure PIN-protected container. Although credentials are stored on the smart card, other single sign-on data, including application definitions and preferences, are stored in the user's local cache on the hard drive.

If the Default option is selected, the user's credentials are stored in the user's local (off-line) cache as with the No option. Alternatively, the user's credentials inherit the Store credentials on smart card option set by the higher-level container.

NOTE:You can manually disable inheritance of higher-level options by selecting the Yes option for Stop walking here (SecureLogin Administrative Management utility > Preferences > General options.)

8.3.3 Using AES for SSO Data Encryption

This option determines the level and standard of encryption used to encrypt single sign-on data stored on the smart card by allowing the use of AES instead of triple DES.

Figure 8-4 Using AES for SSO Data Encryption

If you select No, a 168-bit key used with triple DES (EDE) in Cipher-Block Chaining (CBC) mode is used to encrypt the user's single sign-on credentials.

NOTE:The input key for DES is 64 bits long and includes 8 parity bits. These 8 parity bits are not used during the encryption process, resulting in a DES encryption key length of 56 bits. Therefore, the key strength for Triple DES is actually 168 bits.

If you select Yes, then a 256-bit key used with AES (EDE) in CBC mode is used to encrypt the user's credentials.

If a previous version of SecureLogin has been implemented with passphrases enabled and if this option is set to Yes, users must answer with a passphrase before data can be decrypted and reencrypted by using AES.

8.3.4 Using a Smart Card to Encrypt SSO Data

SecureLogin 6.1 offers various encryption options. By default, SecureLogin encrypts data using either a user-defined passphrase key or a randomly generated key. The Use smart card to encrypt SSO data option can be used to determine whether PKI credentials or the self-generated key are stored on the smart card and then used to encrypt the user's single sign-on data.

Figure 8-5 Using a Smart Card to Encrypt SSO Data

If you select No, all other smart card options are dimmed and not available.

If you select PKI credentials, single sign-on data is encrypted by using the user's PKI credentials. Single sign-on data stored in the directory and in the offline cache (if enabled) is encrypted by using the public key from the selected certificate, and the private key (stored on a PIN protected smart card) is used for decryption.

If you select Key generated on smart card option, single sign-on data is encrypted by using a randomly generated symmetric key that is stored on the user's smart card. This key is used to encrypt and decrypt single sign-on data stored in the Directory and in the offline cache (if enabled).

NOTE:It is possible to inadvertently set these options to Require smart card under the following circumstances: First, you change the Use smart card to encrypt SSO data option to PKI credentials, then you change the Lost card scenario option to Require Smartcard, and finally change the Require Smart Card is present for SSO and administration operations option to Yes. If you do this, then both the Lost card scenario and Require smart card for SSO and administration operations are set to Require smart card.

You should set these preferences in the following order:

  1. Set the Store credentials on smart card to No.

  2. Set the Use smart card to encrypt SSO data option to PKI credentials.

  3. Click Apply.

  4. Close and then reactivate SecureLogin. Check to see if the options are correctly set.

When a smart card is deployed with a user's PKI credentials, consider using key escrow, archiving, and backup through an enterprise card management system for the user's private key to be recovered in a lost card scenario. If no escrow is used, the Enable passphrase security system option should be set to Yes or Hidden to prevent the loss of the user's single sign-on credentials if a user loses a card.

8.3.5 Using PKI Encryption for the Datastore and Cache

If PKI credentials are used to encrypt single sign-on data and the passphrase security system is set to No, you should consider implementing a key archive for backup and recovery. If this system is not implemented and the passphrase security system is not enabled, users can never decrypt their single sign-on data if they lose a smart card, because the private key is stored on the smart card and is not recoverable.

Without private key recovery, if the user loses his or her smart card, the single sign-on administrator must clear the user’s single sign-on data store and reset the back-end password before the user is able to use single sign-on again. This is a high security solution, but is more inconvenient to end users because they cannot have single sign-on access without the smart card.

For more information, refer Section 8.5.7, Using a Card Management System.

Choosing a Certificate

When a smart card is configured to use PKI credentials to encrypt single sign-on data, SecureLogin retrieves the serial number of the current certificate and locates the certificate in the certificate store as specified in the relevant SecureLogin preferences.

Figure 8-6 Choosing a Certificate

SecureLogin then loads the associated private key (which might cause a PIN prompt), and attempts to decrypt the user key with the private key.

In cases where the decryption fails or the certificate cannot be located but a smart card is present and a certificate that matches the selection criteria can be located, SecureLogin assumes that the recovered smart card is in use. SecureLogin the attempts to decrypt the user key with each key pair with the key pair stored on the card.

8.3.6 Certificate Selection Criteria

The Certificate Selection Criteria option allows you to select an encryption or authentication certificate to encrypt user's single sign-on information in the directory.

Figure 8-7 Certificate Selection Criteria

The certificate selection criteria determine which certificate to select if multiple certificates are in use (for example, if an enterprise has configured an Entrust* certificate for single sign-on encryption and a Microsoft certificate for login and or, authentication).

If only one certificate is used, the field is blank and the certificate is detected automatically and set to User Certificate. When entering certificate selection criteria, no special formatting is required and the search string is not case sensitive. Wildcards are not used and a search matches if the search text is a substring of the certificate subject field. SecureLogin attempts to match against the Certificate Subject, then the Certificate Issuer and finally the Friendly Name in that order.

Example 8-1 For example if the subject is

CN=Writer,OU=Users,OU=Accounts,OU=APAC,DC=Novell,DC=Int

Then Writer is a valid search value, as are Accounts, APAC, and Int. The prefixes CN=, OU=, or DC= are not required.

Similarly, if the Certificate Issuer is

CN=IssuingCA1,OU=AD,DC=undiscovered,DC=com

Then IssuingCA1 is a valid search value, as are AD, undiscovered, and com.

Current Certificate

This option displays the certificate that is currently being used by SecureLogin to encrypt a user’s single sign-on data.

Figure 8-8 Current Certificate