A.2 Merging Trees with Multiple Security Containers

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 because this procedure has the potential to be a very time-consuming and laborious task.

IMPORTANT:These instructions are complete for trees with NetIQ Certificate Server 2.2.1 and earlier, NetIQ Single Sign-on 2.x, and NMAS 2.x.

To merge trees with multiple Security containers:

  1. In iManager, identify the trees that will be merged.

  2. 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:

    • Any certificates signed by the source tree's Organizational CA must be deleted.

    • The source tree's Organizational CA must be deleted.

    • All user secrets stored in NetIQ SecretStore on the source tree must be deleted.

    • All NMAS login methods in the source tree must be deleted and reinstalled in the target tree.

    • All NMAS users that were in the source tree must be re-enrolled when the trees are merged.

    • All users and servers that were in the source tree must have new certificates created for them when the trees are merged.

    • All users that were in the source tree must have their secrets reinstalled into SecretStore.

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.

A.2.1 Product-Specific Operations to Perform prior to Tree Merge

This section contains the following information:

NetIQ Certificate Server

If NetIQ 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.

  1. 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.

  2. Install the Trusted Root certificates in the target tree.

    1. Pick a Trusted Root container in the Security container in the source tree.

    2. 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).

    3. 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.

    4. 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.

    5. Delete the Trusted Root object in the source tree.

    6. 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.

    7. Delete the Trusted Root container in the source tree.

    8. Continue Step 2.a through Step 2.f until all Trusted Root containers have been deleted in the source tree.

  3. 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.

  4. 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.

    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.

  5. 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 lists all the certificates for the user. All of those certificates with the Organizational CA as the issuer must be deleted.

    User certificates will be present in the source tree only if NetIQ Certificate Server 2.0 or later has been installed on the server that hosts the Organizational CA in the source tree.

NetIQ Single Sign-on

If NetIQ Single Sign-on has been installed on any server in the source tree, you should delete all NetIQ Single Sign-on secrets for users in the source tree.

For every user using NetIQ 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.

NMAS

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.

  1. 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 all new login methods using original NetIQ or vendor-supplied sources.

    Although methods can be reinstalled from existing server files, establishing a clean installation from NetIQ or vendor-supplied packages is typically simpler and more reliable.

  2. To ensure that the previously established login sequences in the source tree are available in the target tree, migrate the desired login sequences.

    1. In iManager, browse to and select the Security container in the source tree.

    2. Expand the Security container view, click the Login Policy object and select Modify Object.

    3. For each login sequence listed in the Login Sequences tab, note the Login Methods used.

    4. Select the Security container in the target tree and replicate the login sequences using the same login methods note in Step 2.c.

    5. Click OK when you are finished.

  3. Delete NMAS login security attributes in the source tree.

    1. In the Security container of the source tree, delete the Login Policy object.

    2. In the Authorized Login Methods container of the source tree, delete all login methods.

    3. Delete the Authorized Login Methods container in the source tree.

    4. In the Authorized Post-Login Methods container of the source tree, delete all login methods.

    5. Delete the Authorized Post-Login Methods container in the source tree.

      NOTE:To delete the Authorized Login Methods, use ldapdelete.

NetIQ Security Domain Infrastructure

If NetIQ Certificate Server 2.x or later, NetIQ Single Sign-on, NMAS, or eDirectory 8.5 or later has been installed on any server in the source tree, the NetIQ 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.

  1. 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.

  2. 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.

Other Security-Specific Operations

If a Security container exists in the source tree, delete the Security container before you merge the trees.

A.2.2 Performing the Tree Merge

eDirectory trees are merged using the DSMerge utility. For more information, see Section 11.0, Merging NetIQ eDirectory Trees and Section B.0, NetIQ eDirectory Linux Commands and Usage.

A.2.3 Product-Specific Operations to Perform after the Tree Merge

This section contains the following information:

NetIQ Security Domain Infrastructure

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 NetIQ Certificate Server 2.5.2 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 NetIQ 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 NetIQ Certificate Server 2.5.2 or later on the servers in the resulting tree. NetIQ 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.

For more information on installing NetIQ Certificate Server, see the NetIQ Certificate Server 3.3 Administration Guide.

NetIQ Certificate Server

If you are using NetIQ Certificate Server, then after the tree merge reissue certificates for servers and users that were formerly in the source tree, as necessary.

We recommend that you install NetIQ Certificate Server 2.5.2 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, NetIQ Certificate Server 2.5.2 or later must be installed.

NetIQ Certificate Server 2.5.2 or later must be installed on the server that hosts the Organizational CA. For more information, see the NetIQ Certificate Server 3.3 Administration Guide.

NetIQ Single Sign-On

If you are using NetIQ Single Sign-on, after the tree merge you should re-create SecretStore secrets for users who were formerly in the source tree, as necessary.

NMAS

If you are using NMAS, after the tree merge you should re-enroll NMAS users who were formerly in the source tree, as necessary.

For more information, see the NetIQ Modular Authentication Services 3.3 Administration Guide.