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:
An eavesdropper intercepting a clear text password over the network
An attacker manipulating a connector to change a user’s password to a value of their choosing, which is equivalent to capturing the user’s clear text password
An attacker gaining access to a privileged component of Identity Synchronization for Windows
An unprivileged user recovering a password from a file stored on disk.
An intruder recovering a password from a hard disk that was removed from one of the components of the system. This could be a password being synchronized, or it could be a system password that is used to access a directory.
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.
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.
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.
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.
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 summarizes how Identity Synchronization for Windows protects sensitive information that is sent over the network.
Table 10–1 Protecting Sensitive Information Using Network Security
SSL and 3DES Keys Protection Summary contains an overview of the security features discussed in this section.
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.
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.
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 summarize how Identity Synchronization for Windows protects sensitive information that is stored on disk.
Table 10–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 |