Accepting or rejecting name change requests

There are two situations that are unique to user name change requests. One situation generates a request to revert to the original user name, another situation generates a request to retract the user's name change. You are required to accept or reject these requests whenever they are posted to Administration Requests database (ADMIN4.NSF).

About this task

Users whose IDs are stored in an ID vault are not prompted to reject or accept name changes; name changes occur without user interaction.

When you initiate a user's name change, the user may be prompted to accept or reject the name change. If the user rejects the name change, an administration request is generated that requires you to either accept the user name reverting back to the original name or reject the user name reverting back to the original user name. For example, if a user refuses a name change, the administration request Approve refused name change is posted to ADMIN4.NSF.

Note: The user is prompted if the user has requested a name change from the Notes® client by selecting File > Security > User Security, and then selecting Your Identity > Your Names and clicking Name Changes. Then in the Notes® Name Changes dialog box, selecting the Ask your approval before name changes option.

If the expiration date for the name change is reached and the user has not responded, an administration request is issued asking you to accept a request to retract the name change. You can then either accept the request to retract the name change, or you can reject that request. If you accept the name change retraction, the administration requests for rejecting a name change are generated.

Procedure

  1. From the Domino® Administrator, choose Server > Analyses > Administration Requests.
  2. Select the server and then open the Administration Requests (ADMIN4.NSF) database.
  3. Open the Pending Administrator Approval view.
  4. Open one of these views according to how you want to accept or reject requests that have been generated by users accepting, rejecting, or ignoring name changes.
    • Individual Approval Required -- Use this view to individually approve or reject each request. Select and open the request and then click Approve or Delete.
    • Pending by Age or Pending by Server -- Use one of these views to approve or reject multiple requests at one time. Select the requests that you are accepting or rejecting, and then click Approve Selected Requests or Delete Selected Requests.
  5. Close the Administration Requests database.

Renaming users impacts design elements

When a user is renamed, the user is renamed in the Domino® Directory, Person documents, ACLs, calendar entries, the Free-time database, Reader/Author fields, profiles in the mail file, and design elements. The user is renamed in any design elements that contain the old (original) name. The user's design elements are also re-signed. The signing requirements for the design elements vary according to whether the design element is private or shared.

Private elements

The Notes® client is responsible for updating private design elements because the renamed user must be the last signer of the private element. For example, if a mail file contains a private folder, the private folder's creator's signature is updated during the rename. The renamed user must then authenticate with the server in order to open the private folder. If someone other than the renamed user attempts to open the private folder, they will be unable to authenticate and will not be able to open the folder.

Shared folders

The server performing the update signs the shared design elements during the update. The shared folder's creator name is not updated during a user rename because it is not crucial that the renamed user be the last user to access the database. A shared folder can be signed by anyone, for example, the server can sign a shared folder for the owner. If a shared design element needs to be updated, the server performs the update; therefore, the server also signs the database.