| Sun ONE Identity Synchronization for Windows Installation and Configuration Guide |
Chapter 10
Configuring SecurityThis chapter contains the following items:
Some of the information in this section is written with an assumption that you are familiar with the basic concepts of public-key cryptography and Secure Sockets Layer (SSL) protocol, and understand the concepts of intranet, extranet, and the 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 manual, Managing Servers with iPlanet Console 5.0.
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.
Configuration Password
To protect sensitive information while it is stored in the product’s configuration registry and while it is transferred over the network, Identity Synchronization for Windows uses a configuration password. This configuration password is chosen by the administrator during core installation and is provided whenever the console or installer is run.
SSL
Identity Synchronization for Windows can be configured to use LDAP over SSL everywhere that components use LDAP, the one exception to this is the installer. The installer cannot communicate with the Directory Server where the product’s configuration registry is stored, and with the directories being synchronized over SSL. All access to the Sun ONE Message Queue is protected with SSL. SSL is mandatory between the Active Directory connector and Active Directory when synchronizing from the Sun ONE Directory Server to Active Directory.
Generated 3DES Keys
A 3DES key generated from the configuration password is used to secure all sensitive information in the product’s configuration registry. 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 (subcomponent) plugin encrypts all user password changes with a 3DES key
SSL & 3DES Keys Protection Summary
The following table summarizes how Identity Synchronization for Windows protects sensitive information that is sent over the network.
Table 10-1 Network Security
Figure 10-1 contains an overview of the security features discussed in this section.
Figure 10-1 Identity Synchronization for Windows Security Overview
Sun ONE Message Queue Access Controls
Identity Synchronization for Windows uses Sun ONE 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 only known to Sun ONE Message Queue and to the connector are provided to access the Sun ONE Message Queue broker. Each message sent over the Sun ONE MQ 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.
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 registry.
Persistent Storage Protection Summary
The following tables summarize how Identity Synchronization for Windows protects sensitive information that is stored on disk.
Table 10-2 Persistent Storage Protection
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 installer does not enforce any password policy for this password; make 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.
Active Directory Credentials during Installation
When the synchronization settings are configured from Sun to Windows SSL is mandatory between the Active Directory connector and Active Directory. During installation of the Active Directory Connector, in order to search for a CA Certificate, (this certificate is eventually stored in the local AD connector certificate database) the installer prompts you for Active Directory Credentials. Please note that while the installer provides “Administrator” as the default user in the installation panel, Administrator rights are not required to retrieve the certificate.
The installer cannot communicate with Active Directory over SSL. Therefore these Active Directory credentials, although not required to be administrative are transferred over the network in the clear.
Consequently, one of the following might be desirable,
- Retrieve the certificate (see Enabling SSL in the Active Directory Connector) and manually add it to the Active Directory connector’s certificate database.
- Create a temporary account used only for the purpose of reading the CA certificate, after which is deleted.
- Please note that the credentials do not need to be the Administrative.
Directory Server Administrative Credentials During Installation
The installer prompts you for administrative credentials for the Directory Server being synchronized when,
The installer cannot communicate with the Directory Sever over SSL; therefore, these credentials are transferred in the clear.
This is not an issue when installing the Directory Server (subcomponent) plugin as the installer must be run in the same machine where the Directory Server being synchronized is located; however, this is an issue when installing the Directory Server Connector as it does not need to be installed in the same machine as the Directory Server being synchronized. In the latter case one of the following might be desirable,
- Make sure that the network is secure between the machine where the connector is being installed and the Directory Server being synchronized
- Create a temporary administrative password in the Directory Server being synchronized only for the purpose of installing the Directory Server connector.
- Install the Directory Server Connector on the same machine as the Directory Server.
Directory Server User Credentials During Installation
When installing the Directory Server Connector the installer generates a Connector User password and is transferred to the Directory Server over the network in the clear.
Product’s Configuration Registry Credentials During Installation
Every time you run the installer it prompts you for the Directory Server location and credentials where the product’s configuration registry is stored. The installer cannot communicate with this Directory Server over SSL; therefore these credentials, which must be in the group Configuration Administrators (i.e.: admin), are not transferred over the network in the clear.
This is not an issue if core or any other component are installed on the same machine as the Directory Server used to store the products configuration registry.
- Make sure that the network is secure between the machine where the connector is being installed and the Directory Server that stores the product’s configuration registry.
- Install the product’s configuration registry in a different Directory Server than where the data being synchronized resides, this accomplishes reducing the scope of access to a Directory Server that does not also hold user data.
- Create new credentials in the Directory Server storing the product’s configuration registry only for the purpose of creating, modifying and updating the configuration registry; see Creating New product’s Configuration Registry Credentials for details.
Creating New product’s Configuration Registry Credentials
Credentials to access the Directory Server where the product’s configuration registry resides must be in the group Configuration Administrators. You might have a reason to create new credentials other than Admin, if so consider the following:
- The installer requires the user supply credentials for a user stored in the Console administrative subtree:
ou=Administrators, ou=TopologyManagement, o=NetscapeRoot.
- The core installer will not expand other users than “admin” into “uid=admin,ou=Administrators, ou=TopologyManagement, o=NetscapeRoot"). If you want to supply any username besides admin, you must specify the entire DN during core installation when you are first prompted for these credentials.
- Create the new user under ou=Administrators, ou=TopologyManagement, o=NetscapeRoot.
- Make sure the new credentials are in the group Configuration Administrators.
- Set ACI’s to allow only this user or perhaps all users in the group Configuration Administrators to access the Directory Server where the product’s configuration registry is stored. Documentation on managing access controls in the Sun ONE Directory Server can be found in the Directory Server 5.2 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 Sun ONE Message Queue broker returns.
- To override this setting and force Message Queue clients to validate the Message Queue Broker’s certificate, edit:
<installation-root>/isw-<hostname>/resources/WatchList.properties,
- Add the following to the JVM arguments of each process:
-Djavax.net.ssl.trustStore=<keystore path> -DimqSSLIsHostTrusted=false
- Restart the Identity Synchronization 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 Sun ONE 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 (/etc/imq/keystore on Solaris and <installation-root>/isw-<host name>/imq/etc/keystore on Windows 2000). The alias of the certificate must be imq.
Access to the Message Queue Broker
By default the Sun ONE 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 ONE Message Queue Administrator’s Guide for details.
Product’s Configuration Registry Certificate Validation
The system manager accepts any certificate when connecting to the product’s configuration registry over SSL; the Message Queue Broker accepts any certificate when connecting to the product’s configuration registry over SSL. Currently, there is no way to make either the system manager or the Message Queue Broker validate the product’s configuration registry SSL certificates.
User Passwords in the Windows connector’s Object Cache
Active Directory and NT connectors store unsalted MD5 hashes of user passwords in the connector’s object cache. In order to ensure maximum protection we recommend that you override default permissions of persist/ADP[nnn]/oc:
Restricting Access to the Product’s Configuration Registry
When core is installed, the process of adding information to the Directory Server where the product’s configuration registry 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");)
Documentation on managing access controls in the Sun ONE Directory Server can be found in the Directory Server 5.2 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 Installation Notes for Replicated Environments.
Table 10-3 lists the configuration components requiring CA certificates and identifies which certificates are required where.
Table 10-3
MMR Configuration Components Requiring CA Certificates
Figure 10-2 shows Identity Synchronization for Windows installed in an MMR configuration. There are two replicated Directory Server masters with multiple Directory Server read-only hubs or consumers. Each Directory Server has its own plugin and there is only one Directory Server connector. There is one Active Directory system and one Active Directory connector.
Figure 10-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
idsync certinfo accepts the following arguments:
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.
C:\Program Files\Sun\MPS\isw-hostname\bin> idsync certinfo -h hostname -p 388 -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
Certificate Database Password: LTD8a4kfXtMe95CX
Connector Server Certificate Name:
Get ’Active Directory CA’ certificate from Active Directory and import into Active Directory Connector certificate db for server ldaps:://hostname.example.com:636Connector: CNN100
Certificate Database Location: C:\Program Files\Sun\MPS\isw-hostname\etc\CNN100
Certificate Database Password: d1JESIKFRfriCFnq
Connector Server Certificate Name: server-cert100
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:638SUCCESS
Note
Use the certutil version bundled with Directory Server 5.2. Later versions of certutil are incompatible with Identity Synchronization for Windows.
Enabling SSL in Directory ServerFollow these steps to enable SSL in a Directory Server.
Note
These abbreviated procedures are for your convenience. Refer to the Directory Server 5.2 Administrator’s Guide for more information.
- Create a new key certificate database for the Directory Server by entering:
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -N -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, the Directory Server will not be able to find the certificate database.
- Generate a self-signed certificate - this will be the server certificate used by the Directory Server. Make sure you choose the subject DN according to the hostname of the server where the Directory Server is running.
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 certificate database password does not have to be entered each time the Directory Server is restarted.
C:\Program Files\Sun\MPS\alias > echo Internal (Software) Token:secret12 > slapd-hostname-pin.txt
- Enable SSL in the Directory Server:
- Open the console.
- Select the Configuration tab.
- Select the Encryption tab (on the right pane).
- Check Enable SSL for this server.
- Check Use this cipher family: RSA.
- Click on save and on 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 the Directory Server will not start.
- Click on Save, then yes, then OK.
- Select the Tasks tab (on the top).
- Click on Restart Directory Server, then click on yes.
Retrieving the CA Certificate from the Directory Server Certificate Database
Ensure that you have enabled SSL in the 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\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, the Directory Server will not be able to find the certificate database.
Enabling SSL in the Active Directory ConnectorEnabling SSL in the Active Directory takes several steps:
Retrieving the Active Directory CA Certificate
Retrieving the Active Directory CA Certificate using certutil
From the Active Directory machine run the following command to export the certificate. Note that certutil is a program that ships with Windows 2000.
C:\>certutil -ca.cert cacert.bin
The cacert.bin file can then be imported into a certificate database.
Retrieving the Active Directory CA Certificate over LDAP
where administrator DN looks like cn=administrator,cn=users,dc=put,dc=your,dc=domain,dc=here (the domain name in this case is: put.your.domain.name.here)
There will be several entries matching the above search filter. You probably need the one that has cn=Certification Authorities, cn=Public Key Services in its DN.
- Open up a text editor and cut out the first value of the first CA certificate attribute (it should be a BASE-64 encoded text block). Paste those lines 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. So, in the end you should have something like this:
-----BEGIN CERTIFICATE-----
MIIDvjCCA2igAwIBAgIQDgoyk+Tu14NGoQnxhmNHLjANBgkqhkiG9w0BAQUFA DCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG9sZEBzdW4uY29tMQswCQYDVQQGEwJVUzELMAkGA1UEC BMCVFgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczEQMA4GA1UEC xMHaVBsYW5ldDEUMBIGA1UEAxMLUmVzdGF1cmFudHMwHhcNMDIwMTExMDA1NDA5WhcNMTIwMTExM DA1OTQ2WjCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG9sZEBzdW4uY29tMQswCQYDVQQGEwJVUzELM AkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczEQM A4GA1UECxMHaVBsYW5ldDEUMBIGA1UEAxMLUmVzdGF1cmFudHMwXDANBgkqhkiG9w0BAQEFAANLA DBIAkEAyekZa8gwwhw3rLK3eV/12St1DVUsg31LOu3CnB8cMHQZXlgiUgtQ0hm2kpZ4nEhwCAHhF LD3iIhIP4BGWQFjcwIDAQABo4IBnjCCAZowEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDA gFGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFJ5Bgt6Oypq7T8Oykw4LH6ws2d/IMIIBMgYDV R0fBIIBKTCCASUwgdOggdCggc2GgcpsZGFwOi8vL0NOPVJlc3RhdXJhbnRzLENOPWRvd2l0Y2hlc ixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlnd XJhdGlvbixEQz1yZXN0YXVyYW50cyxEQz1jZW50cmFsLERDPXN1bixEQz1jb20/Y2VydGlmaWNhd GVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50ME2gS 6BJhkdodHRwOi8vZG93aXRjaGVyLnJlc3RhdXJhbnRzLmNlbnRyYWwuc3VuLmNvbS9DZXJ0RW5yb 2xsL1Jlc3RhdXJhbnRzLmNybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAANBAL5R9 R+ONDdVHWu/5Sd9Tn9dpxN8oegjS88ztv1HD6XSTDzGTuaaVebSZV3I+ghSInsgQbH0gW4fGRwaI BvePI4=
-----END CERTIFICATE------ Save this into a file, e.g. ad-cert.txt.
The ad-cert.txt file can then be imported into a certificate database.
Adding the Active Directory Certificate to the Connector’s Certificate Database
These steps only need to be followed if SSL is enabled for the Active Directory connector after the connector was installed 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 and save it to a file called cacert.bin.
Note
This procedure assumes that the CA certificate was obtained using the Active Directory certutil tool (see Retrieving the Active Directory CA Certificate using certutil) and will not work if it was obtained over LDAP in ASCII form.
- 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 cacert.bin file:
C:\\Program Files\Sun\Sun\MPS\isw-hostname\shared\bin\certutil.exe -A -d . -n ad-ca-cert -t C,, -i \cacert.bin
Note
If the certificate was obtained in ASCII form over LDAP, then you should add a “-a” argument to the certutil command line to indicate that it is in ASCII form rather than binary.
- Restart the Identity Synchronization for Windows service/daemon.
Adding the Active Directory Certificate to the Directory ServerFollow these steps to add the Active Directory CA certificate to the Directory Server certificate database.
- Retrieve the Active Directory CA certificate and save it to a file called cacert.bin.
- Stop the Directory Server.
- On the machine where Directory Server is installed, import the Active Directory CA certificate:
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -A -d . -P slapd-hostname- -n ad-ca-cert -t C,, -i cacert.bin
Note
If the certificate was obtained in ASCII form over LDAP, then you should add a “-a” argument to the certutil command line to indicate that it is in ASCII form rather than binary.
- Start the Directory Server.
Adding the Directory Server Certificate to the Directory Server Connector
- 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:
C:\Program Files\Sun\MPS\shared\bin\certutil.exe -A -d . -n ds-cert -t C,, -i C:\s-cert.txt
Note
If the certificate was obtained in ASCII form over LDAP, then you should add a “-a” argument to the certutil command line to indicate that it is in ASCII form rather than binary.
- Restart the Identity Synchronization for Windows service/daemon.
