2.3 Addressing Security Issues
The major security issues to consider are authentication, encryption, and use of the Remote Loader. You might want to consider a security option called signing. See Digitally sign communications in Section 9.0, Security Best Practices.
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 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
NOTE:Active Directory driver uses Negotiate as the default authentication method. When the Active Directory driver’s basic configuration file is imported to create a new driver, the authentication method is set to by default. If you want to use 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 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 on the driver configuration. See Step 5, in SSL Connection between the 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 Metadirectory engine and the Remote Loader. For additional information on SSL and Remote Loaders, see Creating a Secure Connection
in the Identity Manager 3.6.1 Remote Loader Guide.
The following table outlines where SSL connections can be used for each of the scenarios discussed in Section 2.2, Where to Install the Active Directory Driver:
Table 2-2 SSL Connects
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. This is only needed if the Remote Loader is not running on a Domain Controller.
Setting Up a Certificate Authority
Most organizations already have a certificate authority. 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 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 about the Novell solution, see the Novell Certificate Server 3.3 Administration Guide.
Creating, Exporting, and Importing Certificates
After you have a certificate authority, 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.
-
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.
-
-
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
-
-
Install this certificate on the domain controller.
-
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 Server 2003 Help.
-
In iManager, edit the driver properties and change the option to yes.
-
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.
Verifying the Certificate
To verify the certificate, authenticate to Active Directory via SSL. Use the ldifde command line utility found on Windows servers. To use the ldifde command:
-
Open a command line prompt
-
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.
ldifde -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.
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 Creating a Secure Connection
in the Identity Manager 3.6.1 Remote Loader Guide.
WARNING:When the Remote Loader is running on a Windows 2003 SP2 32-bit server, the certificate must be in Base64 format. If you use the DER format, the Remote Loader fails to connect to the Identity Manager engine.