Notes Shared Login-enabled IDs may be corrupted when using policy-mandated ID encryption

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:

(0 users)Average rating

Document information


More support for:

IBM Notes
Security

Software version:

8.5

Operating system(s):

Windows

Reference #:

1450471

Modified date:

2012-05-29

Translate my page

Machine Translation

Content navigation