Connector Guides › Connectors Guide › Connecting to Endpoints › Lotus Notes/Domino Connector › Administration Process (Adminp)

Administration Process (Adminp)

CA Identity Manager uses the Lotus Domino Administration Process (Adminp) to automate tasks that involve accounts, such as recertifying, renaming, upgrading to hierarchical naming conventions, and deleting. It also uses the ADMIN4.NSF database to store requests and responses.

The Adminp process works with CA Identity Manager so that when requests are made, Adminp transforms the account ID on the Lotus Notes/Domino server from a normal state to a pending state. The following states are maintained with the account status information:

• Change Expiration Pending
• Rename Pending
• Move in Hierarchy Pending
• Delete Pending

Both the Rename and Move in Hierarchy requests require accounts to accept the modification when the account connects to the server for the first time after the request is made. If the account accepts the change, Adminp performs a series of actions that are detailed and logged in the ADMIN4.NSF database and the REGARC.NSF database. These actions include modifications to the following databases:

• Address Book
• Access Control List
• Person Documents
• Free Time Database
• Calendar Entries and Profiles
• Reader and Author fields

When making a Rename request, the account must accept the change within the period of time that is specified in the Name_Change_Expiration_Days NOTES.INI setting. The account is prompted upon every subsequent server connection until the change request becomes obsolete.

Even though no defaults for this setting exist, change requests are deleted after 21 days if there is no specified setting. If the request becomes obsolete, Adminp deletes it from the ADMIN4.NSF database. You are then responsible for backing out the change made in the REGARC.NSF database.

As part of any of the three Custom requests-specifically Change Common Name, Move In Hierarchy, and Upgrade to Hierarchical, CA Identity Manager creates a secondary account ID and stores it in the REGARC.NSF database. The secondary account ID is for recovery purposes only and follows this format:

• If this is the first rename for the account ID, the secondary account ID will contain a new password with no encryption keys.
• If the account ID has been renamed before, the secondary account ID inherits the password of the previous account ID, but does not inherit its encryption keys.

To replace the secondary account ID with a copy of the real renamed account ID that was accepted by the user, you must establish a procedure to retrieve a copy of the real account ID from the user and store it in the REGARC.NSF database. If such a procedure is not established, any encryption keys associated with the real account ID will be lost if this ID is lost or becomes unusable. To make the account ID accessible, explore the Lotus Notes/Domino server again and remove the old account IDs. You will then be able to manage the renamed account IDs as though they were original account IDs.

If a user must retrieve mail or access documents that were encrypted with a previous version of the account ID you can retrieve a previous generation of the account ID from the REGARC.NSF database as long as you archived the proper version of that account ID.