Special considerations are needed when merging eDirectory trees where 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 can be a time-consuming and laborious task.
IMPORTANT: These instructions are complete for trees with Novell Certificate ServerTM 2.02 and earlier, Novell Single Sign-on 1.x, and NMAS 1.x.
To merge trees with multiple security containers:
In ConsoleOneTM, identify the trees that will be merged.
Identify which tree will be the source tree and which tree will be the target tree.
Keep in mind these security considerations when choosing which tree will be the source and which tree will be the target:
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, you should complete the following steps.
Depending on how the product was used, the objects and items referred to might not be present. If the objects and items referred to in a given step are not present in the source tree, skip the step.
NOTE: Previous versions 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 2.a).
In the source tree, open a Trusted Root object in the selected Trusted Root container and export the certificate.
IMPORTANT: Remember the location and filename you choose; you will use them in the next step.
In the target tree, create a Trusted Root object in the container that you created in Step 2.b. Specify the same name as the source tree and, when prompted for the certificate, specify the file that you created in Step 2.c.
Delete the Trusted Root object in the source tree.
Repeat Step 2.c through Step 2.e 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 Step 2.a through Step 2.g 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.
Any certificates signed by the Organizational CA of the source tree will be unusable following Step 3. This includes server certificates and user certificates that have been signed by the Organizational CA of the source tree.
Delete every Key Material object in the source tree that 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 do not need to be deleted.
If you are uncertain about the identity of the signing CA for any Key Material object, reference the Trusted Root Certificate section of the Certificates tab in the Key Material object properties page.
Delete all user certificates in the source tree that 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. Private keys and certificates that are still in eDirectory will no longer be usable after you perform Step 3.
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 2.0 or later has been installed on the server that hosts the Organizational CA in the source tree.
If Novell Single Sign-on has been installed on any server in the source tree, you should complete the following step.
Depending on how the product was used, the objects and items referred to 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, you should complete the following steps.
Depending on how the product was used, the objects and items referred to might not be present. If the objects and items referred to are not present in the source tree, skip the step.
In the target tree, install any NMAS login methods that were in the source tree but not in the target tree.
To ensure that all of the necessary client and server login components are properly installed in the target tree, we recommend that you install new login methods using original Novell or vendor-supplied sources.
Although methods can be reinstalled from existing server files, establishing a clean installation 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, notate the Login Methods used (listed in the right window).
Select the Security container in the target tree and replicate the login sequences using the same login methods notated in Step 2.c.
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, complete the following steps.
Depending on how the product was used, the objects and items referred to 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: Make sure that you delete this file on all servers in the source tree.
If a Security container exists in the source tree, delete the Security container before you merge the trees.
eDirectory trees are merged using the ndsmerge 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 (the 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 in the resulting tree.
The easiest way to accomplish this is to install Novell Certificate Server v2.0 or later 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 (the SYS:\SYSTEM\NICI\NICISDI.KEY file). It can also be installed on other servers in the resulting tree.
If you are using Novell Certificate Server, after the tree merge:
Reissue certificates for servers and users that were formerly in the source tree, as necessary.
We recommend that you install Novell Certificate Server 2.0 or later on all servers that hold a replica of the partition containing a User object.
In order to issue a certificate for a server, Novell Certificate Server 2.0 or later must be installed.
Novell Certificate Server 2.0 or later must be installed on the server that hosts the Organizational CA.
If you are using Novell Single Sign-on, after the tree merge:
Re-create Secret Store secrets for users that were formerly in the source tree, as necessary.
If you are using NMAS, after the tree merge:
Reenroll NMAS users that were formerly in the source tree, as necessary.