How AdminQ key rollover requests are processed

When you initiate a Notes ID key rollover request from an ID vault Security Settings policy, the following steps occur to update the keys in the ID file of web user who has a vaulted ID.

Without AdminQ, the key rollover requires a web user such as an HCL Verse user to authenticate with Domino using an HCL Notes client to get the updated ID file.

Step 1 and Step 10 are the only steps that require an action on the part of the administrator.

The servers involved with the processing must run Domino 12.0.2 or higher and use the 12.0.2 or higher adminq.ntf design.

For a graphic depiction of these steps, see AdminQ key rollover illustration.

  1. On the domain administration server, the administrator follows the procedure Enabling key rollover to initiate a key rollover for users assigned to an ID vault Security Settings policy.
  2. The policy change in names.nsf replicates to the vault administration server.
  3. After midnight, AdminQ on the vault administration server checks the Security Settings policy in names.nsf to see if any users require a key rollover.
  4. When AdminQ detects that the key rollover date has arrived, it sets a "Rollover Scheduled Date" for the key rollover in the user's ID vault.
  5. AdminQ checks the ID vault hourly for users whose "Rollover Scheduled Date" has arrived.
  6. AdminQ detects that the user's "Rollover Scheduled Date" has arrived and creates a "UserRollover" request for the user in adminq.nsf assigned the state "Needs Processing."
  7. AdminQ checks hourly for "UserRollover" requests in adminq.nsf assigned the state "Needs Processing."
  8. When AdminQ finds the "UserRollover" request for the user in the "Needs Processing" state, it creates a "Certify New Person Key Request" in admin4.nsf and changes the state to "Pending Public Key." AdminQ also moves the ID to the "Pending" state in the Key Rollover view of the ID vault.
  9. The "Certify New Person Key Request" replicates to admin4.nsf on the domain administration server.
  10. The administrator opens the Certify New Key Requests view in admin4.nsf, selects the user entry, clicks Certify Selected Entries, and follows the prompts to certify the ID.
  11. AdminP creates a "Recertify Person in Domino Directory" in admin4.nsf.
  12. AdminP kicks of the "Recertify Person in Domino Directory" request according to the AdminP interval setting.
  13. AdminP updates the public key in the user's Person document in the Domino directory.
  14. AdminQ creates a "UserRecertify" request in adminq.nsf for the user. For information on steps taken to carry out that request, see How AdminQ recertify requests are processed.
  15. The updated Person document in names.nsf replicates from the domain administration server to vault administration server.
  16. AdminQ checks hourly for users with new public keys.
  17. AdminQ detects the user's new public key and updates the key in the user's ID vault.
  18. AdminQ changes the state of the "UserRollover" request in adminq.nsf to "Processed." It also changes the state of the ID in the Key Rollover view of the ID vault from "Pending" to "Completed."
  19. The web user connects a Domino HTTP server, likely a different server than the ID vault server.
  20. HTTP authenticates the user and loads the user ID into memory from the ID vault.
  21. The user accesses the resource on the HTTP server.
Note: If enforce key checking is enabled in the Compare public keys field in the Security tab of a Server document, a Notes client user may be unable to log on to the server shortly after the key rollover. This occurs when the new key in the Person document is not yet in the local ID file because the Notes client hasn't synced with the vault. In this situation, the user can delete the local ID file or click File > Security > User Security and ID Vault Sync to download the latest ID file from the vault. The option Log public key mismatches near the Compare public keys field can help detect IDs for which this is a problem.