SecureLogin includes a number of options that determine SecureLogin's behavior, such as how SSO 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 MMC snap-in for Active Directory environments, ConsoleOne® for iManager in eDirectory™ environments, for SecureLogin Manager in LDAP v3-compliant directories such as Sun*, Oracle*, and IBM*.
Access the Administrative Management Utility of SecureLogin.
For more information on how to access the Administrative Management Utility, see Section 1.2, Administrative Management Utility and Section 1.3, Accessing the SSO 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
determines if a user's smart card must be present before allowing an SSO session or administration function. This option also checks to see if a smart card has been removed after the start of a SSO session, which prevents the swapping of smart cards to copy a user’s credentials.If the smart card is removed after the SSO 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 SSO session.
If you select
, the user's smart is not required for SSO and administration operations.If you select
, then the user's smart is required for SSO and administration operations.If the
option is selected, then this option is set to . Alternatively, the user's credentials inherit the option set by the higher-level container.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 the .Figure 7-1 Smart Card Detection
Use the
option to select how user credentials are stored.If you select
, the user's credentials are stored in the user's local (off-line) cache.If you select
, the user's SSO credentials, including user names and passwords, are stored on the smart card in a secure PIN-protected container. Although credentials are stored on the smart card, other SSO data, including application definitions and preferences, are stored in the user's local cache on the hard drive.If the
option is selected then the user's credentials are stored in the user's local (off-line) cache as per the option. Alternatively, the user's credentials inherit the option set by the higher-level container.Figure 7-2 Store Credentials on Smart Card
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 SSO data stored on the smart card by allowing the use of AES instead of triple DES.
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 SSO 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 cane be decrypted and reencrypted using AES.Figure 7-3 Use AES for SSO Data Encryption
SecureLogin 6.0 SP1 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 SSO data.If you select
, SSO data is encrypted using the user's PKI credentials. SSO data stored in the directory and in the offline cache (if enabled) is encrypted 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, SSO data is encrypted using a randomly generated symmetric key that is stored on the user's smart card. This key is used to encrypt and decrypt SSO 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:
IMPORTANT:You should always set the
to or and apply the setting before you change the option is set to .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, then the
option should be set to or to prevent the loss of the user's SSO credentials if a user loses a card.For more information, refer Section 7.6, Using a Card Management System.
Figure 7-4 Use Smart Card to Encrypt SSO Data
If PKI credentials are used to encrypt SSO 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 SSO 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 SSO administrator must clear the user’s SSO data store and reset the back-end password before the user is able to use SSO again. This is a high security solution, but is more inconvenient to end users because they cannot have SSO access without the smart card.
For more information, refer Section 7.6, Using a Card Management System.
When a smart card is configured to use PKI credentials to encrypt SSO data, SecureLogin will retrieves the serial number of the current certificate and locates the certificate in the certificate store as specified in the relevant SecureLogin preferences.
SecureLogin then loads the associated private key (which may cause a PIN prompt), and attempts to decrypt the user key with the private key.
In cases where the encryption fails or the certificate cannot be located but a smart card is present and a certificate that matches the selection criteria can be located, then 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.
Figure 7-5 Selecting a Certificate
The
option allows you to select an encryption or authentication certificate to encrypt user's SSO information in the directory.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 SSO encryption and a Microsoft* certificate for log on and/or authentication).
Figure 7-6 Certificate Selection Criteria
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 7-1 For example if the subject is
CN=Daniel,OU=Users,OU=Accounts,OU=APAC,DC=Novell,DC=Int
Then Daniel is a valid search value, as are Accounts, APAC, and Int. The prefixes CN=, OU=, or DC= are not required.
Similarly, if the
is,CN=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 SSO data.
Figure 7-7 Current Certificate