Environment
Novell eDirectory 8.7.3 for All Platforms
Situation
Upgrading Security Domain Infrastructure (SDI) to 168-bit keys.
Preparing for Universal Password (UP) implementation.
Resolution
SDKey : 1
Object Class : Secret Key
Key Size : 168 bits
Key Usage : 0x4400C0
Key Format : DES-EDE3-CBC-IV8
Key Id : 9C 44 68 B6 4C BD 54 F5 5B 57 FB 88 61 2F E2 E2
Validity : Sun Aug 19 21:05:09 2003 - Sun Feb 3 23:59:00 2036
It is very possible that under a Server section there will be multiple SDKey sections. The key numbers do not matter among servers and are simply used for identification should you decide to manually remove or revoke keys. The important sections include 'Key Size', 'Key Id' and 'Validity'. Validity is rarely a problem since tree keys are set to expire 30 years in the future. The Key ID should be noted because we need to make sure the same Key Id is on all servers in the tree (the only exceptions are very old servers that do not have NICI and will never work with UP). The Key Size is also relevant because this parameter tells us how many bits make up the key. It is this parameter we will have be set to 168 for our synchronized key at the end of this solution
The final bit of information to note is whether or not the listed key(s) is/are revoked. A revoked key cannot be used for encryption but can still be used for decryption. Revoked keys, synchronized or not, 56-bit or 168-bit, are not useful for any future password-set operations.
If the output file shows a valid (not expired) 168-bit key that is not revoked for EVERY server in your tree then your tree is already completely ready for Universal Password as far as tree keys are concerned. If there is a 56-bit key synchronized, valid , and not-revoked to all servers in the tree UP should still work but using 168-bit keys is still preferred. Consider using the CoolSolution listed in the note section below to interpret the process.txt file generated. Its output is generated quickly and the summary at the end can instantly answer a question of valid keys for all servers, a process that can take a long time in a large tree.
If there are still unsychronized keys we can use sdidiag to generate a new key and to verify its synchronization to all servers. Once inside sdidiag the comment to revoke all old keys and generate a new key is:
sd -g
The command to run at the end of that command does a two-pass synchronization of the keys to make sure all servers hold the keys properly. The command is:
rd -t
The latter command can be run again if it is needed but a reboot of any problem servers may help them retrieve the new keys as well. The former command should not be run casually though it shouldn't cause large problems. Each time `sd -g` is run a new key on all servers in the tree are generated. Running multiple times creates a large number of keys unnecessarily.
If you review your keys now (process.txt) there should be a new
168-bit key that is valid on all servers. If this is not the case
try rebooting problem servers. Keep in mind that servers with an
outdated version of NICI will never get these keys. Servers with
this issue are no longer supported.
Additional Information
Novell TID# 3455150 covers how to retrieve tree key information from either a NetWare server (sdidiag.nlm) or from a workstation (sdidiag.exe).
A CoolSolution exists (tkinfo.pl) that can help analyze output
in the process.txt file. See: https://www.novell.com/coolsolutions/feature/16544.html
Formerly known as TID# 10100303