Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide

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 11–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 11–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 11–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