The Lost Card Scenario preference determines how SecureLogin handles a user forgetting, losing, or damaging a smart card. The Lost Card scenario preference can only be used if, the Enable passphrase security system preference is also enabled (set to either Yes or Hidden).
NOTE:For users upgrading from SecureLogin version 5.5, setting Enable passphrase security system to Hidden is equivalent to setting the old Disable passphrase security system to Off.
If a smart card is used to encrypt single sign-on data and the card is lost, stolen, or damaged. Also, if the key archive/backup and recovery is not used, the user will not have access to their single sign-on data unless the Enable passphrase security system preference is set to Yes or Hidden.
If Enable passphrase security system is set to Yes, the user has previously set a passphrase, and Lost card scenario is set to Allow Passphrase, then the user is prompted to answer with his or her passphrase before SecureLogin is available.
If Enable passphrase security system is set to Hidden, the user is not prompted for the answer and SecureLogin loads seamlessly.
This preference allows the user to start SecureLogin using their passphrase if their smart card is not available. The Enable passphrase security system preference must be set to Yes or Hidden for this to work. Hidden replaces a user-generated passphrase with a system-generated passphrase, effectively removing the need for the user to remember the passphrase answer.
IMPORTANT:For the user to decrypt data using their passphrase, the passphrase must already have been set. Administrators cannot simply toggle the Enable passphrase security system preference on the day the user forgets their smart card unless the user has previously set a passphrase (or had it randomly generated using Hidden).
NOTE:Administrators can manually disable inheritance of higher level preferences by selecting the Yes option for Stop walking here in the SecureLogin Administrative Management Utility, Preferences – General options.
The default preference is to allow the user to start SecureLogin using their passphrase, unless it inherits a Lost card scenario preference from a higher-level container.
The Require smart card preference prevents a user from starting single sign-on without his or her smart card. This option is for high security implementations where organizations want to tie the use of a user's single sign-on credentials to the user's smart card. This means that the user cannot access single sign-on with any other method; that is, they cannot use a username and password without the smart card.
IMPORTANT:If the Require smart card option is changed while the user is logged in, refreshing the cache using the Advanced > Refresh Cache option from the taskbar does not refresh the Lost card scenario option.
The user must log out and log in again (or restart SecureLogin) for the new option to take effect.
The Allow passphrase preference must be used in conjunction with the Enable passphrase security system option. It allows the user to start SecureLogin by using a passphrase if the smart card is not available. The passphrase security system must be set to Yes or Hidden for this setting to apply.
The Hidden option replaces a user-generated passphrase with a system-generated passphrase, effectively removing the need for the user to remember the passphrase answer.
IMPORTANT:For the user to decrypt data using a passphrase, the passphrase must already be set. You cannot simply toggle the Enable passphrase security system setting to on the day the user forgets a smart card unless the user has previously set a passphrase (or had it randomly generated by using the Hidden option).
The Default option allows the user to start SecureLogin by using a passphrase if the smart card is not available through the Allow Passphrase preference. Alternatively, this option inherits the Lost Card scenario preference set by the higher-level container.
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.)
There is another option available that permit access if a user loses or forgets his or her smart card. For example, If a user loses or forgets his or her smart card and the Lost card scenario option is set to Require smart card, you can grant temporary access to systems by resetting the user's password. The user is then required to log in and enter the passphrase. This option is possible only if the Enable passphrase security system is turned on.
However, the user should not expect easy or automatic access to the system. Users should understand that, a strong and secure solution has been implemented and that they have the responsibility of looking after their own smart cards.
Enterprise server or web-based card management system (CMS) software enables corporations to implement and easily manage smart card-based identity management, provisioning, and authentication devices and enforce policy across geographically-dispersed locations.
These systems provide a complete and flexible solution to manage the issuance, administration, and configuration required for the successful and seamless smart card integration.
NetIQ CMS provides a complete and flexible solution to manage the issuance, administration and configuration required for a successful and seamless smart card integration with SecureLogin and Smart Card Password Login (SCPL). It can be configured to perform key escrow, archive and recovery as described throughout this document.
The use of a CMS is crucial if an enterprise opts to deploy corporate smart cards with a very high level of security. This would include disabling the Enable passphrase security system preference combined with Store credentials on smart card (set to Yes) and Use smart card to encrypt SSO data (set to PKI credentials or Key generated on smart card).
In the event of a lost or damaged smart card, the user can never decrypt their single sign-on data because the key stored on the smart card is not recoverable.
You must then reset the user's corporate passwords and issue a new smart card (with a new key pair) before the user can log in and reconfigure the single sign-on applications using SecureLogin again.
The user must manually enter all application credentials into SecureLogin the first time he or she logs in after the data was cleared from the directory.
Enterprises should consider implementing key escrow, archiving, or backup through a suitable CMS to allow a user's encryption key to be recovered in the event of a lost or damaged smart card.
It is recommended that you extensively test the CMS and smart card restoration techniques before selecting the high security options described above.
The procedure to reset a user’s data store is described in Deleting or Re-setting User Data.
If an enterprise opts to deploy corporate smart cards without a suitable card management system (CMS), you can still create a very high level of security by setting Enable passphrase security system to No and then selecting the Use smart card to encrypt SSO data preference to PKI credentials or Key generated on smart card. However, in the event of a lost or damaged smart card the user can never decrypt the single sign-on data because the key stored on the smart card is not recoverable.
WARNING:Deleting the user's single sign-on datastore permanently deletes the users data in the directory. This would include any local applications, credentials, preferences, and password policies that are not being inherited from some other object in the directory.
If you still decide to delete the user's existing single sign-on configuration data store, delete it from the Advanced Setting > Datastore tab of the user object in the directory management tool.
The administrator must then reset the user's corporate password and issue a new smart card (with a new key pair) before the user can log on and reconfigure their single sign-on enabled applications.
The user will have to re‑enter all their application credentials into SecureLogin the first time it is used after having them deleted from the directory.
If the Use smart card to encrypt SSO data preference is set to PKI credentials and Enable passphrase security system is set to No, then in the event of a lost or damaged smart card the user will never be able to decrypt the single sign-on data because the key stored on the smart card is the only key that can be used for decryption. This key is not recoverable unless key archiving and recovery was implemented.
If a CMS-based key archive is used, then the encryption key needs to be recovered to the new smart card, the single sign-on data unencrypted, and an administrator needs to chose a new certificate to encrypt the user’s data.
If you are using the enterprise CMS-based recovery system, you must issue the user a replacement smart card based on a CMS backup of the user's original key.
Similarly, if the Use smart card to encrypt SSO data preference is set to use Key generated on smart card, then in the event of a lost or damaged smart card the user can never decrypt the single sign-on data because the key stored on the smart card is not recoverable.
You should consider setting the Enable passphrase security system option to Yes when the Key generated on smart card option is used to provide an alternative mechanism for decrypting single sign-on data if the smart card is lost/stolen/damaged.
Using the enterprise CMS-based recovery system, the administrator must issue the user a replacement smart card based on a CMS backup of the user's original key. The replacement card includes the recovered private key and a new key pair so data can be decrypted using the old key and re-encrypted using the new key.