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*.
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.
Click
. The Preferences Properties table is displayed.In the
column, go to and select the appropriate preferences.Click
.Click
.The following sections explain the various security preferences:
The
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 , 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.
Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Protocom\SecureLogin
Set the DWORD value of FindCertificateRetryNumber to:
Set the DWORD value of FindCertificateRetryInterval to:
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
o option is set to then the option is dimmed and not available.If
is set to , then the option is available and defaults to .If you select
, the user's smart card is not required for single sign-on and administration operations.If you select
, the user's smart is required for single sign-on and administration operations.If the
option is selected, this option is set to . Alternatively, the user's credentials inherit the option set by the higher-level container.IMPORTANT:Any changes to the
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
option for (SecureLogin Administrative Management utility > > options.)Use the
option to select how user credentials are stored.Figure 8-3 Storing User Credentials on Smart Card
If you select
, the user's credentials are stored in the user's local (off-line) cache.If you select
, 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
option is selected, the user's credentials are stored in the user's local (off-line) cache as with the option. Alternatively, the user's credentials inherit the option set by the higher-level container.NOTE:You can manually disable inheritance of higher-level options by selecting the
option for (SecureLogin Administrative Management utility > > options.)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
, 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
, 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
, users must answer with a passphrase before data can be decrypted and reencrypted by using AES.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
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
, all other smart card options are dimmed and not available.If you select
, 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
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
under the following circumstances: First, you change the option to , then you change the option to , and finally change the option to . If you do this, then both the and R are set to .You should set these preferences in the following order:
Set the
to .Set the
option to .Click
.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
option should be set to or to prevent the loss of the user's single sign-on credentials if a user loses a card.If PKI credentials are used to encrypt single sign-on data and the passphrase security system is set to
, 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.
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.
The
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
, then the and finally the 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
isCN=IssuingCA1,OU=AD,DC=undiscovered,DC=com
Then IssuingCA1 is a valid search value, as are AD, undiscovered, and com.
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