Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide

Chapter 12 Configuring Security

This chapter provides important information about configuring security for your deployment. The information is organized as follows:


Note –

This chapter assumes that you are familiar with the basic concepts of public-key cryptography and Secure Sockets Layer (SSL) protocol, and that you understand the concepts of intranet, extranet, Internet security, and the role of digital certificates in an enterprise. If you are new to these concepts, please refer to the security-related appendixes of the Managing Servers with iPlanet Console 5.0 manual.


Security Overview

Passwords are sensitive information; therefore, Identity Synchronization for Windows takes security precautions to ensure that user and administrative password credentials used to access the directories being synchronized are not compromised.

This section covers the following security methodologies:

This security approach aims to prevent the following events from taking place:

Specifying a Configuration Password

To protect sensitive information while it is stored in the product’s configuration directory and while it is transferred over the network, Identity Synchronization for Windows uses a configuration password. You (the administrator) specify a configuration password when you install Core, and you must provide this password when you open the Console or run the Identity Synchronization for Windows installation program.


Note –

The system manager must access the configuration password before passing it to the connector; consequently, the system manager stores this password in its initialization file.

File system access controls prevent non-privileged users from accessing the system manager’s initialization file. The Identity Synchronization for Windows installation program does not enforce a password policy for this password.

To increase security when you select a configuration password, see Hardening Your Security.


Using SSL

You can configure Identity Synchronization for Windows to use LDAP over SSL everywhere that components use LDAP. All access to Message Queue is protected with SSL.

You must use SSL between the Active Directory Connector and Active Directory when you are synchronizing from Directory Server to Active Directory.

Requiring Trusted SSL Certificates

By default, connectors configured to use SSL will accept any SSL certificate that the server (i.e.Directory Server or Active Directory) returns — which includes untrusted, expired, and invalid certificates. All network traffic between the connector and server will be encrypted, but the connector will not detect a server that is impersonating the true Active Directory or Directory Server.

To force the connector to accept only trusted certificates, use the Console to enable the Require trusted SSL certificates option on the Specify Advanced Security Options panel of the Directory Source Configuration wizard (see Creating an Active Directory Source). After enabling this option, you must add the appropriate CA certificates to the connector’s certificate database as reported by idsync certinfo.

Generated 3DES Keys

A 3DES key generated from the configuration password is used to secure all sensitive information in the product’s configuration directory. With the exception of log messages, all messages to the Message Queue are encrypted with per-topic 3DES keys. Messages sent between connectors and subcomponents are encrypted with per session 3DES keys. The Directory Server Plug-in encrypts all user password changes with a 3DES key.

SSL and 3DES Keys Protection Summary

SSL and 3DES Keys Protection Summary summarizes how Identity Synchronization for Windows protects sensitive information that is sent over the network.

Table 12–1 Protecting Sensitive Information Using Network Security

Use this Protection Method 

Between the Following Information Types: 

LDAP over SSL (optional) 

  • Directory Server Connector and Directory Server, Active Directory Connector and Active Directory

  • Directory Server Plug-in and Active Directory

  • Command line interfaces and the product’s configuration directory

  • Console and the product’s configuration directory

  • Console and Active Directory Global Catalog

  • Console and Active Directory domains or Directory Servers being synchronized

  • Message Queue broker and the product’s configuration directory

  • Connectors, system manager, central logger, command line interfaces, and Console may authenticate the Message Queue over LDAPS

  • Installer and the Configuration Directory Server

  • Installer and Active Directory

  • Installer and the Directory Server being synchronized

Encrypted with 3DES keys (default)

  • Directory Server Connector and Directory Server Plug-in (all data)

  • Windows NT Connector, Windows NT Password Filter DLL, and Windows NT Change Detector (all data)

  • All sensitive information in the product’s configuration directory

  • All messages sent between connectors and subcomponents (encrypted with per-session 3DES keys)

  • All (non-log) messages sent over Message Queue

SSL and 3DES Keys Protection Summary contains an overview of the security features discussed in this section.

Figure 12–1 Security Overview for Identity Synchronization for Windows

Physical deployment of Identity Synchronization for Windows
Components

Message Queue Access Controls

Identity Synchronization for Windows uses Message Queue’s access control to prevent unauthorized access to message subscription and publishing, allowing each connector to trust messages that it receives.

Unique username and passwords known only to Message Queue and to the connector are provided to access the Message Queue broker. Each message sent over the Message Queue is encrypted with a per topic 3DES key, which protects the message contents and prevents outsiders who do not know the topic key from sending meaningful messages. These measures prevent (a) an attacker from sending falsified password synchronization messages to connectors and (b) an attacker from impersonating a connector and receiving actual password updates.


Note –

By default, clients of the Message Queue, such as the connectors and system manager, accept any SSL certificate that the Message Queue broker returns. See Hardening Your Security for more information to enhance Message Queue certificate validation and other Message Queue-related security issues.


Directory Credentials

Privileged credentials are required by the connectors to change passwords in Active Directory and the Directory Servers being synchronized. These privileged credentials are encrypted before they are stored in the product’s configuration directory.

Persistent Storage Protection Summary

Persistent Storage Protection Summary summarize how Identity Synchronization for Windows protects sensitive information that is stored on disk.

Table 12–2 Persistent Storage Protection

Persistent Storage 

Confidential Information 

Protection 

Product’s Configuration Stored in a Configuration Directory Server 

Credentials for accessing the directories and per Message Queue topic 3DES keys are stored in the product’s configuration directory. 

All sensitive information stored in the product’s configuration directory is encrypted with a 3DES key that is generated from the configuration password. See Hardening Your Security for recommendations to further protect the product’s configuration directory.

Directory Server Retro Changelog 

The Directory Server Plug-in captures password changes and encrypts them before writing them to the Directory Server Retro Changelog. 

The Directory Server Plug-in encrypts all user password changes with a 3DES key that is unique to each deployment. 

Message Queue Broker Persistent Storage 

The Message Queue broker stores password synchronization messages sent between all connectors. 

With the exception of log messages, all persisted messages are encrypted with per-topic 3DES keys. 

Message Queue Broker Directory Credentials 

The Message Queue broker authenticates users against the product’s configuration directory. It connects to the configuration directory using the directory administrative user name and password provided during Core installation. 

The directory password is stored in a passfile, which is protected with file system access controls. 

System Manager Boot File 

The system manager’s boot file contains information for accessing the configuration. This includes the configuration password and the directory administrative user name and password provided during Core installation. 

This file is protected with file system access controls. 

Connectors and Central Logger Boot Files 

Each connector as well as the central logger have an initial configuration file with credentials for accessing the Message Queue. 

These files are protected with file system access controls. 

Directory Server Plug-in Boot Configuration 

The Plug-in’s configuration, stored in cn=config, includes credentials for connecting to the connector. 

The cn=config subtree is protected with ACIs and the dse.ldif file, which mirrors this tree, is protected with file system access controls.

NT Password Filter DLL and NT Change Detector Boot Configuration 

The NT subcomponent’s configuration, which is stored in the Windows registry, includes credentials for connecting to the connector. 

If access to the PDCs registry is not secure, these registry keys can be protected with access controls. 

Windows Connector’s Object Cache 

Windows connectors store hashed user passwords in the connector’s object cache. 

The passwords are not stored in the clear but encrypted with MD5 hashes. These database files are protected with file system access controls. (see Hardening Your Security

Hardening Your Security

This section depicts potential security weaknesses in the current release of the product and recommendations as to how to extend and harden security outside the product’s default configuration. It includes the following:

Configuration Password

The configuration password is used to protect sensitive configuration information but the installation program does not enforce any password policy for this password; be sure that this password follows some strict guidelines choose a complex password that is not easily guessed and follow standard policy guidelines for strong passwords.

For example, it should be at least eight characters long, include upper case letters, lower case letters, and non-alphanumeric characters. It should not include your name, initials, or dates.

Creating Configuration Directory Credentials

To access the Directory Server where the product’s configuration directory resides, your credentials must be in the Configuration Administrators group. However, if you need to create credentials other than admin for any reason, consider the following:

The installation program requires you to provide credentials for a user stored in the Console administrative subtree. However, the Core installation program will not expand users other than admin into “uid=admin,ou=Administrators, ou=TopologyManagement, o=NetscapeRoot”. Therefore, you must specify the entire DN during Core installation.

ProcedureTo Create a New User Other Than admin

  1. Create a user in:


    ou=Administrators, ou=TopologyManagement, o=NetscapeRoot
  2. Add the new credentials to the Configuration Administrators group.

  3. Set ACIs to allow only this user or all users in the Configuration Administrators group to access the Directory Server where the product’s configuration directory is stored.

  4. Specify entire DN during Core installation.

    For more information about managing access controls in the Directory Server, see Chapter 6, Directory Server Access Control, in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide

Message Queue Client Certificate Validation

By default, clients of the Message Queue, such as the connectors and system manager, accept any SSL certificate that the Message Queue broker returns.

ProcedureTo Validate the Message Queue Client Certificate

  1. To override this setting and force Message Queue clients to validate the Message Queue broker’s certificate, edit:

    installation_root/resources/WatchList.properties

  2. Add the following to the JVM arguments of each process in Watchlist.properties :

    -Djavax.net.ssl.trustStore=keystore_path-DimqSSLIsHostTrusted=false

  3. Restart the Identity Synchronization for Windows daemon or service.

    The javax.net.ssl.trustStore property should point to a JSEE keystore that trusts the broker certificate, for example, /etc/imq/keystore can be used on the machine where Core was installed because this is the same keystore used by the broker.

Message Queue Self-Signed SSL Certificate

By default, the Message Queue broker uses a self-signed SSL certificate. To install a different certificate, use the keytool utility that ships with Java to modify the broker’s keystore (/var/imq/instances/isw-broker/etc/keystore on Solaris, /var/opt/sun/mq/instances/isw-broker/etc/keystore on Linux, and mq_installation_root /var/instances/isw-broker/etc/keystore on Windows 2000). The alias of the certificate must be imq.

Access to the Message Queue Broker

By default, the Message Queue uses dynamic ports for all services except for its port mapper. To access the broker trough a firewall or restrict the set of hosts that can connect to the broker, the broker should use fixed ports for all services.

This can be achieved by setting the imq.service_name protocol_type .port broker configuration properties. Refer to the Sun Java System Message Queue Administration Guide for more information.

Configuration Directory Certificate Validation

The system manager accepts any certificate when connecting to the product’s configuration directory over SSL; the Message Queue broker accepts any certificate when connecting to the product’s configuration directory over SSL. Currently, there is no way to make either the system manager or the Message Queue broker validate the product’s configuration directory SSL certificates.

Restricting Access to the Configuration Directory

When Core is installed, the process of adding information to the Directory Server where the product’s configuration directory is stored does not include adding any access control information. To restrict access to only configuration Administrators, the following ACI can be used:

(targetattr = "*")
(target = "ldap://ou=IdentitySynchronization,
ou=Services,dc=example,dc=com")
(version 3.0;acl "Test";deny (all)
(groupdn != "ldap://cn=Configuration Administrators,
ou=Groups, ou=TopologyManagement, o=NetscapeRoot");)

For more information about managing access controls in the Directory Server, see Chapter 6, Directory Server Access Control, in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide

Securing Replicated Configurations

Deployments connecting to Directory Servers using replication follow the same rules identified in Security Overview. This section gives an example replicated configuration and explains how to enable use of SSL in this configuration.


Note –

For an overview of planning, deploying, and securing replicated configurations see Appendix D, Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows


Securing Replicated Configurations lists the configuration components requiring CA certificates and identifies which certificates are required where.

Table 12–3 MMR Configuration Components Requiring CA Certificates

Component 

Required CA certificates 

Preferred Directory Server Replicated Master 

Active Directory System 

Secondary Directory Server Replicated Master 

Active Directory System 

Read-only Directory Server Hub(s) 

Preferred Directory Server Replicated Master 

Secondary Directory Server Replicated Master 

Directory Server Connector 

Preferred Directory Server Replicated Master 

Secondary Directory Server Replicated Master 

Active Directory Connector

Active Directory System 

Replicated configuration shows Identity Synchronization for Windows installed in an MMR configuration, where there are two replicated Directory Server masters with multiple Directory Server read-only hubs or consumers. Each Directory Server has a Plug-in and there is only one Directory Server Connector, one Active Directory system, and one Active Directory Connector.

Figure 12–2 Replicated Configuration

Replicated deployment of Identity Synchronization for
Windows Components

When the Directory Server source is configured for SSL, you must make sure that both the preferred and secondary Directory Server certificates are trusted by the replica Directory Server. This is true for every Directory Server Plug-in of type other that you install on a system with a Directory Server hub or read-only replica.


Note –

Directory Server Plug-ins have access to the same CA certificates as its associated Directory Server.

The above diagram is specific to two Directory Server masters. But you can extended this to contain multiple masters.


Using idsync certinfo

Use the idsync certinfo utility to determine what certificates are required based on the current Identity Synchronization for Windows SSL settings. Execute idsync certinfo to retrieve information about what certificates are required in each certificate database.


Note –

You must be sure that when you are configuring the Directory Server source for SSL, both the preferred and secondary Directory Server source certificates are trusted by the replica Directory Server for all Directory subcomponents or Plug-ins.

If Identity Synchronization for Windows tries to establish SSL connections (with the trust all certificates setting enabled), and the server’s hostname does not match the hostname provided in the certificate presented by the server during the SSL negotiation phase, the Identity Synchronization for Windows Connector will refuse to establish the connection.

The directory source hostname in the Identity Synchronization for Windows configuration must always match the hostname embedded in the certificate used by that directory source.


Arguments

Arguments describes the arguments you can use with the idsync certinfo subcommand.

Table 12–4 certinfo Arguments

Argument 

Description 

-h CR-hostname

Specifies the configuration directory hostname. This argument defaults to the values specified during Core installation. 

-p CR-port-no

Specifies the configuration directory LDAP port number. (Default is 389)

-D bind-DN

Specifies the configuration directory bind distinguished name (DN). This argument defaults to the values specified during Core installation. 

-w bind-password | -

Specifies the configuration directory bind password. The - value reads the password from standard input (STDIN).

-s rootsuffix

Specifies the configuration directory rootsuffix. Where rootsuffix is a distinguished name such as dc=example,dc=com. This argument defaults to the values specified during Core installation.

-q configuration_password

Specifies the configuration password. The - value reads the password from standard input (STDIN).

Usage

The following example uses idsync certinfo to search for system components designated to run under SSL communications. The results of this example identifies two connectors (CNN101 and CNN100) and provides instructions as to where to import the appropriate CA certificate.


:\Program Files\Sun\MPS\isw-
hostname\bin idsync certinfo -h
CR-hostname -p 389 -D 
"cn=Directory Manager" -w dirmanager -s dc=example,dc=com
 -q password
Connector: CNN101
Certificate Database Location: C:\Program Files\Sun\MPS\isw-
hostname\etc\CNN101
Get ’Active Directory CA’ certificate from Active Directory 
and import into Active Directory Connector certificate db
for server ldaps::/
hostname.example.com:636
Connector: CNN100 Certificate Database Location:
C:\Program Files\Sun\MPS\isw-
hostname\etc\CNN100
Export ’Directory Server CA’ certificate
from Directory Server certificate db and
import into Directory Server Connector certificate db
ldaps://hostname.example.com:636
Export ’Active Directory CA’ certificate
from Active Directory Server
hostname.example.sun.com:389 
and import into Directory Server Server certificate db
for server ldaps://hostname.example.com:638
SUCCESS

Enabling SSL in Directory Server

Follow these steps to enable SSL in a Directory Server using a self-signed certificate.


Note –

These abbreviated procedures are for your convenience. Refer to the Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide for more information.


ProcedureTo Enable SSL in Directory Server

Note: The following procedure is applicable only for Solaris because Directory Server 6.0 is not yet available for Windows

  1. Create a DS instance

    /opt/SUNWdsee/ds6/bin/dsadm create -p non-ldap-port-P ldap-secure-port <DS-server-root>/slapd-<hostname>

  2. Start the instance

    /opt/SUNWdsee/ds6/bin/dsadm start <DS-server-root>/slapd-<hostname>

  3. Create a self-signed certificate

    /opt/SUNWdsee/ds6/bin/dsadm add-selfsign-cert -S "cn=<machine name with domain>,O=<preferred root suffix>"/<DS-server-root>/slapd-<hostname>/<certificate name>

    Where S = Create an individual certificate and add it to database,the second variable represents the path of Directory Server instance and the last variable is for the certificate alias.

  4. Set the server properties to this certificate

    /opt/SUNWdsee/ds6/bin/dsconf set-server-prop -p non-ldap-port ssl-rsa-cert-name:<certificate name>

  5. Restart the DS

    /opt/SUNWdsee/ds6/bin/dsadm restart /<DS-server-root>/slapd-<hostname>/

  6. Now stop the DS and remove the default Cert (this ensures that the above generated certificate will be the default cert)

    /opt/SUNWdsee/ds6/bin/dsadm stop /<DS-server-root>/slapd-<hostname>/

  7. Now remove the default certificate

    /opt/SUNWdsee/ds6/bin/dsadm remove-cert /<DS-server-root>/slapd-<hostname>/ defaultCert

    where the first variable represents the slapd-path and the second variable represents the alias of the certificate. In case you want to export the above default cert, following is the command

    /opt/SUNWdsee/ds6/bin/dsadm export-cert -o /<any path>/slapd-cert.export /<DS-server-root>/slapd-<hostname>/ <original default cert alias>

    where o=output file (/<any path>/slapd-cert.export), the second variable represents the slapd-path and the third variable represents the certificate alias.

Retrieving the CA Certificate from the Directory Server Certificate Database

Ensure that you have enabled SSL in Directory Server. To export the Directory Server certificate to a temporary file so that you can import it into the certificate database of the Directory Server Connector, issue the following command:

<ISW-server-root>\shared\bin\certutil.exe -L -d . 
-P slapd-hostname- -n server-cert -a \ > C:\s-cert.txt

ISW-server-root is the path where ISW-hostname directory is present.

These examples are run in the alias directory immediately below the server root. Otherwise, Directory Server will not find the certificate database.

Retrieving the CA Certificate from the Directory Server (using dsadm command on Solaris platform)

Ensure that you have enabled SSL in Directory Server. To retrieve the CA certificate issue the following command:

/opt/SUNWdsee/ds6/bin/dsadm export-cert -o /<any path>
/slapd-cert.export /<DS-server-root>/slapd-<hostname>/
<original default cert alias>

Enabling SSL in the Active Directory Connector

Identity Synchronization for Windows automatically retrieves Active Directory SSL certificates over SSL and imports them into the Connector’s certificate database using the same credentials you provided for the Connector.

However; if an error occurs (for example, invalid credentials or no SSL certificates were found), you can retrieve an Active Directory CA certificate and add it to the Connector certificate database. See the following sections for instructions:

Retrieving an Active Directory Certificate

If an error occurs, you can use certutil (a program that ships with Windows 2000/2003) or LDAP to retrieve an Active Directory certificate, as described in the following sections.


Note –

The certutil command discussed in this section is not the same as the certutil command that ships with the Directory Server and discussed previously in this publication.


Using Window’s Certutil

ProcedureTo Retrieve an Active Directory Certificate Using the certutil program

  1. Run the following command from the Active Directory machine to export the certificate.


    C:\>certutil -ca.cert cacert.bin
  2. You can then import thecacert.bin file into a certificate database.

Using LDAP

ProcedureTo Retrieve an Active Directory Certificate using LDAP

  1. Execute the following search against Active Directory:


    ldapsearch -h CR-hostname -D administrator_DN -w administrator_password 
    -b "cn=configuration,dc=put,dc=your,dc=domain,dc=here" "cacertificate=*"

    Where the administrator_DN might look like:


    cn=administrator,cn=users,dc=put,dc=your,dc=domain,dc=here

    In this example, the domain name is: put.your.domain.name.here.

    Several entries will match the search filter. You probably need the entry using cn=Certification Authorities, cn=Public Key Services in its DN.

  2. Open a text editor and cut the first value of the first CA certificate attribute (it should be a base64 encoded text block). Paste that value (text block) into the text editor (only the value). Edit the contents, so that none of the lines start with white space.

  3. Add-----BEGIN CERTIFICATE----- before the first line and -----END CERTIFICATE----- after the last line. See the following example:


    -----BEGIN CERTIFICATE-----
    MIIDvjCCA2igAwIBAgIQDgoyk+Tu14NGoQnxhmNHLjANBgk
    qhkiG9w0BAQUFADCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG
    9sZEBzdW4uY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV
    FgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1p
    Y3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1U
    EAxMLUmVzdGF1cmFudHMwHhcNMDIwMTExMDA1NDA5WhcNMT
    IwMTExMDA1OTQ2WjCBjjEeMBwGCSqGSIb3DQEJARYPYmVyd
    G9sZEBzdW4uY29tMQswCQYDVQQGEwJVUELMAkGA1UECBMCV
    FgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1p
    Y3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1U
    EAxMLUmVzdGF1cmFudHMwXDANBgkqhkiG9w0BAQEFAANLAD
    BIAkEAyekZa8gwwhw3rLK3eV/12St1DVUsg31LOu3CnB8cM
    HQZXlgiUgtQ0hm2kpZ4nEhwCAHhFLD3iIhIP4BGWQFjcwID
    AQABo4IBnjCCAZowEwYJKwYBBAGCNxQCBAYeBABDAEEwCwY
    DVR0PBAQDAgFGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBB
    YEFJ5Bgt6Oypq7T8Oykw4LH6ws2d/IMIIBMgYDVR0fBIIBK
    TCCASUwgdOggdCggc2GgcpsZGFwOi8vL0NOPVJlc3RhdXJh
    bnRzLENOPWRvd2l0Y2hlcixDTj1DRFAsQ049UHVibGljJTI
    wS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZm
    lndXJhdGlvbixEQz1yZXN0YXVyYW50cyxEQz1jZW50cmFsL
    RPXN1bixEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9u
    TGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGl
    vblBvaW50ME2gS6BJhkdodHRwOi8vZG93aXRjaGVyLnJlc3
    RhdXJhbnRzLmNlbnRyYWwuc3VuLmNvbS9DZXJ0RW5yb2xsL
    1Jlc3RhdXJhbnRzLmNybDAQBgkrBgEEAYI3FQEEAwIBADAN
    BgkqhkiG9w0BAQUFAANBAL5R9R+ONDdVHWu/5Sd9Tn9dpxN
    8oegjS88ztv1HD6XSTDzGTuaaVebSZV3I+ghSInsgQbH0gW
    4fGRwaI BvePI4=
    -----END CERTIFICATE-----
  4. Save the certificate into a file (such as ad-cert.txt).

  5. You can then import that file (for example, ad-cert.txt) into a certificate database. Continue to the next section, Adding Active Directory Certificates to the Connector’s Certificate Database

Adding Active Directory Certificates to the Connector’s Certificate Database

Use this procedure only if you enabled SSL for the Active Directory Connector after installing the Connector or if invalid credentials were provided during installation.

ProcedureTo Add Active Directory Certificate to the Connector's Certificate Database

  1. On the machine where the Active Directory Connector is installed, stop the Identity Synchronization for Windows service/daemon.

  2. Retrieve the Active Directory CA certificate using one of the following methods:

  3. Assuming the Active Directory Connector has connector ID CNN101 (see logs/central/ error.log for a mapping from connector ID to the directory source it manages), go to its certificate database directory on the machine where it was installed, and import the certificate file:

    • If the certificate was retrieved using certutil, type:

      <ISW-server-root>\shared\bin\certutil.exe -A -d . -n ad-ca-cert -t C,, -i \cacert.bin
    • If the certificate was retrieved using LDAP, type:

      <ISW-server-root>\shared\bin\certutil.exe -A -d . -n ad-ca-cert -t C,,
       -a -i \ad-cert.txt

      ISW-server-root is the path where ISW-hostname directory is present

    On Solaris, the certificate can be imported using dsadm in the following manner:

    /opt/SUNWdsee/ds6/bin/dsadm add-cert -C <DS-server-root>/slapd-<hostname>/ ad-ca-cert cacert.bin

    where ad-ca-cert is the name of the certificate assigned after the import and cacert.bin is the certificate about to be imported

  4. Restart the Identity Synchronization for Windows service/daemon.


    Note –

    Because the Directory Server certutil.exe is installed automatically when you install Directory Server, you will not be able to add a CA certificate to a connector installed on a machine with no Directory Server.

    At a minimum, you must install the Sun Java System Server Basic Libraries and Sun Java System Server Basic System Libraries from the Directory Server package on the server where the Active Directory Connector is installed. (You do not have to install the Administration Server or Directory Server components.)

    In addition, be sure to select the JRE subcomponent from the Console (to ensure your ability to uninstall).


Adding Active Directory Certificates to Directory Server


Note –

Make sure that you have enabled SSL in Directory Server.


ProcedureTo Add the Active Directory CA certificate to the Directory Server Certificate Database

  1. Retrieve the Active Directory CA certificate using one of the following methods:

  2. Stop Directory Server.

  3. Import cacert.bin into the <DS-server-root>\slapd-hostname\alias folder on Windows and for Solaris and Linux import it into <DS-server-root>/slapd-hostname/alias directory.

  4. On the machine where Directory Server is installed, import the Active Directory CA certificate as follows:

    • If the certificate was retrieved using certutil, type:


      <ISW_server_root>\shared\bin\certutil.exe -A -d . 
      -P slapd-hostname- -n ad-ca-cert -t C,, -i \cacert.bin
    • If the certificate was retrieved using LDAP, type:


      <ISW_server_root>\shared\bin\certutil.exe -A -d . 
      -P slapd-hostname- -n ad-ca-cert -t C,, -a -i \ad-cert.txt

      ISW-server-root is the path where ISW-hostname directory is present

    • If the certificate was retrieved using dsadm (on Solaris), type:


      /opt/SUNWdsee/ds6/bin/dsadm add-cert -C <DS-server-root>
      /slapd-<hostname>/ ad-ca-cert cacert.bin

      Where ad-ca-cert is the name of the certificate assigned after the import and cacert.bin is the certificate about to be imported

  5. Start Directory Server.

Adding Directory Server Certificates to the Directory Server Connector

If you enable SSL communication between the Directory Server Plug-in and Active Directory, then you must add the Active Directory CA Certificate to the certificate database of each Directory Server master.

ProcedureTo Add the Directory Server Certificates to the Directory Server Connector

  1. On the machine where the Directory Server Connector is installed, stop the Identity Synchronization for Windows service/daemon.

  2. Retrieve the Directory Server CA certificate.

  3. Assuming the Directory Server Connector has connector ID CNN100 (see logs/example/ error.log for a mapping from connector ID to the directory source it manages), go to its certificate database directory on the machine where it was installed, and import the cacert.bin file:

    <ISW_server_root>\shared\bin\certutil.exe -A -d . -n ds-cert -t C,, -i C:\s-cert

    ISW-server-root is the path where ISW-hostname directory is present.

  4. Restart the Identity Synchronization for Windows service/daemon.