Technical Analysis of bi-directional Sun IDM and AD password syncing

One of the more common uses for Sun Identity Manager is to sync passwords to an Active Directory environment. If AD is not used as the primary authentication service, you'll probably also need to sync passwords back from AD to IDM, so that users can change their password from their workstations. This is especially important in the case where their password has expired and they can't access the IDM web interface to change it without logging into their workstation. Sun IDM provides methods for this bi-directional sync, but the documentation prior to version 8.1 is very sparse and even in 8.1 it is lacking in some areas and fragmented into several separate documents. This post tries to consolidate the information and fill in some of the gaps.

The two additional components that are required for password synchronization are the IDM Gateway, which synchronizes from IDM to AD and PasswordSync, which synchronizes from AD to IDM. Below is a diagram that details how the different components work together and communicate.



Here is a quick list of best practices to follow. For more detail about the communication protocols read on past the bullet points.

• Change the default Gateway encryption key


• Use an active-standby configuration behind a load-balancer for the IDM Gateway. Active-active is not supported.


• Ensure that you are using encryption between the IDM Gateway and the DCs, either Kerberos or SSL.


• Ensure that you are using HTTP over SSL for the communication from the PasswordSync application on the DCs to the PasswordSync servlet.


• Use a JMS server to handle the PasswordSync events. This will help ensure that no password changes are lost and allow for much better auditing of change events.

The communication between the Sun IDM application and the IDM Gateway is done over port 9278 using the usual protocol for communication with resource adapters. This traffic is encrypted using 3DES by the RASecureConnection class. This may come as a bit of a surprise, since the AD resource adapter in IDM has an encryption type setting of None, Kerberos, or SSL. This setting is for the communication between the Gateway and the DC, not between IDM and the Gateway.

Since 3DES is a symmetric protocol, it is important that you change the key from the default key that is compiled into the application. You can do this through the IDM admin interface, Server Tasks -> Run Tasks -> Manage Server Encryption and select "Manage Gateway Keys"

Password changes initiated through standard methods in AD (i.e. administrative resets, user-initiated changes) are sent to IDM through the PasswordSync application. This application is installed on the DC and configured through the user interface as detailed here. It communicates with the PasswordSync servlet, which is shipped with IDM and by default runs as part of the IDM web application. However, it can be split out into a separate servlet container. There are two options for the communication between the PasswordSync servlet and the IDM application. The simpler, but less reliable option is direct communication to the IDM application, the other is to use a Java Messaging Server (JMS), which the IDM application will interface with. This will allow for queuing, guaranteed delivery of the password change messages and better reporting and logging. The JMS method is preferred, as without it, password changes may be lost if there is a problem with the IDM application.

You will need to ensure that the PasswordSync -> PasswordSync servlet communication is encrypted via SSL. You will need to import the SSL certificate that the PasswordSync servlet is using onto the DCs as documented here. You will also need to remember to update it on the DCs whenever the certificate is changed or renewed.

Running Sun Directory Server 6.3 as a non root user

It's a standard best practice to run services with a dedicated user if possible. Sun's Directory server Enterprise Edition supports this, but, as with many Sun products, the documentation on how to do so is scattered in many different places. Here's a quick how-to guide on to do it for DSEE 6.3.1 on Solaris 10. This only covers the Directory Server component, not the Directory Proxy Server or Control Center components. But don't worry, more posts are in the works for those components!

These steps presume that you have already installed the DSEE software.

Step 1, create the user. Here's quick instructions to create username "ldap" with group "ldap":

groupadd ldap
useradd -g ldap -s /bin/false -c "ldap" ldap
usermod -K defaultpriv=basic,proc_owner,net_privaddr ldap

If you're not familiar with Solaris's RBAC (Role Based Access Control) , the last command grants the ldap user the privileges to bind to a privileged port number (net_privaddr), which is needed to use the standard LDAP ports of 389 and 636. The proc_owner command allows the ldap user to send signals to other processes as well as those that it owns.

Step 2, create the directory server instance.

dsadm create -p 389 -P 636 -u ldap -g ldap /opt/ds_homedir

Where the last argument is the directory that you want to use to store the configuration and data for your new instance.

Step 3, enable the service within SMF. This has two functions: first, it will make sure that the service will restart automatically when the server reboots, second, it enables you to start/stop the directory service as the root user without having to switch to the ldap user first.

If you installed using the Native Package install, it's easy, since the installation contains a built-in SMF manifest. Just run the following command to activate it:

dsadm enable-service --type SMF /opt/ds_homedir

However, if you used the ZIP distribution, it's a little more involved, since you have to create your own SMF manifest and register it manually. Below is the one that I use. You'll need to modify the exec commands to specify the directory of your instance. The timeouts are purposely long, as DS will often need a long time to re-check the database after an ungraceful shutdown (i.e. system crash):

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>

<!--
    Document   : ds_ldaptest2.xml
    Created on : 23-OCT-2009
    Author     : Keith Bucher
    Description: The SMF Service Manifest file for Directory Server 6
-->

<service_bundle type="manifest"
                name="SUNWldap-directory services">
  <service name="application/sun/ds" type="service" version="1">
    <dependency name="filesystems" grouping="require_all"
              restart_on="none" type="service">
      <service_fmri value="svc:/system/filesystem/local:default">
    </dependency>
    <dependency name="network" grouping="require_all"
             restart_on="none" type="service">
      <service_fmri value="svc:/network/initial:default">
    </dependency>
    <exec_method type="method"
                 name="start"
                 exec="/opt/sun/ds6/bin/dsadm start --exec /opt/ds_ldaptest2"
                 timeout_seconds="600">
      <method_context working_directory=":default">
        <method_credential user="ldap"
                           group=":default"
                           privileges="basic,proc_owner,net_privaddr"/>
      </method_context>
      <stability value="Evolving">
    </exec_method>
    <exec_method type="method"
                 name="stop"
                 exec="/opt/sun/ds6/bin/dsadm stop --exec /opt/ds_ldaptest2"
                 timeout_seconds="600">
      <method_context working_directory=":default">
        <method_credential user="ldap"
                           group=":default"
                           privileges="basic,proc_owner,net_privaddr"/>
      </method_context>
      <stability value="Evolving">
    </exec_method>
    <instance name="default" enabled="false">
    <stability value="Evolving">
    <template>
      <common_name>

        <loctext lang="C"> Directory Server </loctext>
      </common_name>
      <documentation>
        <doc_link name="Directory Server Enterprise Edition 6 Administration Guide" uri="http://docs.sun.com/doc/819-0995/"
/>
      </documentation>
    </template>
  </service>
</service_bundle>

Once you've created this file, use the following commands to register it with SMF and enable the service:

svccfg import /opt/ds_homedir/config/manifest_file.xml
svcadm enable svc:/application/sun/ds:default