|
| |
| Sun Java System Identity Synchronization for Windows 1 2004Q3 Installation and Configuration Guide | |
Chapter 11
Configuring SecurityThis chapter provides important information about configuring security for your deployment. The information is organized as follows:
Security OverviewPasswords 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.
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 (more...) ). 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 Plugin encrypts all user password changes with a 3DES key.
SSL and 3DES Keys Protection Summary
Table 11-1 summarizes how Identity Synchronization for Windows protects sensitive information that is sent over the network.
Figure 11-1 contains an overview of the security features discussed in this section.
Figure 11-1 Identity Synchronization for Windows Security Overview
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
Table 11-2 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 ChangelogThe Directory Server Plugin captures password changes and encrypts them before writing them to the Directory Server Retro Changelog.
The Directory Server Plugin 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 Plugin Boot Configuration
The Plugin’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 SecurityThis 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.
To create a new user other than admin:
- Create a user in
ou=Administrators, ou=TopologyManagement, o=NetscapeRoot
- Add the new credentials to the Configuration Administrators group
- 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
- Specify entire DN during Core installation
For more information about managing access controls in the Directory Server, see Sun Java System Directory Server 5 2004Q2 Administrator’s Guide, Chapter 6: “Managing Access Control.”
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.
- To override this setting and force Message Queue clients to validate the Message Queue broker’s certificate, edit:
<installation_root>/resources/WatchList.properties
- Add the following to the JVM arguments of each process in Watchlist.properties:
-Djavax.net.ssl.trustStore=<keystore_path> -DimqSSLIsHostTrusted=false
- 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 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 Administrator’s 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 Sun Java System Directory Server 5 2004Q2 Administrator’s Guide, Chapter 6: “Managing Access Control.”
Securing Replicated ConfigurationsDeployments 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 E, "Installation Notes for Replicated Environments."
Table 11-3 lists the configuration components requiring CA certificates and identifies which certificates are required where.
Figure 11-2 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 Plugin and there is only one Directory Server Connector, one Active Directory system, and one Active Directory Connector.
Figure 11-2 Replicated Configuration
Using idsync certinfoUse 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.
Arguments
Table 11-4 describes the arguments you can use with the idsync certinfo subcommand:
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.
Enabling SSL in Directory ServerFollow 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 Directory Server 5 2004Q2 Administrator’s Guide for more information.
- Create a new key certificate database for Directory Server by entering:
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -d . -P slapd-hostname-
In order to finish creating your database, you
must enter a password which will be used to
encrypt this key and any future keys.
The password must be at least 8 characters long,
and must contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
Note
These examples are run in the alias directory immediately below the server root. Otherwise, Directory Server will not be able to find the certificate database.
- Generate a self-signed certificate, which will be the server certificate used by Directory Server. Be sure you choose the subject DN according to the hostname of the server where Directory Server is running.
Note
By default, a self-signed certificate is valid for three months. If you want to increase or decrease this time period, use the -v <months-valid> option. For example, to increase the time period to 24 months, enter -v 21 or to decrease the time period to one month, enter -v -2.
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -d . -P slapd-hostname- -S -n server-cert -s "cn=hostname.example.com,c=us" -x -t CTu,,
A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.
To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
Continue typing until the progress meter is full:
|************************************************************|
Finished. Press enter to continue:
Enter Password or Pin for "NSS Certificate DB":
Generating key. This may take a few moments...
- Display the certificates for checking purposes.
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -L -d . -P slapd-hostname-
Certificate Name Trust Attributes
server-cert CTu,,
p Valid peer
P Trusted peer (implies p)
c Valid CA
T Trusted CA to issue client certs (implies c)
C Trusted CA to certs(only server certs for ssl) (implies c)
u User cert
w Send warning
- Create a PIN file, so that the certificate database password does not have to be entered each time you restart Directory Server.
C:\Program Files\Sun\MPS\alias > echo Internal (Software) Token:<secret12> slapd-hostname-pin.txt
- Enable SSL in the Directory Server as follows:
- Open the Console.
- Select the Configuration tab.
- Select the Encryption tab (on the right pane).
- Select Enable SSL for this server.
- Select Use this cipher family: RSA.
- Click Save and click OK twice.
- Select the Network tab.
- Update the Secure Port field. If running on the same machine as Active Directory, the port must be changed from 636 to an unused port or Directory Server will not start.
- Click Save, then yes, then OK.
- Select the Tasks tab (on the top).
- Click Restart Directory Server, then click yes.
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:
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -L -d . -P slapd-hostname- -n server-cert -a > C:\s-cert.txt
These examples are run in the alias directory immediately below the server root. Otherwise, Directory Server will not find the certificate database.
Enabling SSL in the Active Directory ConnectorIdentity 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
To retrieve an Active Directory Certificate using the certutil program:
Using LDAP
To retrieve an Active Directory Certificate using LDAP:
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.
- 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.
- Add -----BEGIN CERTIFICATE----- before the first line and -----END CERTIFICATE----- after the last line. See the following example:
-----BEGIN CERTIFICATE-----
MIIDvjCCA2igAwIBAgIQDgoyk+Tu14NGoQnxhmNHLjANBgkqhkiG9w0BAQUFA DCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG9sZEBzdW4uY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVFgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczE QMA4GA1UECxMHaVBsYW5ldDEUMBIGA1UEAxMLUmVzdGF1cmFudHMwHhcNMDIwMTExMDA1ND A5WhcNMTIwMTExMDA1OTQ2WjCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG9sZEBzdW4uY29tM QswCQYDVQQGEwJVUELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU 3VuIE1pY3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1UEAxMLUmVzdGF1cmFu dHMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAyekZa8gwwhw3rLK3eV/12St1DVUsg31LOu3 CnB8cMHQZXlgiUgtQ0hm2kpZ4nEhwCAHhFLD3iIhIP4BGWQFjcwIDAQABo4IBnjCCAZowEw YJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAgFGMA8GA1UdEwEB/wQFMAMBAf8wHQYDV R0OBBYEFJ5Bgt6Oypq7T8Oykw4LH6ws2d/IMIIBMgYDVR0fBIIBKTCCASUwgdOggdCggc2G gcpsZGFwOi8vL0NOPVJlc3RhdXJhbnRzLENOPWRvd2l0Y2hlcixDTj1DRFAsQ049UHVibGl jJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1yZX N0YXVyYW50cyxEQz1jZW50cmFsLERDPXN1bixEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0a W9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50ME2gS6BJhkdo dHRwOi8vZG93aXRjaGVyLnJlc3RhdXJhbnRzLmNlbnRyYWwuc3VuLmNvbS9DZXJ0RW5yb2x sL1Jlc3RhdXJhbnRzLmNybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAANBAL 5R9R+ONDdVHWu/5Sd9Tn9dpxN8oegjS88ztv1HD6XSTDzGTuaaVebSZV3I+ghSInsgQbH0g W4fGRwaI BvePI4=
-----END CERTIFICATE-----
- Save the certificate into a file (such as ad-cert.txt).
- 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 for instructions.
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.
- On the machine where the Active Directory Connector is installed, stop the Identity Synchronization for Windows service/daemon.
- Retrieve the Active Directory CA certificate using one of the following methods:
- 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:- Restart the Identity Synchronization for Windows service/daemon.
Note
Because the Directory Server certutil.exe is installed automatically when you install Directory Server 5 2004Q2, 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 5 2004Q2 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 ServerFollow these steps to add the Active Directory CA certificate to the Directory Server certificate database.
- Retrieve the Active Directory CA certificate using one of the following methods:
- Stop Directory Server.
- On the machine where Directory Server is installed, import the Active Directory CA certificate as follows:
- If the certificate was retrieves using certutil, type:
C:\\Program Files\Sun\MPS\shared\bin\certutil.exe -A -d . -P slapd-hostname- -n ad-ca-cert -t C,, -i \cacert.bin
- If the certificate was retrieves using LDAP, type:
C:\\Program Files\Sun\MPS\shared\bin\certutil.exe -A -d . -P slapd-hostname- -n ad-ca-cert -t C,, -a -i \ad-cert.txt
- Start Directory Server.
Adding Directory Server Certificates to the Directory Server ConnectorIf you enable SSL communication between the Directory Server Plugin and Active Directory, then you must add the Active Directory CA Certificate to the certificate database of each Directory Server master. Use the following steps:
- On the machine where the Directory Server Connector is installed, stop the Identity Synchronization for Windows service/daemon.
- Retrieve the Directory Server CA certificate.
- 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:
Note
If the certificate was obtained in ASCII form, add an “-a” argument to the certutil command line to indicate that it is in ASCII form rather than binary form.
- Restart the Identity Synchronization for Windows service/daemon.
