Addressing Security Issues

This section discusses the security issues you must consider before installing the Active Directory driver.

The major factors to consider are authentication, encryption, and use of the Remote Loader. If you have Windows 2003 or Windows 2000 SP3 or later, consider a security option called signing. See "Use Signing" in Security Parameters.

A simple prescription for managing security is not possible because the security profile available from Windows varies with 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 implementing your driver and when upgrading components, pay close attention to security.


Authentication Methods

Authentication identifies the driver shim to Active Directory and, potentially, the local machine. To authenticate to Active Directory, you can use either the Negotiate method or the Simple (simple bind) method.

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

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

Simple

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

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

Some provisioning services are unavailable, such as Exchange mailbox provisioning and password synchronization.


Encryption

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

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

If the DirXML engine, Identity Vault, the Active Directory driver, and Active Directory are on the same machine, you don't need SSL. Communication isn't going across the network.

However, if you are accessing Active Directory remotely by using an Active Directory driver shim on a member server, you need to set up SSL between the 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 the "SSL Connection Between the Active Directory Driver and the Domain Controller" topic.

If you are using the Remote Loader on the Domain Controller, you need to set up SSL between the DirXML/Identity Manager engine and the Remote Loader. For additional information on SSL and Remote Loaders, see "Setting Up a Connected System" in the Novell Nsure Identity Manager 2.0.1 Administration Guide.

The following table outlines where SSL connections can be used for each of the scenarios discussed in Planning Your Installation:

Configuration SSL Connections Available

Single-Server

No SSL connections are necessary.

Two-Server: Identity Manager and the Active Directory driver are on the same server

An SSL connection can be established between the Active Directory driver and the domain controller.

Dual-Server: Identity Manager is on one server but the Active Directory driver is on a separate server

An SSL connection can be established between Identity Manager and the Remote Loader running the Active Directory driver.

Three-Server

An SSL connection can be established between the Active Directory driver and the domain controller.

An SSL connection can also be established between Identity Manager and the Remote Loader running the Active Directory driver.


SSL Connection Between the Active Directory Driver and the Domain Controller

To make SSL connections to an Active Directory domain controller, you must be set up to use SSL. This involves setting up a certificate authority, then creating, exporting, and importing the necessary certificates.


Setting Up a Certificate Authority

Most organizations already have a certificate authority. In this case, 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 certificate authority that the issuing certificate authority of this certificate chains to.

If you do not have a certificate authority in your organization, you must establish one. Novell, Microsoft, and several other third parties provide the tools necessary to do this. Establishing a certificate authority is beyond the scope of this guide. For more information, see


Creating, Exporting, and Importing Certificates

After you have a certificate authority, for LDAP SSL to operate successfully, the LDAP server must have the appropriate server authentication certificate installed. 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 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.
      • 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 Certificate Authority. Consult this document for the latest requirements and additional information.

  2. Export this certificate in one of the following standard certificate file formats supported by Windows 2000:

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

    The following links contain instructions for each supported platform:

    Follow the instructions listed under Import the Certificate into the Local Computer Store.

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

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

    For more information on establishing trust for certificates, see the "Policies to establish trust of root certification authorities" topic in Windows 2000 Server Help.

  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 Active Directory driver shim.


SSL Connection Between the Remote Loader and Identity Manager

If you are using the Remote Loader, you need to set up SSL between the DirXML/Identity Manager engine and the Remote Loader, plus the settings between the driver and Active Directory.

For information on establishing an SSL connection between the Remote Loader and Identity Manager, see "Setting Up Remote Loaders" in the Novell Nsure Identity Manager 2.0.1 Administration Guide.