16.4. Steps for Configuring Windows Synchronization

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.

Note

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 TLS. Therefore, this configuration section assumes that TLS must also be configured.
Configuring synchronization over TLS is also similar to configuring replication over TLS. Both sync peers must be configured to trust each other for encrypted sessions (all password operations are performed over TLS).
All synchronization for user and group entries is passive from the Active Directory (AD) side; it is the Directory Server which sends updates on its side and polls for updates on the AD domain. For passwords, the AD server requires a separate password service; this service actively sends password changes from the AD domain to Directory Server.

16.4.1. Step 1: Configure TLS on Directory Server

The full instructions for configuring the Directory Server to run in TLS are at Section 9.4.1, “Enabling TLS in Directory Server”. Basically, the Directory Server needs to have the appropriate TLS certificates installed, be configured to run over an LDAPS port, and allow client authentication from other servers.
Two certificates must be issued and installed on both the Directory Server and the AD sync peer:
  • CA certificate, shared between the Directory Server and AD
  • Server certificates for the Directory Server and AD sync peers, which are accessible by the sync services

16.4.2. Step 2: Configure the Active Directory Domain

You can configure synchronization only with AD domain controllers. Additionally, password complexity must be enabled in AD.
To enable password complexity:
  1. Open the Group Policy Management console and create a new Group Policy Object (GPO). For details, see the Windows documentation.
  2. Right-click the GPO, and select Edit to open the Group Policy Management Editor.
  3. Navigate to Computer Configuration → Windows Settings → Security Settings → Account Policies → Password Policy, and double-click the policy named Password must meet complexity requirements.
  4. Enable the policy and click OK.
  5. Close the Group Policy Management Editor and the Group Policy Management console.
Configure TLS and set up a root CA on the AD 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 AD server.
  2. Set up the AD server to use the TLS server certificate.
    1. Create a certificate request .inf, using the fully-qualified domain name of the AD as the certificate subject. For example: 
      ;----------------- request.inf -----------------

[Version]

Signature="$Windows NT$

[NewRequest]

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

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1

;-----------------------------------------------
    2. Generate the certificate request. 
      # certreq -new request.inf request.req
    3. Submit the request to the AD CA. For example: 
      # certreq -submit request.req certnew.cer

      Note

      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 AD 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. 
    # cd /etc/dirsrv/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 AD.
    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 TLS correctly, try searching AD over LDAPS.

16.4.3. Step 3: Select or Create the Synchronization Identity

There are two users used to configure Windows Synchronization:
  • An AD user, specified in the sync agreement.
    The user specified in the sync agreement is the entity as whom the Directory Server binds to AD to send and receive updates. The AD 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 AD , 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.

Note

The user cited in the sync agreement (the supplier DN) exists on the AD 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.

16.4.4. Step 4: Install the Password Sync Service

The steps to install the Password Sync service are described in the Installing the Password Sync Service section in the Red Hat Directory Server Installation Guide.
For a list of operating systems Red Hat supports running the Password Sync service on, see Red Hat Directory Server Release Notes.

Note

The first attempt to synchronize passwords, which happens when the Password Sync application is installed, always fails because the CA certificate does not exist in Password Sync's certificate database. Adding the CA certificate is part of the configuration step of the application.

16.4.5. Step 5: Configure the Password Sync Service

Next, set up certificates that Password Sync uses to access the Directory Server over TLS:
  1. Enable TLS in Directory Server. For details, see Section 9.4.1, “Enabling TLS in Directory Server”.

    Note

    TLS is required for Password Sync to send passwords to Directory Server. The service will not send the passwords except over TLS 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 TLS is configured.
  2. On the Directory Server, export the server certificate. 
    # certutil -d /usr/lib64/dirsrv/slapd-instance -L -n "CA certificate" -a > dsca.crt
  3. Copy the exported certificate from the Directory Server to the Windows machine.
  4. Open a command prompt on the Windows machine, and open the Password Sync installation directory. 
    > cd "C:\Program Files\Red Hat Directory Password Synchronization""
  5. Create new cert8.db and key.db databases on the Windows machine. 
    > certutil.exe -d . -N
  6. Import the server 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
  7. Verify that the CA certificate was correctly imported. 
    > certutil.exe -d . -L -n "DS CA cert"
  8. Reboot the Windows machine. The Password Sync service is not available until after a system reboot.

Note

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.

16.4.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.

Note

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 15.6.1, “Configuring the Read-Write Replicas on the Supplier Servers”.

16.4.6.1. Setting up the Directory Server for Synchronization 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.
    The Configuration tab

    Figure 16.3. The Configuration tab

  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.

Important

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 AD. The AD 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.
    The Enable Replica check box

    Figure 16.4. The Enable Replica check box

  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 16.4.3, “Step 3: Select or Create the Synchronization Identity”, this user must be on the Directory Server and must have the access right for the userPassword attribute of all users that are to be synchronized.
    The Update Settings section

    Figure 16.5. The Update Settings section

  5. Save the replication settings for the database.

Note

For more information on replication settings, see Chapter 15, Managing Replication.

16.4.6.2. Setting up the Directory Server for Synchronization 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
nsslapd-changelogmaxage: 7d
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, Command, and File Reference and Section 15.2.1, “Configuring Suppliers from the Command Line”.

16.4.7. Step 7: Create the Synchronization Agreement

Create the synchronization agreement.

Note

If secure binds are required for simple password authentication (Section 19.11.1, “Requiring Secure Binds”), then any replication operations will fail unless they occur over a secure connection. Using a secure connection (LDAPS or StartTLS) is recommended, anyway.

16.4.7.1. Creating the Synchronization 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 Synchronization 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 AD 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 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 TLS, these peer servers must be able to trust each other's certificates.
    Using either TLS or Start TLS is recommended for security reasons. TLS or Start TLS is required for synchronizing passwords because AD refuses to modify passwords unless the connection is TLS-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 AD.
  8. Save the sync agreement.

Note

By default, Windows Synchronization polls the AD 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 16.12.2, “Adding and Editing the Synchronization Agreement in the Command Line”.
When the agreement is complete, the new sync agreement is listed under the suffix.

16.4.7.2. Creating the Synchronization 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=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsDSWindowsReplicationAgreement
cn: replication_agreement_name
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
For descriptions of the parameters used in the example and other attributes you can set, see the Red Hat Directory Server Configuration, Command, and File Reference.

16.4.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. AD 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 16.5.3, “Configuring User Synchronization for Directory Server Users”, and configuring Directory Server group entries for synchronization is described in Section 16.6.4, “Configuring Group Synchronization for Directory Server Groups”.

16.4.9. Step 9: Begin Synchronization

After the synchronization agreement has been created, start the synchronization.

Starting the Synchronization Using the Command Line

To start synchronization using the command line: 
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start
When the initialization is complete, Directory Server automatically removes the nsds5BeginReplicaRefresh attribute from the replication agreement entry.

Starting the Synchronization Using the Console

  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.