Das ist nicht einfach, hier der Vorschlag von Notes
What to Do When a Certifier ID is Stolen, Lost or Compromised
Problem:
What should an Administrator do if a Notes/Domino Certifier ID has been lost, stolen or compromised?
Solution:
The following information describes how to recertify with a new CERT.ID and lock down the Public Address Book.
The good news is that the threat posed by someone with your Certifier ID can be contained and stopped. The bad news is that the recertification process is a manually-intensive process, making it somewhat difficult to recertify an organization.
A. Defining the Threat
The first step is to determine what a person with an organization's Certifier ID can do so that you know what activities can be prevented. The following is a list of the activities that a person with your organization's Certifier ID can do:
1. Create new user IDs, or forge duplicate user IDs which appear to have the same user name as an existing user but which actually have a different public key/private key pair from the original user's ID.
2. Create new server IDs, or forge duplicate servers (same as above) having different public key/private key pairs.
3. Create cross-certificates.
4. Create organizational level Certifier IDs.
5. Recertify existing user IDs and server IDs that have expired.
B. Containment Steps
Next you should determine what steps can be taken to stop someone who holds the Certifier ID. The following list of steps allows you to stop the activities of an unauthorized person holding your Certifier ID.
1. Tightly restrict access to the Public Address Book. Set default Access Control List (ACL) access to Reader. Restrict who you grant Author and higher rights in the ACL.
2. Turn on the following settings in every Server document:
- "Compare public keys against those stored in Address Book"
- "Only allow server access to users listed in this Address Book"
3. Turn on the following settings in the Public Address Book's ACL:
- "Enforce a consistent Access Control List across all replicas of this database"
4. Check each Server ID for any old or invalid flat certificates.
5. Restart each Notes server after making the changes to the Server documents.
6. Remove any old or invalid Person documents from the Public Address Book.
7. Remove any old or invalid Server documents from the Public Address Book.
8. Remove any old or invalid cross-certificates or Certificate documents from the Public Address Book.
NOTE: These steps apply specifically to the problem of a compromised Certifier ID. This is not intended to be an exhaustive list of the normal procedures and policies that you should already have in place to ensure the security of your environment, such as physical security, network operating system security, ensuring that database administrators understand their role in controlling who is granted ACL rights, etc.
C. Recertification Options
The following are possible workarounds:
1. Do nothing. Once the environment is secured and the threat of someone with your Certifier ID is contained, you can opt to do nothing else. You do not have to issue a new certifier to contain the threat. You could wait for a future product enhancement that would automate the recertification process and make it more convenient.
2. Migrate users and servers to a new Organization name and certifier. The good news is that the Administration Process (AdminP), makes it easier to roll out a name change for users. The bad news is that the process of renaming servers is manual and very detailed. The process of changing the distinguished names of all your servers would be a lot of work. Server renaming is not supported by AdminP.
3. Recertify manually. The bad news is that this is a manual process and takes time. See steps in Supporting Information section below.
4. Attempt to automate the parts of the manual recertification process that affect each user through such things as agents, script, or emails with buttons.
Supporting Information:
You can perform the following steps to create a new Cert ID by registering an organization with the exact same name as the original organizational Certifier. For the purposes of this document, we will use the Organization of Acme, O=Acme.
1. First, make a backup of the Public Address Book (NAB), NOTES.INI, server ID, all User ID's, and any OU ID's.
2. Delete the Certificate in the NAB for the lost Cert ID. In this case, we would delete the certificate /Acme under Server, Certificates, Notes Certifiers.
3. Register a new Organization:
In R4, use File, Tools, Server Administration, Certifiers, Register Organization. Choose a Registration Server and be sure to name the Organization the exact same name as before; in this case, Acme. Enter a password and click on Register.
In R5, start up the Administration client, click the Configuration tab, Tools, Registration, Organization, and then same as R4 steps for the rest. This will add a new certificate for /Acme under Notes Certifiers in the NAB.
You should get an informational dialog box that the ID file has been created. Click OK.
4. In R4, while still in Server Administration, go to Certifiers, Certify ID file. Use the newly created CERT.ID to certify the SERVER.ID and the Admin ID (the ID that is logged in while doing these procedures) by clicking Certify.
In 5.x, click the Configuration tab, Tools, Certification, Certify, and use the newly created CERT.ID. Then follow the same as in 4.x.
A message in the status bar should state that the ID was successfully certified.
5. At this point, re-start the Domino server. In R4, exit or quit from the Domino server console and then restart. In R5, from server console, type "restart server".
6. When the server comes back up, in R4 go to the NAB's People view, and check off by holding and dragging the mouse to the left, all the names of people certified under the Organizational Cert ID, in this case, Acme. An example of a hierarchical user registered under the Acme certifier would be Joe Smith/Acme.
In 5.x, click the People & Groups tab in the Domino Administrator, and check off all people under Organizational Certifier.
7. In R4, go to Actions, Recertify Person, and use the newly created CERT.ID to recertify the users. A"Renew Certificates in Selected Entries" dialog box appears. Click Certify. At this point, AdminP will recertify the users, but be sure to check the server console for errors and the Administration database ADMIN4.NSF to be sure the requests were completed.
In R5, go to Actions, Recertify Selected People, then same as R4 steps above.
8. At this point, when users re-authenticate with the server, they will have their ID's updated with the new hierarchical certificates. If they are having trouble, have them log out completely (F5), then re-authenticate. If they still have a problem, then manually re-certify the user's ID.
9. If there are servers and people under OU's that are descendants of the Original Certifier, for example, server1/sales/Acme and John Brown/Marketing/Acme, then these OU's also need to be re-created, and the servers and users need to be recertified. OU's Certifiers will first need to be deleted from the NAB /sales/Acme and /Marketing/Acme.
10. Also, any servers that have cross-certified with the Organization will need to be cross-certified again. Delete all cross-certificates from the NAB and cross-certify again.
NOTE: When users go into their mail files after the recertification, they may see an error stating that the Public keys do not match, when viewing their ACL. There are no known problems associated with this error. It seems only informational and does not affect functionality, but you can avoid it by updating signatures in the user's mail file. In R4, go to Server
Administration, Database Tools, and under databases find users mail file(s) under tools sign a database, Update existing signatures only, then click Sign. In R5, in the Domino Administrator, go to the Files tab, find users mail file(s), Tools, Database, Sign, Update existing signatures only.
