Flash (Alert)
Abstract
IDs enabled for Notes Shared Login (NSL) can be corrupted if the NSL user is assigned to a policy that mandates an ID encryption level stronger than currently applied to the ID file.
Content
When NSL-enabled users are assigned to a policy that mandates an ID file encryption strength greater than what is currently applied to the user's ID, the ID file will become unusable. This occurs because the code that re-encrypts the user's ID to comply with the policy-mandated encryption strength is not NSL-aware and does not properly update the ID file.
As an example, an NSL user currently has 64-bit RC2 ID encryption. The user is then assigned to a policy that mandates 128-bit RC2 ID encryption. After the policy is assigned and the ID re-encrypted with 128-bit RC2, the ID file is unusable.
This condition has been reported to Quality Engineering as SPR #DJAG89QN7Q and is fixed in Notes/Domino 8.5.2 FP1.
Workaround:
To work around this problem, in the Security Settings document -> Mandated encryption standard field, set this to Select encryption standard from dialog list or ensure than the selected encryption standard matches the current standard applied in user mail files.
Note:
Note that this issue is related to another SPR #RPAI89AHD5, in which users who belong to an ID Vault have their ID encryption downgraded to 64-bit RC2 after synching with the vault. For users who are both enabled for NSL and belong to an ID Vault, ensure that you modify the policy encryption standard to either Select encryption standard from dialog list or 64-bit RC2.
SPR #RPAI89AHD5 is also fixed in Notes/Domino 8.5.2 FP1.
Rate this page:
Copyright and trademark information
IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.