2.3 Addressing Security Issues

The major security issues 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.

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

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

2.3.2 Encryption

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 (eDirectory). You need to make sure that you use SSL with any communication that goes across the network.

If the Metadirectory 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 Section 2.3.3, SSL Connection Between the Remote Loader and Identity Manager.

If you are using the Remote Loader on the Domain Controller, you can set up SSL between the Metadirectory engine and the Remote Loader. For additional information on SSL and Remote Loaders, see Setting Up a Connected System in the Novell Identity Manager 3.0.1 Administration Guide.

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

Table 2-2 SSL Connects

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

Verify the Certificate

To verify the certificate, authenticate to AD via SSL. Use the ldifde command line utility found on Windows servers. To use the ldifde command:

  1. Open a command line prompt

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

Here is an example of what you would enter if your server is configured for port 636.

ldife -f out.txt -t 636 -b administrator dxad.novell.com novell -s parent1.dxad3.lab.novell

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

2.3.3 SSL Connection Between the Remote Loader and Identity Manager

If you are using the Remote Loader, you need to set up SSL between the Metadirectory engine and the Remote Loader, and configure 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 Loadersin the Novell Identity Manager 3.0.1 Administration Guide.