User ID files may fail to synchronize with ID Vault for users who are enabled for Web Federated Login or Notes Federated Login
When SAML authentication is in use in an environment, some users may experience the issue described below if they also use Notes clients which use the Notes ID password for authentication, or if they have users accessing servers or internet sites running Traveler, which uses non-SAML authentication for accessing user mail files.
Users whose Notes passwords are set to synch with their HTTP passwords may find that their password changed in the Notes client successfully syncs to the web password, but the change is not synced as expected to the ID Vault, resulting in encryption and signing being unavailable due to a password mismatch when accessing the vault.
A user is accessing iNotes through SAML authentication, and is also accessing mail using Traveler. Additionally, the user has a Notes client with this ID. The user is able to successfully use the ID for encryption while in iNotes and also while in Traveler.
Then the user updates their password on the Notes client. Due to policy settings, the HTTP password is updated to the new Notes password.
Next, when the user accesses their mail through Traveler, using the new password, they cannot access the ID with the new password.
The user does not notice a problem when accessing the ID using SAML, as this bypasses the use of user IDs for accessing the vault, and uses a SAML assertion instead. Thus the user never enters their Notes ID password when encrypting mail in iNotes when SAML authentication is used. SAML authentication does not use the HTTP password used by Traveler, but instead uses the password set by the SAML identity provider.
When ID Vault is in use, the ID is automatically downloaded from the ID Vault, as opposed to using an ID file stored in the mail file. If a user's ID has not been successfully synchronized with the ID Vault, the password on a Notes ID may not be the same as the password of the copy in the ID Vault. The user may incorrect assume that an HTTP password that matches the new Notes password indicates everything was synchronized. Additionally, when SAML authentication is in use, the "synchronize with vault" action button in iNotes security preferences does not function as expected, and may erroneously report that synchronization was successful when in fact it was not.
Steps to reproduce.
1. Set up Domino to user SAML/Web Federated Login.
2. Register a user as an iNotes users and assign a security policy that implements, the users internet password being updated when the Notes password changes, ID Vault and Web Federated Login, with 'Enable Web Federated login with SAML IdP 'and 'Allow password authentication with the ID Vault' set to yes.
3. Set up two iNotes Internet Sites, one which uses SAML authentication and one which uses Single Server authentication.
4. Have the user log into the SAML enabled internet site and confirm that SAML authentication works correctly and the user can read an encrypted mail without being prompted for their Notes password.
5. Have the user log into the single server internet site and confirm that they are authenticated using their Internet password and the user can read an encrypted mail without being prompted for their Notes password.
6. Have the user log into their Notes client and change their password through File -> Security -> Users Security -> Change Password.
7. Open the Admin4.nsf and you will see that the "Change HTTP password in Domino Directory " request is generated and completed successfully for the user.
8. Have the user log back into their Notes client and confirm that the new Notes password allows them access.
9. Have the user log into the SAML enabled internet site, they will be able to read an encrypted mail without being asked to provide their Notes password.
10. Have the user log into the single server Internet Site with their new Internet password. The user is authenticated, however when they attempt to read an encrypted mail they will be prompted to provide their Notes password.
If the user enters their new Notes password they will not be able prompted again to enter their Notes password. The user has to enter their old Notes password in order to be able to read the email.
11. Have the user select Preferences -> Security -> Synch With Vault. The operation will report that it was successful, however the ID in the users mail file is not being updated with their new Notes password as they must still enter their old Notes password in order to read an encrypted mail.
Diagnosing the problem
Debugging parameters on the Sever side notes.ini;
If a Notes client user changes an ID password, he should verify that synchronization was successful by reviewing the client log's security events view. Synchronizations will be logged, and the user can verify if it was successful. If the client successfully synchs, the password on the vaulted ID should match that of the client.
The vault server will log to the console log if there are failed accesses to the ID Vault for access to a user ID. The iNotes server may record an error like the following when "Sync with Vault" fails:
Server Vault_Server/Corp reported the following problem causing authentication to fail: You are not authorized to perform this function on this server
Resolving the problem
If a user has an ID in vault for which they do not know the password, and the client is not syncing, then a new copy of the ID may be extracted from the ID Vault by an administrator, and the password can be set to the desired user password. This ID can then be used on a Notes client to synch the ID with the
updated password to the vault. Password changes on the newly downloaded ID should sync correctly with vault, but it is recommended to verify that this was successful by checking the client log.
The "Synch With Vault" action in iNotes should not be used by users who have SAML-enabled IDs in their environment.
An Enhancement Request (SPR # GFAL9ZBJVT / APAR #LO86013) has been opened to improve the reliability of ID Vault synchronization when there is a mix of SAML authentication and non-SAML authentication in a user environment.