12.3. Steps for Configuring Windows Sync

Configuring synchronization is very similar to configuring replication. It requires configuring the database as a master with a changelog and creating an agreement to define synchronization. A common user identity, a sync user, connects to the Windows sync peer to send updates from the Directory Server and to check for updates to sync back to the Directory Server.


To synchronize passwords (which is the only way for users to be active on both Directory Server and Active Directory), synchronization must be configured to run over SSL/TLS. Therefore, this configuration section assumes that SSL/TLS must also be configured.
Configuring synchronization over SSL/TLS is also similar to configuring replication over SSL/TLS. Both sync peers must be configured to trust each other for encrypted sessions (all password operations are performed over TLS/SSL).
All synchronization for user and group entries is passive from the Active Directory side; it is the Directory Server which sends updates on its side and polls for updates on the Active Directory domain. For passwords, the Active Directory server requires a separate password service; this service actively sends password changes from the Active Directory domain to Directory Server.

12.3.1. Step 1: Configure SSL on Directory Server

The full instructions for configuring the Directory Server to run in SSL are at Section 7.4.2, “Enabling TLS/SSL Only in the Directory Server”. Basically, the Directory Server needs to have the appropriate SSL certificates installed, be configured to run over an SSL port, and allow client authentication from other servers.
Two certificates must be issued and installed on both the Directory Server and the Active Directory sync peer:
  • CA certificate, shared between the Directory Server and Active Directory
  • Server certificates for the Directory Server and Active Directory sync peers, which are accessible by the sync services
To set up SSL:
  1. Generate a certificate request.
    1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
    2. Select the Server Certs tab, and click the Request button at the bottom.
    3. Fill in the certificate information, and save the certificate request to a file.
  2. Submit the certificate to a certificate authority, and retrieve it once it is issued.
    The method for submitting certificate requests and retrieving certificates varies for each CA.
  3. Install the new certificate.
    1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
    2. Select the Server Certs tab, and click Install at the bottom of the window.
    3. Paste in the certificate, and set the password for the token database.
  4. Install the CA certificate for the issuing CA.
    1. Download and save the CA certificate from the CA's site. Each CA has a slightly different way of making its CA certificate available.
    2. In the Directory Server Console, select the Tasks tab, and click Manage Certificates.
    3. Go to the CA Certs tab, and click Install at the bottom of the window.
    4. Paste in the CA certificate or point to the downloaded file, and go through the certificate installer.
  5. Change the server to the SSL port; this is described in much more detail in Section 1.6, “Changing Directory Server Port Numbers”.
    1. Open the Directory Server Console, and open the Configuration tab for the Directory Server.
    2. In the Settings tab, set the secure port for the server to use for TLS/SSL communications, such as 636. Click Save.
    3. Select the Encryption tab in the right pane.
    4. Select the Enable SSL for this Server check box, then select the certificate to use from the drop-down menu. Click Save.
    5. Restart the Directory Server. The Directory Server must be restarted from the command line.
      service dirsrv restart example
      To restart the Directory Server without the password prompt, create a PIN file or use a hardware crypto device. See Section 7.4.4, “Creating a Password File for the Directory Server” for information on how to create a PIN file.

12.3.2. Step 2: Configure the Active Directory Domain


Synchronization can only be configured with an Active Directory domain controller, so make sure that the domain is properly installed and configured.
The first configuration step is to make sure that the Active Directory password complexity policies are are enabled so that the Password Sync service will run.
  1. Run secpol.msc from the command line.
  2. Select Security Settings.
  3. Open Account Policies, and then open Password Policy.
  4. Enable the Password must meet complexity requirements option and save.
Configure SSL and set up a root CA on the Active Directory server, as described in the Microsoft knowledgebase at http://technet.microsoft.com/en-us/library/cc772393%28v=ws.10%29.aspx#BKMK_AS1.
  1. Install a certificate authority.
    1. In the Administrative Tools area, open Server Manager and add a role.
    2. Select the Active Directory Certificate Services check box.
    3. Click through to the Select Role Services page, and select the Certification Authority check box.
    4. When configuring the CA, select the following options on the appropriate screens:
      • Enterprise for the setup type
      • Certification Authority Web Enrollment in the optional configuration
    5. Reboot the Active Directory server.
  2. Set up the Active Directory server to use the SSL server certificate.
    1. Create a certificate request .inf, using the fully-qualified domain name of the Active Directory as the certificate subject. For example:
      ;----------------- request.inf -----------------
      Signature="$Windows NT$
      Subject = "CN=ad.server.example.com, O=Engineering, L=Raleigh, S=North Carolina, C=US"
      KeySpec = 1
      KeyLength = 2048
      Exportable = TRUE
      MachineKeySet = TRUE
      SMIME = False
      PrivateKeyArchive = FALSE
      UserProtected = FALSE
      UseExistingKeySet = FALSE
      ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
      ProviderType = 12
      RequestType = PKCS10
      KeyUsage = 0xa0
      For more information on the .inf request file, see the Microsoft documentation, such as http://technet.microsoft.com/en-us/library/cc783835.aspx.
    2. Generate the certificate request.
      certreq -new request.inf request.req
    3. Submit the request to the Active Directory CA. For example:
      certreq -submit request.req certnew.cer


      If the command-line tool returns an error message, then use the Web browser to access the CA and submit the certificate request. If IIS is running, then the CA URL is http://servername/certsrv.
    4. Accept the certificate request. For example:
      certreq -accept certnew.cer
  3. Make sure that the server certificate is present on the Active Directory server.
    1. In the Run menu, open the MMC console.
    2. In the File menu, click Add/Remove Snap-in....
    3. Select the Certificates snap-in, and click Add to add it, and then click Next.
    4. Expand the Certificates (Local) menu on the left. Expand the Personal item and click Certificates.
    5. The new certificate should be listed with the other certificates.
  4. On the Directory Server, export the CA certificate.
    [root@server ~]# cd /etc/dirsrv/slapd-instance_name
    [root@server slapd-instance_name]# certutil -d . -L -n "CA certificate" -a > dsca.crt
  5. Copy the exported certificate from the Directory Server to the Windows machine.
  6. Import the CA certificate from Directory Server into Active Directory.
    1. Open Administrative Tools and select the Certificate Authority item.
    2. Expand Trusted Root Certification Authorities.
    3. Right-click the Certificates item and select Import.
    4. Browse to the downloaded Directory Server CA certificate, and click Next.
    5. Save the CA certificate in the Trusted Root Certification Authorities store.
  7. Reboot the domain controller.
To test that the server is running in SSL correctly, try searching Active Directory over LDAPS.

12.3.3. Step 3: Select or Create the Sync Identity

There are two users used to configure Windows Sync:
  • An Active Directory user, specified in the sync agreement.
    The user specified in the sync agreement is the entity as whom the Directory Server binds to Active Directory to send and receive updates. The Active Directory user should be a member of the Domain Admins group, or have equivalent rights, and must have rights to replicate directory changes.
    For information on adding users and setting privileges in Active Directory, see the Microsoft documentation.
  • A Directory Server user, specified in the Password Sync Service.
    The user referenced in the Password Sync Service must have read and write permissions to every entry within the synchronized subtree and absolutely must have write access to password attributes in Directory Server so that Password Sync can update password changes.


The user cited in the sync agreement (the supplier DN) exists on the Active Directory server. The user cited in the Password Sync configuration exists on Directory Server.
To create a sync user on Directory Server:
  1. Create a new entry, such as cn=sync user,cn=config, with a password. For example:
    ldapmodify -a -D "cn=directory manager" -W -p 389 -h server.example.com -x
    dn: cn=sync user,cn=config
    changetype: add
    objectClass: inetorgperson
    objectClass: person
    objectClass: top
    cn: sync user
    sn: SU
    userPassword: secret
    passwordExpirationTime: 20380119031407Z
  2. Set an ACI that grants the sync user access to compare and write user passwords.
    The ACI must be set at the top of the subtree which will be synchronized. For example:
    ldapmodify -D "cn=directory manager" -W -p 389 -h server.example.com -x
    dn: ou=people,dc=example,dc=com
    changetype: modify
    add: aci
    aci: (targetattr="userPassword")(version 3.0;acl "password sync";allow (write,compare) userdn="ldap:///cn=sync user,cn=config";)
    For security reasons, the Password Sync user should not be Directory Manager and should not be part of the synchronized subtree.

12.3.4. Step 4: Install the Password Sync Service


Password Sync must be installed on every domain controller in the Active Directory domain in order to synchronize Windows passwords.
Passwords can only be synchronized if both the Directory Server and Windows server are running in SSL, the sync agreement is configured over an SSL connection, and certificate databases are configured for Password Sync to access.
The Password Sync Service is supported on Microsoft Windows Server 2008 R2 (32-bit and 64-bit).
  1. Click the Downloads tab, and select the Red Hat Enterprise Linux channels, then filter for the Directory Server product and architecture.
  2. Open the Downloads tab for the Directory Server channel.
  3. On the Directory Server page, download the appropriate version of the WinSync Installer. This is the Password Sync MSI file (RedHat-PassSync-1.1.5-arch.msi). Save it to the Active Directory machine.


    There are two PassSync packages available, one for 32-bit Windows servers and one for 64-bit. Make sure to select the appropriate packages for your Windows platform.
  4. Double-click the Pass Sync MSI file to install it.
  5. The Password Sync Setup window appears. Hit Next to begin installing.
  6. Fill in the Directory Server host name (or IPv4 or IPv6 address), secure port number, user name (such as cn=sync user,cn=config), the certificate token (password), and the search base (e.g., ou=People,dc=example,dc=com).
    Hit Next, then Finish to install Password Sync.
  7. Reboot the Windows machine to start Password Sync.


    The Windows machine must be rebooted. Without the rebooting, PasswordHook.dll is not enabled, and password synchronization will not function.
The first attempt to synchronize passwords, which happened when the Password Sync application is installed, will always fail because of the SSL connection between the Directory Server and Active Directory sync peers. The tools to create the certificate and key databases is installed with the .msi.
Password Sync and many of its libraries are installed in C:\Program Files\Red Hat Directory Password Synchronization. All of the files installed with Password Sync are listed in Table 12.1, “Installed Password Sync Libraries”.

Table 12.1. Installed Password Sync Libraries

Directory Library Directory Library
C:\WINDOWS\system32 passhook.dll C:\WINDOWS\system32 libnspr4.dll
C:\WINDOWS\system32 nss3.dll C:\WINDOWS\system32 sqlite3.dll
C:\WINDOWS\system32 softokn3.dll C:\WINDOWS\system32 nssdbm3.dll
C:\WINDOWS\system32 nssutil3.dll   
C:\WINDOWS\system32 smime3.dll C:\WINDOWS\system32 freebl3.dll
C:\Program Files\Red Hat Directory Password Synchronization nsldap32v60.dll C:\Program Files\Red Hat Directory Password Synchronization certutil.exe
C:\Program Files\Red Hat Directory Password Synchronization nsldappr32v60.dll C:\Program Files\Red Hat Directory Password Synchronization nsldapssl32v60.dll
C:\WINDOWS\system32 ssl3.dll C:\WINDOWS\system32 libplc4.dll
C:\Program Files\Red Hat Directory Password Synchronization nssckbi.dll C:\Program Files\Red Hat Directory Password Synchronization nsldif32v60.dll
C:\Program Files\Red Hat Directory Password Synchronization passsync.log[a] C:\Program Files\Red Hat Directory Password Synchronization passsync.exe
C:\Program Files\Red Hat Directory Password Synchronization pk12util.exe C:\Program Files\Red Hat Directory Password Synchronization msvcr71.dll
C:\WINDOWS\system32 libplds4.dll   
[a] This log file is not an installed library, but it is created at installation.

12.3.5. Step 5: Configure the Password Sync Service

Next, set up certificates that Password Sync uses to access the Directory Server over SSL:


SSL is required for Password Sync to send passwords to Directory Server. The service will not send the passwords except over SSL to protect the clear text password sent from the Active Directory machine to the Directory Server machine. This means that Password Sync will not work until SSL is configured.
  1. On the Directory Server, export the CA certificate.
    [root@server ~]# cd /etc/dirsrv/slapd-instance_name
    [root@server ~]# certutil -d . -L -n "CA certificate" -a > dsca.crt
  2. Copy the exported certificate from the Directory Server to the Windows machine.
  3. Open a command prompt on the Windows machine, and open the Password Sync installation directory.
    C:\Windows\system32>cd "C:\Program Files\Red Hat Directory Password Synchronization"
  4. Create new cert8.db and key.db databases on the Windows machine.
    C:\C:\Program Files\Red Hat Directory Password Synchronization>certutil.exe -d . -N
  5. Import the CA certificate from the Directory Server into the new certificate database.
    certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i \path\to\dsca.crt
  6. Verify that the CA certificate was correctly imported.
    certutil.exe -d . -L -n "DS CA cert"
  7. Reboot the Windows machine. The Password Sync service is not available until after a system reboot.


If any Active Directory user accounts exist when Password Sync is first installed, then the passwords for those user accounts cannot be synchronized until they are changed because Password Sync cannot decrypt a password once it has been hashed in Active Directory.

12.3.6. Step 6: Configure the Directory Server Database for Synchronization

Just as with replication, there must be a changelog available to track and send directory changes and the Directory Server database being synchronized must be configured as a replica.


If the Directory Server database is already configured for replication, this step is not necessary.
Setting up a database for replication is described in Section 11.5.1, “Configuring the Read-Write Replicas on the Supplier Servers”. Setting up the Directory Server from the Console

First, enable the changelog:
  1. In the Directory Server Console, select the Configuration tab.
  2. In the left-hand navigation tree, click the Replication folder.
  3. In the main window, click the Supplier Settings tab.
  4. Check the Enable Changelog database.
  5. Set the changelog database directory. Click the Use default button to use the default or Browse... to select a custom directory.
  6. Save the changelog settings.
After setting up the changelog, then configure the database that will be synchronized as a replica. The replica role should be either a single-master or multi-master.


While it is possible to configure a sync agreement on a hub server, this only allows uni-directional synchronization, from Red Hat Directory Server to Active Directory. The Active Directory server cannot sync any changes back to the hub.
It is strongly recommended that only masters in multi-master replication be used to configure synchronization agreements.
  1. In the Directory Server Console, select the Configuration tab.
  2. In the left-hand navigation tree, click the Replication folder, then click the name of the database to synchronize.
    By default, there are two databases, NetscapeRoot for directory configuration and userRoot for directory entries. Other databases may be listed if they have been added to Directory Server.
  3. Check the Enable Replica check box, and select the radio button by the type of replica which the database is.
  4. In the Update Settings section, either select or add a supplier DN. This is the user account as which synchronization process will be run. As mentioned in Section 12.3.3, “Step 3: Select or Create the Sync Identity”, this user must be on the Active Directory server.
  5. Save the replication settings for the database.


For more information on replication settings, see Chapter 11, Managing Replication. Setting up the Directory Server for Sync from the Command Line

First, enable the changelog:
ldapmodify -a -D "cn=directory manager" -W -p 389 -h server.example.com -x

dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/changelogdb
Then, create the supplier replica entry:
ldapmodify -a -D "cn=directory manager" -W -p 389 -h server.example.com -x

dn: cn=sync replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: sync replica
nsds5replicaroot: dc=example,dc=com
nsds5replicaid: 7
nsds5replicatype: 3
nsds5flags: 1
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaBindDN: cn=sync user,cn=config
These different parameters are described in more detail in the Configuration and Command-Line Tool Reference and Section 11.7.1, “Configuring Suppliers from the Command Line”.

12.3.7. Step 7: Create the Synchronization Agreement

Create the synchronization agreement.


If secure binds are required for simple password authentication (Section 14.8.1, “Requiring Secure Binds”), then any replication operations will fail unless they occur over a secure connection. Using a secure connection (SSL/TLS and Start TLS connections or SASL authentication) is recommended, anyway. Creating the Sync Agreement from the Console

  1. In the Directory Server Console, select the Configuration tab.
  2. In the left-hand navigation tree, click Replication, then right-click on the database to sync. The default user database is userRoot, but additional databases are added as new suffixes are added to the Directory Server.
    Alternatively, highlight the database, and in the top tool bar, click Object.
  3. Select New Windows Sync Agreement from the menu.
  4. In the two fields, supply a name and description of the synchronization agreement. Hit Next.
  5. In the Windows Sync Server Info window, fill in the Active Directory information in the Windows Domain Information area.
    • The name of the Windows domain.
    • What kinds of entries to synchronize; users and groups are synchronized independently. When a type of entry is chosen, then all of the entries of that type that are found in the Windows subtree are created in the Directory Server.
    • The Windows and Directory Server subtree information; this is automatically filled in.
    • The host name, IPv4 address, or IPv6 address of the domain controller
    • The Windows server's port number
  6. Set the connection type. There are three options:
    • Use LDAP. This sets either a standard, unencrypted connection.
    • Use TLS/SSL. This uses a secure connection over the server's secure LDAPS port, such as 636. Both the Directory Server and the Windows server must be properly configured to run in TLS/SSL for this connection and must have installed each other's CA certificates in order to trust their server certificates.
    • Use Start TLS. This uses Start TLS to establish a secure connection over the server's standard port. Like regular SSL, these peer servers must be able to trust each other's certificates.
    Using either TLS/SSL or Start TLS is recommended for security reasons. TLS/SSL or Start TLS is required for synchronizing passwords because Active Directory refuses to modify passwords unless the connection is SSL-protected.
  7. Fill in the authentication information in the Bind as... and Password fields with the sync ID information. This user must exist in the Active Directory domain.
  8. Save the sync agreement.


By default, Win Sync polls the Active Directory peer every five (5) minutes to check for changes. In the sync agreement summary, this is displayed as the Update Interval. The update interval can be changed by editing the winSyncInterval attribute manually. See Section 12.10.2, “Adding and Editing the Sync Agreement in the Command Line”.
When the agreement is complete, the new sync agreement is listed under the suffix. Creating the Sync Agreement from the Command Line

It is also possible to add the sync agreement through the command line.
ldapmodify -a -D "cn=directory manager" -W -p 389 -h server.example.com -x

dn: cn=ExampleSyncAgreement,cn=sync replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsDSWindowsReplicationAgreement
cn: ExampleSyncAgreement
nsds7WindowsReplicaSubtree: cn=Users,dc=ad1
nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: ad1
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost: ad1.windows-server.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=sync user,cn=config
nsDS5ReplicaCredentials: {DES}ffGad646dT0nnsT8nJOaMA==
nsDS5ReplicaTransportInfo: TLS
winSyncInterval: 1200
All of the different parameters used in the sync agreement are listed in Table 12.6, “Sync Agreement Attributes”. These different parameters are described in more detail in the Configuration and Command-Line Tool Reference.

12.3.8. Step 8: Configure Directory Server User and Group Entries for Synchronization

Add the ntUser and ntGroup object classes to any user and group entries, respectively, which will be synchronized, along with any required attributes. Only Directory Server entries with those object classes are synchronized. Active Directory entries which are synced over to Directory Server have those object classes automatically.
Whenever the appropriate object classes are added to an entry, both for new entries and existing entries, the entry is synced over at the next incremental update.
Configuring Directory Server user entries for synchronization is described in Section 12.4.3, “Configuring User Sync for Directory Server Users”, and configuring Directory Server group entries for synchronization is described in Section 12.5.4, “Configuring Group Sync for Directory Server Groups”.

12.3.9. Step 9: Begin Synchronization

After the sync agreement is created, begin the synchronization process.
  1. Go to the Configuration tab in the Console.
  2. Open the Replication folder and expand the appropriate database.
  3. Select the sync agreement.
  4. Right-click on the agreement or open the Object menu.
  5. Select Initiate Full Re-synchronization.
If synchronization stops for any reason, begin another total update (resynchronization) by selecting this from the sync agreement menu. Beginning a total update (resynchronization) will not delete or overwrite the databases.