Special considerations need to be made when merging eDirectory trees when a Security container has been installed in one or both of the trees. Make sure that this is something you really want to do; this procedure has the potential to be a very time-consuming and laborious task.
IMPORTANT: These instructions are complete for trees with Novell Certificate Server version 2.21 and earlier, Novell Single Sign-on version 1.x, and NMAS version 1.x.
In ConsoleOne, identify the trees to be merged.
Identify which tree will be the source tree and which tree will be the target tree.
The security considerations to keep in mind when choosing which tree will be the source and which tree will be the target are as follows:
If neither the source tree nor the target tree has a container named Security under the [Root] of the tree, or if only one of the trees has the Security container, no further action is required. Otherwise, continue with the remaining procedures in this section.
If Novell Certificate Server has been installed on any server in the source tree, the following steps should be performed. Depending on how the product was used, the objects and items referred to might or might not be present. If the objects and items referred to are not present in the source tree, skip the step.
NOTE: Previous version of Novell Certificate Server were called Public Key Infrastructure Services (PKIS).
Any Trusted Root certificates in the source tree should be installed in the target tree. Trusted Root certificates are stored in Trusted Root objects which are contained by Trusted Root containers. Trusted Root containers can be created anywhere within the tree; however, only the Trusted Root certificates that are in the Trusted Root containers within the Security container must be moved manually from the source tree to the target tree.
Install the Trusted Root certificates in the target tree.
Pick a Trusted Root container in the Security container in the source tree.
Create a Trusted Root container in the Security container of the target tree with the exact name used in the source tree (Step 2a).
In the source tree, open a Trusted Root object in the selected Trusted Root container and export the certificate. Remember the location and filename you choose, so you can use it in the next step.
In the target tree, create a Trusted Root object in the container created in Step 2b. Specify the same name as the source tree and, when prompted for the certificate, specify the file you created in Step 2c.
Delete the Trusted Root object in the source tree.
Repeat Step 2c through Step 2e until all Trusted Root objects in the selected Trust Root container have been installed into the target tree.
Delete the Trusted Root container in the source tree.
Repeat steps Step 2a through Step 2f until all Trusted Root containers have been deleted in the source tree.
Delete the Organizational CA in the source tree. The Organizational CA object is in the Security container.
NOTE: Any certificates signed by the Organizational CA of the source tree will be invalid following Step 3. This includes server certificates and user certificates that have been signed by the Organizational CA of the source tree. The certificates might continue to work, but deleting the Organizational CA that issued them effectively invalidated them. Therefore, the certificates must be reissued.
Delete every Key Material object (KMO) in the source tree which has a certificate signed by the Organizational CA of the source tree.
Key Material objects in the source tree with certificates signed by other CAs will continue to be valid and need not be deleted.
NOTE: If you are uncertain about the identify of the signing CA for any Key Material object, check the Trusted Root Certificate section of the Certificates tab in the Key Material object properties page.
Delete all user certificates in the source tree which have been signed by the Organizational CA of the source tree.
If users in the source tree have already exported their certificates and private keys, those exported certificates and keys will continue to be usable, but they should be replaced by new certificates signed by the target tree's Organizational CA. Private keys and certificates that are still in eDirectory will cease to be exportable after you perform Step 3 above.
For each user with certificates, open the Properties of the user object. Under the Certificates section of the Security tab, a table will list all the certificates for the user. All of those certificates with the Organizational CA as the issuer must be deleted.
User certificates will only be present in the source tree if Novell Certificate Server version 2.0 or later has been installed on the server which hosts the Organizational CA in the source tree.
If Novell Single Sign-on has been installed on any server in the source tree, the following step should be performed. Depending on how the product was used, the objects and items referred to might or might not be present. If the objects and items referred to are not present in the source tree, skip the step.
Delete all Novell Single Sign-on secrets for users in the source tree.
For every user using Novell Single Sign-on in the source tree, open the Properties of the user object. All of the user's secrets will be listed under the Secret Store section of the of the Security tab. Delete all listed secrets.
If NMAS has been installed on any server in the source tree, the following steps should be performed. Depending on how the product was used, the objects and items referred to might or might not be present. If the objects and items referred to are not present in the source tree, skip these steps.
In the target tree, install any NMAS login methods that were in the source tree but not in the target tree.
NOTE: To ensure that all of the necessary client and server login components are properly installed in the target tree, we recommend that all new login methods be reinstalled using original Novell or vendor-supplied sources. (Although methods can be reinstalled from existing server files, establishing a clean install from Novell or vendor-supplied packages is usually simpler and more reliable.)
To ensure that the previously established login sequences in the source tree are available in the target tree, migrate the desired login sequences.
In ConsoleOne, select the Security container in the source tree.
Right-click the Login Policy object and select Properties.
For each login sequence listed in the Defined Login Sequences drop-down menu, note the login methods used (listed in the right pane).
Select the Security container in the target tree and replicate the login sequences using the same login methods noted in Step 2c.
Click OK when you are finished.
Delete NMAS login security attributes in the source tree.
If Novell Certificate Server, Novell Single Sign-on, or NMAS has been installed on any server in the source tree, the Novell Security Domain Infrastructure (SDI) will be installed. If SDI has been installed, the following steps should be performed. Depending on how the product was used, the objects and items referred to might or might not be present. If the objects and items referred to are not present in the source tree, skip the step.
Delete the W0 object and then the KAP container in the source tree. The KAP container is in the Security container. The W0 object is in the KAP container.
On all servers in the source tree, delete the Security Domain Infrastructure (SDI) keys by deleting the sys:\system\nici\nicisdi.key file.
IMPORTANT: This deletion should be performed on all servers in the source tree.
If a Security container exists in the source tree, delete it before you merge the trees.
NOTE: Depending on how the product was used, the objects and items referred to might or might not be present. If the objects and items referred to are not present in the source tree, skip the step.
For any remaining objects in the Security container of the source tree, consult the product documentation for instructions on how to safely move the information contained in the object to the target tree.
Delete the remaining objects in the Security container of the source tree.
Delete the Security container in the source tree.
eDirectory trees are merged with the DSMERGE utility. For more information, refer to the DSMERGE documentation .
If the W0 object existed in the target tree before the merge, the Security Domain Infrastructure (SDI) keys used by the servers that formerly resided in the target tree must be installed in the servers that formerly resided in the source tree.
The easiest way to accomplish this is to install Novell Certificate Server 2.0 or later on all servers formerly in the source tree that held SDI keys (sys:\system\nici\nicisdi.key file). This should be done even if the Novell Certificate Server has already been installed on the server.
If the W0 object did not exist in the target tree before the merge but did exist in the source tree, the SDI must be reinstalled on the resulting tree.
The easiest way to accomplish this is to install Novell Certificate Server 2.0 or greater on the servers in the resulting tree. Novell Certificate Server must be installed on the servers formerly in the source tree that held SDI keys (sys:\system\nici\nicisdi.key file). It can also be installed on other servers in the resulting tree.
Reissue certificates for servers and users formerly in the source tree, as necessary.
NOTE: We recommend that all servers that hold a replica of the partition containing a user's object have Novell Certificate Server version 2.0 or later installed.
In order to issue a certificate for a user, Novell Certificate Server version 2.0 or later must be installed.
The server that hosts the Organizational CA must have Novell Certificate Server version 2.0 or later installed.
Re-create Secret Store secrets for users who were formerly in the source tree, as necessary.
Reinstall the NMAS methods that were formerly in the source tree, as necessary.
Re-enroll NMAS users who were formerly in the source tree, as necessary.
Novell Certificate Server can be installed on multiple servers in an eDirectory tree. However, for Novell Certificate Server to function properly, only one Security container, Organizational CA, KAP container, and W0 object should exist in the tree.
If you are installing Novell Certificate Server on multiple servers in an eDirectory tree, you must allow eDirectory to replicate between each installation of Novell Certificate Server. If you do not allow eDirectory to replicate, your installation to another server might not recognize that the tree already has a Security container, an Organizational CA, a KAP container, and a W0 object and might re-create these objects on another server in the same eDirectory tree.
The items below describe possible scenarios and how to resolve them.
If you delete the Security container, you will not be able to create an Organizational Certificate Authority until you have restored or re-created the security container.
To restore the security container, you must restore the eDirectory partition containing the Security container.
To re-create the Security container, use one of two methods:
Do not delete the KAP or W0 objects. Doing so invalidates all previously created User certificates. If you delete one of these objects, go to the Novell Support Web site and search for TID #10053572, How to Restore or Recreate KAP and W0 Objects, for information on how to resolve this problem. You should not attempt further installations of Novell Certificate Server, Single Sign-on, NMAS, NetWare or eDirectory until the problems have been corrected.