Environment
Novell NetWare 6.5
Novell eDirectory 8.7.3.x
eDirectory 8.8.8.x
Situation
Tree Keys are used to encrypt and decrypt data on the server (such as passwords stored in the eDirectory database.) When all of your servers do not have the same keys, errors may occur when trying to access this encrypted data, as one server may encrypt the data, sync it to another server, and when that server is requested to read it, it may not have the key in which to extract it properly. This document will help you determine if your keys are all the same in your tree and correct them if there are problems.
Resolution
1. First we need to find out what servers hold what key information. TID 3455150 - Using SDIDIAG to gather specific SDKey information from servers will walk you through the steps of gathering the key information. Specifically, you need the LIST.TXT, SERVER.TXT and PROCESS.TXT file created with the commands from KB 3455150.
2. Look at the PROCESS.TXT files. Are there any errors in this file? Do all servers have the same keys? You should see at least one or more keys on all the servers in the list and they should all have the same exact keys. They do not however, have to be in the same order on each server.
NOTE: If you have a lot of servers, with a lot of keys on them, this process may be cumbersome. A Perl Script was created to make this process easier for you. You will need perl running on the host platform. Cool Solutions 16544 - TKInfo Tool (TKInfo Tool is unsupported, but should work fine)
Ex. Perl c:\path\tkinfo.pl c:\path\process.txt
Common errors you will see in the PROCESS.TXT file.
-255 Error: Non eDirectory server / NICI is not loaded on the server (NICISDI.XLM and SASDFM.XLM) Fix: upgrade server to the current eDirectory version.
-672 Error: The server listed does not have rights to the WO object. Go to the WO object, (Found in the Security Container, under the KAP object), Select Trustees of the WO Object, and add the server with the error as a trustee of the WO Object. The default rights Browse, Read Entry Rights & Compare Attribute Rights are sufficient.
-1546 Error: Bug in older NICI, apply NICI to 2.6.4 or greater.
-625 Error: Can't communicate with the server (verify the server is up)
-626 Error: no referrals / communication issue.
3. Look in the LIST.TXT file. This is the Key Server that is responsible for sending the Tree Keys to the other servers in the tree. This can be one or more servers. This server should have all the keys that any server could have in the tree. If it does not, then it cannot send all the keys out to the other servers in the tree. If you have no servers listed here then you need to pick a server that has all the keys (from the process.txt file) and designate it as the Key Server. Once all servers have the same keys, you can change your Key Server to be any server you would like. To define the Key Server, edit the properties of the WO object. This is found in the Security Container, under the KAP object. Under the Other tab on the WO object, you will see an attribute called NDSPKI:SD Key Server DN. You can then change that server to be a server that has all the Keys in the tree. If you do not see the attribute, then you need to add it and define a server as you currently have no Key Server defined.
Note: You may see multiple keys defined in your LIST.TXT or PROCESS.TXT file. Some of which are designated as REVOKED. This is normal. There should be one Key that is not revoked and the other keys will be revoked. This occurs when you have revoked and reissued a new Key for some reason, such as increasing the encryption level. All your servers need to have the non- revoked and the revoked keys in your tree. This is because some data may have been encrypted with an old key, and they need the revoked key to unencrypt it. However all new data will be be encrypted with the non-revoked key(s).
4. Issuing a new Key: Now that you have a Server Defined with the most keys possible, you may want to issue a new key. For instance if you see only a 56 bit key for encryption, you can issue a 168 bit key with the following command in SDIDIAG. SD -R
Use SD -R, cautiously as it creates a new key in which you cannot remove a key once it is created. It can only be revoked and must remain in the key list.
5. Syncing out new Keys. Now that you have a WO server that has the all the keys listed, and you have reissued a new key (if needed), you need to synchronize that out to the other servers in the tree. In SDIDIAG this is done with RD.
This should sync all the keys out to the other servers in the tree. You then need to recreate the PROCESS.TXT file (from KB 3455150) and see if all servers have the same keys now. If some servers are still missing the keys, then you will need to reboot those servers. The RD command should sync out the keys, but if it does not for some reason, each server reads the key information each time they boot up. So rebooting the server should allow it to get the keys.
END RESULT: The end result of all this is that you have a Key Server, listed under the WO objects NDSPKI:SD Key Server DN attribute that has all the keys in the tree, and Each server in entire tree has all the same keys (in process.txt file).
Additional Information
Additional information on SDIDIAG switches and options can be found in TID 3840110 - Using SDIDiag - Switches and Options
