2.3 Securing Driver Communication

The major security recommendations are in the areas of authentication, encryption, and use of the Remote Loader.

A simple prescription for managing security is not possible because the security profile available from Windows varies with the service pack, DNS server infrastructure, domain policy, and local policy settings on the server. The following sections explain your security choices and provide suggested configurations. When you implement your driver, pay close attention to security.

2.3.1 Authentication Methods

Authentication identifies the driver shim to Active Directory and, potentially, the local computer.

Table 2-2 Authentication Methods

Authentication Method

Description

Advantages

Disadvantages

Negotiate

The preferred method.

Uses kerberos, NTLM, or a pluggable authentication scheme if one is installed.

The driver can be installed on any server in the forest.

The server hosting the driver must be a member of the forest.

Simple

Used when the server hosting the driver shim is not a member of the forest.

The driver can be installed on a server that is not a member of the forest.

Some provisioning services are unavailable, such as Exchange mailbox provisioning, password synchronization, moving users across domains, and auto discovery of domain controllers.

NOTE:Multi Domain Active Directory driver uses Negotiate as the default authentication method. When the Multi Domain Active Directory driver’s basic configuration file is imported to create a new driver, the authentication method is set to Negotiate by default. If you want to use Simple authentication, change the authentication setting on the driver’s property page after the driver is created.

2.3.2 Encryption Using SSL

SSL encrypts data. Depending on your configuration, SSL can be used in two places:

  • Between the Active Directory driver and the domain controller

  • Between the Identity Vault and the Remote Loader running the Active Directory driver

Password synchronization occurs between Active Directory and the Identity Vault. You need to make sure that you use SSL with any communication that goes across the network.

If you are accessing Active Directory remotely by using an Multi-Domain Active Directory driver shim on a member server, you need to set up SSL between the Multi-Domain Active Directory driver shim and Active Directory. You do this by setting the SSL parameter to Yes on the driver configuration. See Step 5, in SSL Connection between the Multi-Domain Active Directory Driver and the Domain Controller.

If you are using the Remote Loader on the domain controller, you can set up SSL between the Identity Manager engine and the Remote Loader. For additional information on SSL and Remote Loaders, see Creating a Secure Connection to the Identity Manager Engine in the NetIQ Identity Manager Driver Administration Guide.

SSL Connection between the Multi-Domain Active Directory Driver and the Domain Controller

To establish SSL connections to an Active Directory server, you must configure SSL. This involves setting up a CA, then creating, exporting, and importing the necessary certificates. This is only needed if the Remote Loader is running on a member server. However, if the driver is running on a domain controller, no additional configuration is required after you enable driver SSL.

Setting Up a Certificate Authority

Most organizations already have a CA. If this is the case for your organization, you need to export a valid certificate, then import it to the certificate store on your domain controller. The server hosting the driver shim must trust the root CA that the issuing CA of this certificate chains to.

If you do not have a CA in your organization, you must establish one. NetIQ, Microsoft, and several other third parties provide the tools necessary to do this. Establishing a CA is beyond the scope of this guide. For more information about the NetIQ solution, see Certificate Server Administration in the eDirectory Administration Guide.

Creating, Exporting, and Importing Certificates

After you have a CA, the LDAP server must have the appropriate server authentication certificate installed for LDAP SSL to operate successfully. Also, the server hosting the driver shim must trust the authority that issued those certificates. Both the server and the client must support 128-bit encryption.

  1. Generate a certificate that meets the following Active Directory LDAP service requirements:

    • The LDAPS certificate is located in the local computer’s personal certificate store (programmatically known as the computer’s MY certificate store).

    • A private key matching the certificate is present in the local computer’s store and is correctly associated with the certificate.

      The private key must not have strong private-key protection enabled.

    • The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as the OID).

    • The Active Directory fully qualified domain name (for example, DC01.DOMAIN.COM) of the domain controller appears in one of the following places:

      • The Common Name (CN) in the Subject field

      • The DNS entry in the Subject Alternative Name extension

    • The certificate was issued by a CA that the domain controller and the LDAPS clients trust.

      Trust is established by configuring the clients and the server to trust the root CA that the issuing CA chains to.

    This certificate permits the LDAP service on the domain controller to listen for and automatically accept SSL connections for both LDAP and global catalog traffic.

    NOTE:This information appears in the Microsoft Knowledge Base Article 321051, How to enable LDAP over SSL with a third-party certification authority. Consult this document for the latest requirements and additional information.

  2. Export this certificate in one of the following standard certificate file formats:

    • Personal Information Exchange (PFX, also called PKCS #12)

    • Cryptographic Message Syntax Standard (PKCS #7)

    • Distinguished Encoding Rules (DER) Encoded Binary X.509

    • Base64 Encoded X.509

  3. Install this certificate on the domain controller.

  4. Ensure that a trust relationship is established between the server hosting the driver shim and the root CA that issued the certificate.

    The server hosting the driver shim must trust the root CA that the issuing CA chains to.

    For more information on establishing trust for certificates, see Policies to establish trust of root certification authorities, in the Microsoft TechNet Library.

  5. In iManager, edit the driver properties and change the Use SSL (yes/no) option to yes.

    The SSL Setting

  6. Restart the driver.

    When the driver restarts, an SSL connection is negotiated between the domain controller and the server running the Multi-Domain Active Directory driver shim.

Verifying the Certificate

You must authenticate to Active Directory via SSL to verify the certificate by using the ldifde command line utility found on Windows servers.

Perform the following actions to verify the certificate:

  1. Open a command line prompt.

  2. Enter ldifde -f output/input file -t 636 -b administrator domain password -s computerFullName

For example, enter the following command if your server is configured to use port 636.

ldifde -f out.txt -t 636 -b administrator dxad.netiq.com netiq -s parent1.dxad3.lab.netiq

The output is sent to the out.txt file. If you open the file and see the objects listed in Active Directory, you made a successful SSL connection to Active Directory and the certificate is valid.

SSL Connection Between the .NET Remote Loader and Identity Manager

When you enable SSL between Engine and .NET Remote Loader, ensure that the certificate is added to the certificate store before starting the driver for the first time.

For information on establishing an SSL connection between the Remote Loader and Identity Manager, see Creating a Secure Connection to the Identity Manager Engine in the NetIQ Identity Manager Driver Administration Guide.