Special considerations need to be made 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 has the potential to be a very time-consuming and laborious task.
IMPORTANT: These instructions are complete for trees with Novell® Certificate ServerTM 2.21 and earlier, Novell Single Sign-on 2.x, and NMAS 2.x.
In ConsoleOne®, 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 for the source and target trees:
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 (previously known as Public Key Infrastructure Services, or PKIS) has been installed on any server in the source tree, you should complete the following steps.
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 in a given step are not present in the source tree, you can skip the step.
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.
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 2b. Specify the same name as the source tree and, when prompted for the certificate, specify the file that 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.
Continue 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.
IMPORTANT: Any certificates signed by the Organizational CA of the source tree will become unusable following this step. This includes server certificates and user certificates that have been signed by the Organizational CA of the source tree.
Delete every Key Material object (KMO) 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.
HINT: If you are uncertain about the identity of the signing CA for any Key Material object, look at the Trusted Root Certificate section of the Certificates tab in the Key Material object property page.
Delete all user certificates in the source tree that have been signed by the Organizational CA of the source tree.
NOTE: 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 lists all the certificates for the user. All of those certificates with the Organizational CA as the issuer must be deleted.
NOTE: User certificates will be present in the source tree only 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 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 SecretStore section of the Security tab. Delete all listed secrets.
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, you can skip this step.
If NMAS has been installed on any server in the source tree, you should complete the following steps.
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, you can skip the step.
In the target tree, install any NMAS login methods that were in the source tree but not in the target tree.
HINT: To ensure that all of the necessary client and server login components are properly installed in the target tree, we recommend that you install all 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 typically 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 > select Properties.
For each login sequence listed in the Defined Login Sequences drop-down list, 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 note in Step 2c.
Click OK when you are finished.
Delete NMAS login security attributes in the source tree.
In the Security container of the source tree, delete the Login Policy object.
In the Authorized Login Methods container of the source tree, delete all login methods.
Delete the Authorized Login Methods container in the source tree.
In the Authorized Post-Login Methods container of the source tree, delete all login methods.
Delete the Authorized Post-Login Methods container in the source tree.
If Novell Certificate Server 2.x or later, Novell Single Sign-on, NMAS, NetWare 5.1 or later, or eDirectory eDirectory 8.5 or later has been installed on any server in the source tree, the Novell Security Domain Infrastructure (SDI) will be installed. If SDI has been installed, you should complete the following steps.
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, you can skip the step.
Delete the W0 object and 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 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 (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 2.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.
NOTE: 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 SecretStore secrets for users that were formerly in the source tree, as necessary.
If you are using NMAS: After the tree merge, re-enroll NMAS users that were formerly in the source tree, as necessary.