Chapter 18
Windows Sync
The Windows Sync feature allows synchronization of adds, deletes and changes in groups, user entries, and their passwords between Red Hat Directory Server and both Microsoft Active Directory and Microsoft Windows NT 4.0 Server. It provides an efficient and effective way to maintain consistent directory information across the enterprise.
This chapter covers how to configure and use Windows Sync in the following sections:
- About Windows Sync (page 545)
- Installing Sync Services (page 551)
- Uninstalling the Sync Services (page 558)
- Using Windows Sync (page 562)
- Troubleshooting (page 570)
About Windows Sync
The complete Windows Sync feature is implemented in three parts:
- Directory Server Windows Sync code. The server itself contains code that performs a large proportion of the sync functionality. This code is closely integrated with the server's own native multi-master replication plug-in. The same changelog that is used for multi-master replication is also used to replay outbound changes that pertain to synchronized entries. The corresponding changes are made in the Windows Server via LDAP. The server also performs LDAP search operations against its Windows Server peer in order to synchronize inbound changes made to Windows user entries.
- Password Sync Service. This is an application that must be installed on the Active Directory machine (or primary domain controller in the case of NT4). Its purpose is to capture password changes for Windows users and relay those changes back to the Directory Server via LDAP with SSL, for security.
- NT4 LDAP Service. This is a special LDAP server application that must be installed on the primary domain controller for NT4 sync. It is only used for NT4 and is not needed for Active Directory deployments. The purpose of the NT4 LDAP Service is to provide a similar view of users and groups as is available via LDAP from Active Directory. This allows almost all of the Directory Server Windows Sync code to be the same for both Active Directory and NT4.
Figure 18-1 and Figure 18-2 show the relationship between Red Hat Directory Server and Active Directory and Windows NT4 Server primary domain controller (PDC), respectively.
Figure 18-1 Active Directory - Directory Server Synchronization Process
|
Figure 18-2 Windows NT4 Server - Directory Server Synchronization Process
|
Windows Sync is compatible with Directory Server's multi-master replication facilities. Figure 18-3 shows this arrangement:
Figure 18-3 Multi-Master Directory Server - Windows Domain Synchronization
|
How Windows Sync Works
Synchronization is configured and controlled by means of one or more synchronization agreements. These are similar in purpose to replication agreements and contain a similar set of information, including the host name and port number for the Windows Server.
The Directory Server connects to its peer Windows Server via LDAP and SSL to both send and retrieve updates.
The unit of synchronization is a subtree. A single Windows subtree can be synchronized to a single Directory Server subtree and vice versa. The Windows and Directory Server subtree DNs are specified in the sync agreement. All entries within the respective subtrees are candidates for synchronization, including entries that are not immediate children of the subtree root. It's important to note however that any descendent container entries will need to be created separately by the administrator. Windows Sync never creates container entries itself.
Windows Sync provides some control over which entries are synchronized. This is intended to allow administrators to determine that only a subset of all the entries should be subject to synchronization and to give sufficient flexibility to support different deployment scenarios. Therefore, certain rules are applied to determine first if a particular entry should be synchronized and second if a given new entry should be created in the peer server.
Specifically, only entries with user or group object classes are synchronized from Windows to Directory Server. In addition, two flags with agreement scope allow the creation of new entries for newly found entries in the Windows Server to be enabled or disabled. One flag controls new entry creation for users while the other controls new entry creation for groups. Similarly, only entries with the necessary object classes and attribute values in the Directory Server will be synchronized.
The Directory Server peer maintains a replication changelog, a database that records the modifications that have occurred. The changelog is used by Windows Sync to generate outbound changes made to the Windows Server. Therefore, a changelog and the associated replica object must be configured in a Directory Server before it may run Windows Sync.
During normal operation, all the updates made to entries in the Directory Server that need to be sent to the Windows Server are generated via the changelog. However, when the server is initially configured or after major changes to its content, it is necessary to initiate a re-synchronization process. For re-synchronization, the entire contents of synchronized subtree in the Directory Server is examined and, if necessary, sent to the Windows Server. This is done without using the changelog.
Inbound changes, that is changes to entries in the Windows Server, are found by using Active Directory's `Dirsync' search feature. Because there is no changelog to use, it is necessary to issue the Dirsync search periodically. The default interval is five minutes. The administrator may also trigger an immediate Dirsync search by right-clicking on the sync agreement and selecting "Send and Receive Updates Now". Use of the Dirsync search ensures that only those entries that have changed since the previous search are retrieved. However, in the case of a server or where there have been major changes to its content, a Dirsync search that returns all entries (and not just recently changed entries) can be performed. This full Dirsync is done whenever the administrator initiates the `re-synchronization' process mentioned above. In some situations, it may be unappealing to wait up to five minutes for the next Dirsync search to occur. During this time, recent changes made on the Windows Server will not be brought over to the Directory Server. In this case, the administrator can manually initiate an immediate Dirsync search.
In addition to the entry synchronization mechanisms discussed above, the Password Sync Service is needed to catch password changes made on the Windows server. Without the Password Sync Service, it would be impossible to have inbound password sync because passwords are hashed once stored in Active Directory, and the hashing function is incompatible with that used by Directory Server. Also, it is not possible to retrieve password values from a Windows Server externally. Outbound passwords are synchronized along with other entry attributes using a special Directory Server facility for retaining the plaintext password values in the changelog.
Installing Sync Services
There are two services that can be installed on your Windows machine to synchronize more aspects of your Directory Server with a Windows Server.
Password Sync must be installed on the Windows Server. It synchronizes password changes made on the Windows Server with the corresponding entries' passwords on the Directory Server.
The NT4 LDAP Service is installed only on Windows NT4 Server to allow synchronization operations over LDAP between the Directory Server and Windows NT4 Server.
Installing and Configuring the Password Sync Service
- Copy the PassSync.msi file that contains the Password Sync utility to the Windows machine.
- Double-click on the PassSync.msi file to install it.
- Fill in the Directory Server hostname, secure port number, user name (such as cn=sync manager,cn=config), the certificate token (password), and the search base (e.g., ou=People,dc=example,dc=com).
This user must have write access to the userpassword attribute for all users in the synched Directory Server subtree. |
You must reboot the Windows machine. Without rebooting, the password hook DLL will not be enabled, and password synchronization will not function. |
Password Sync is installed in C:\Program Files\Red Hat Directory Password Synchronization, and the passsync.exe is the only file in the installation directory.
The following .dlls are installed in C:\winnt\system32 and utilized by Password Sync:
The Password Sync Service runs as a Windows service, which means that it can be started, stopped, and controlled by the net start|stop command, the Services Control Panel applet, and other Windows Services management mechanisms.
Changed passwords are captured even if the Password Sync Service is not running. If the Password Sync Service is restarted, the password changes are sent to Directory Server immediately.
Reconfiguring the Password Sync Service
To reconfigure Password Sync, open the Windows Services panel, highlight Password Sync, and select Modify. This will lead you back through the configuration screens.
Setting Up SSL for the Password Sync Service
Next, set up certificates that Password Sync Service will use SSL to access the Directory Server:
- Download certutil.exe if you do not already have it installed on your machine. It is available from ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/. See "Managing SSL and SASL," on page 425, for more information on SSL.
- Create a new cert8.db and key.db using certutil.exe on the Password Sync machine.
certutil.exe -d . -N
pk12util -d . -P slapd-serverID -o servercert.pfx -n Server-Cert
- Copy the exported certificate from the Directory Server to the Windows machine.
- Import the server certificate from the Directory Server into the new certificate database using pk12util.exe.
pk12util.exe -d "C:\Program Files\Red Hat Directory Password
Synchronization" -i servercert.pfx
certutil.exe -d "C:\Program Files\Red Hat Directory Password
Synchronization" -M -n Server-Cert -t "P,P,P"
Installing and Configuring the NT4 LDAP Service
For Windows NT4 servers, Windows Sync must be configured to a PDC, and all sync services must be installed on a PDC. Synchronization will not function properly on a non-PDC machine.
- Open C:\Program Files\Red Hat Directory Synchronization\bin, and double-click on installuseresync.bat. This will set up the LDAP Service as a Windows service.
- Open C:\Program Files\Red Hat Directory Synchronization\conf. Modify the usersync.conf file to reflect the Directory Server port, SSL port, and hostname.
After the service is installed and started the first time the password can only be changed via an LDAP modify operation, not the configuration file. |
server.net.ldaps.enable=true
javax.net.ssl.keyStore=c:\\keystore
javax.net.ssl.keyStorePassword=password
What is your first and last name?
[Unknown]: directory.example.com
What is the name of your organizational unit?
[Unknown]:
What is the name of your organization?
[Unknown]: example.com
What is the name of your City or Locality?
[Unknown]: Boston
What is the name of your State or Province?
[Unknown]: MA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=directory.example.com, OU=Unknown, O=example.com, L=Boston, ST=MA, C=US correct?
[no]: yes
The NT4 LDAP Service runs as a Windows Service, which means that it can be started, stopped, and controlled by the net start|stop command, the Services Control Panel applet, and other Windows Services management mechanisms.
Entry changes are not "stored" by the NT4 LDAP Service when the service is stopped, but the current state of the entries is synchronized automatically when the LDAP Service is restarted.
Uninstalling the Sync Services
To uninstall the Password Sync Service:
- Open the Add/Remove Programs utility.
- Select click remove to uninstall the Password Sync Service.
- If you configured SSL for the Password Sync, then the cert8.db and key3.db databases that were created were not removed when you uninstall Password Sync. Delete these files by hand.
To uninstall the NT4 LDAP Service:
- Open C:\Program Files\Red Hat Directory Synchronization\bin, and double-click on uninstalluseresync.bat.
- Open the Add/Remove Programs utility.
- Select click remove to uninstall the User Sync Service.
Configuring Windows Sync
To configure the Directory Server to run in SSL. You can use the certutil utility to create self-signed certificates or obtain and install certificates to enable SSL; for more information, see Chapter 11, "Managing SSL and SASL."
You should have the following things created and installed on both your Directory Server and your Windows sync peers:
- CA certificate, shared between the Directory Server and Windows server
- Directory Server certificate that is accessible by your sync services
To configure SSL on Active Directory, see the appropriate user documentation. It is not necessary to configure SSL for NT4 Server; SSL is enabled when configuring the NT4 LDAP Service.
Password Sync can be installed on any Windows machine to synchronize Windows passwords. Passwords can only be synchronized if both your Directory Server and Windows Server are running in SSL, the sync agreement is configured over an SSL connection, and you have configured certificate databases for Password Sync to access. See "Installing and Configuring the Password Sync Service," on page 552, for information on installing and configuring Password Sync.
Install the LDAP Service on the Windows NT4 Server, set it up as a Windows service, and modify the configuration file for your Directory Server information. See "Installing and Configuring the NT4 LDAP Service," on page 555, for more information.
The Windows user specified in the sync agreement, which the Directory Server will use to bind for sync operations, should be a member of the Domain Admins group (or have equivalent privileges). A member of this group will have full privileges within the domain, but will not necessarily have privileges within other domains in the Active Directory forest, enhancing security. This limits the extent of the Windows directory that can be affected by the sync ID to only the synchronized subtree.
The user specified in the Password Sync and NT4 LDAP Services should be a a special user that has write access to entries and passwords but, for security reasons, should not be Directory Manager. Also, this user should not be under the synchronized subtree. For information on creating a special sync ID, see "Creating the Supplier Bind DN Entry," on page 318.
To create a synchronization agreement:
- In the Directory Server Console, select the Configuration tab.
- In the left-hand navigation tree, right-click on the suffix to sync, and select New Synchronization Agreement. You can also highlight the suffix, and select Menu>Object>New Synchronization Agreement.
- In the two fields, supply a name and description of your synchronization agreement. Hit "Next."
- The second screen reads "Windows Sync Server Info." By default, your Directory Server hostname and port are visible at the top, under Supplier. At the very bottom of the screen, the name of the synched suffix, such as dc=example,dc=com, is displayed.
- In the middle of the screen are fields for your Windows domain information. Fill in the domain name and the domain controller.
- Select the checkbox(es) for the Windows entries you are going to synchronize.
- Sync New Windows Users. When enabled, all user entries found in Windows that are subject to the agreement will automatically be created in the Directory Server.
- Sync New Windows Groups. When enabled, all group entries found in Windows that are subject to the agreement will automatically be created in the Directory Server.
- The Windows and Directory Server subtree information is automatically filled in; use the defaults to sync only users or change these as appropriate to sync groups or groups and users.
- Check the "Using encrypted SSL connection" checkbox. The use of SSL is recommended for security reasons. You must use SSL if you are going to synchronize passwords because Active Directory will refuse to modify passwords unless the connection is SSL protected.
- Fill in the authentication information in the "Bind as..." and "Password" fields with the sync manager information.
- The last screen is a summary of your synchronization agreement. If you decide to change anything at this point, you can use the back buttons to get to the appropriate screen. If you are satisfied with your agreement, click "Done."
When you have finished, an icon representing the synchronization agreement is displayed under the suffix. This icon indicates that your synchronization agreement is set up.
After the sync agreement is created, you need to begin the synchronizaiton process. Select the sync agreement, right-click or open the Object menu, and select "Initiate re-synchronization." This will begin the synchronization process.
If synchronization stops for any reason, you can initiate re-synchronization by selecting this from the sync agreement menu.
Using Windows Sync
After your Windows Sync service has been installed and configured, you can begin using it to synchronize your user and group entries on your Directory Server and Windows NT4 Server or Active Directory servers.
This section deals with how to move existing entries between servers, how to create and delete entries, and checking the status of synchronization.
- Synchronized Entries
- Groups
- Manually Initiating Synchronization
- Checking Synchronization Status
- Modifying the Synchronization Agreement
- The Connection tab will let you change the bind DN and bind credentials for the sync manager. It will also show whether this is over an SSL connection. Finally, it shows whether new user and group entries will be created in the Directory Server.
- NT4-Specific Limitiations
Synchronized Entries
Special schema is applied to entries in the Directory Server that are subject to synchronization. This schema is very similar, but not identical, to that used by the old Netscape Directory Server 4.x NT Sync feature. Full schema details are available in Red Hat Directory Server Schema Reference.
First, there are provisions for identifying the corresponding entry for a given Windows entry. This is done with the ntUniqueId attribute, which contains the value of the objectGUID attribute for the corresponding entry. This attribute is totally under the control of the sync code and should not be modified manually.
Next, the ntDomainUser attribute holds the value of the samAccountName attribute from the corresponding Windows entry. (In the case of NT4, it matches the user name).
Finally, ntUserCreateNewAccount and ntUserDeleteAccount attributes control the life cycle of the corresponding Windows entry. Only if ntUserCreateNewAccount has the value true will a new entry be created in the Windows Server. Similarly, only if ntUserDeleteAccount has the value true will the corresponding entry be deleted when the Directory Server entry is deleted. These attributes allow the adminstrator to exercise fine-grain control over the life cycle of synchronized entries.
Table 18-1 shows the attributes that are mapped between the Directory Server and Windows Servers, and Table 18-2 shows the attributes that are the same between the Directory Server and Windows Servers.
When you create a Directory Server user from the Console (see "Creating Directory Entries," on page 49), there is an NT User tab in the New User dialog. Fill in this information to supply Windows attributes automatically.
You can add additional ntUser attributes either by using the Advanced button in the Console or by using ldapmodify; see "Modifying Entries Using ldapmodify," on page 62.
Groups
Similar to user entires, group entries are synchronized if they have the ntGroup and mailgroup object classes. There are also two attributes that control creation and deletion of group entries in the Windows Server: ntGroupCreateNewAccount and ntGroupDeleteAccount.
Group entries that are within the scope of the sync agreement will be synchronized in much the same way as user entries. In addition, the membership of groups is synchronized with the constraint that only those members that are also within the scope of the agreement are propagated. The result is that a group may contain members that are both within and without the scope of the agreement, but only the subset of members that are themselves within agreement scope are synchronized. The remaining members are left unchanged on both sides.
Table 18-3 shows the attributes that are mapped between the Directory Server and Windows Servers, and Table 18-4 shows the attributes that are the same between the Directory Server and Windows Servers.
| seeAlso |
l |
| description |
ou |
Manually Initiating Synchronization
While synchronization will always occur automatically every five minutes, you can manually perform synchronization or an update if you have an immediate need for synchronization to occur.
To perform an update manually, go to the Configuration tab in the Console, right-click on the synchronization agreement icon, and select "Send and Receive Updates Now" from the drop down menu.
If you want to re-synchronize every entry in the Directory Server and Windows server, go to the Configuration tab in the Console, right-click on the synchronization agreement icon, and select "Initiate re-synchronization" from the drop down menu. This will not delete or overwrite your data on the sync peer; it will send and receive all updates and add any new or modified Directory Server entries (such as a pre-existing Directory Server user that had the ntUser object class added to it).
The Need for Re-Synchronization
As discussed above, entries are synchronized provided they are subject to the sync agreement. There are some cases where an entry can be initially not subject to the agreement (for example, if it lacks the ntUser object class) but subsequently becomes subject to the agreement (if the ntUser object class is added, for example).
In cases like these, the Directory Server is not able to identify the entry's change in status with normal update processing, and it will fail to create the corresponding entry in the Windows Server (in the case that that entry does not already exist).
It is necessary to initiate a re-synchronization in order for such entries to be recognized and synchronized. Re-synchronization need only be performed once to identify all such entries.
Checking Synchronization Status
You can check synchronization status in the Status tab of the Console. Highlight the synchronization agreement you want to monitor, and the relevant information should appear in the right-hand pane. From the Status area, you can determine whether the last incremental and total updates were successful and when they occurred. Total update signifies the time when the last re-initializiation operation completed.
Modifying the Synchronization Agreement
It is possible to modify parts of the synchronization agreement after it has been created.
In the Configuration>Replication tab of the Directory Server Console, select the sync agreement icon from beneath the database. There are two tabs: Summary, and Connection.
- The Summary tab allows you to change the description of the agreement. This tab also shows the sync peer host and port information and synchronized subtrees.
- The Connection tab will let you change the bind DN and bind credentials for the sync manager. It will also show whether this is over an SSL connection. Finally, it shows whether new user and group entries will be created in the Directory Server.
Active Directory Schema Compatibility
Although Active Directory supports the same basic X.500 object classes as Directory Server, there are a few subtle incompatibilities of which administrators should be aware:
- Both Active Directory and Directory Server can enforce password policy that can enforce certain requirements upon passwords: minimum length, maximum age and so forth. Windows Sync does not synchronize the policies, nor does it ensure that the policies are consistent. This is something that the administrators of both systems must ensure is done. If password policy is not consistent, then password changes made on one system may fail when replayed on the other system.
- Nested groups (where a group contains another group as a member) are supported and will be synchronized. However, Active Directory imposes certain constraints for the composition of nested groups. For example, a domain local group may not be a member of a global group. Directory Server has no concept of local and global groups, and therefore, it is possible to create entries on the Directory Server side that will violate Active Directory's constraints when synchronized. Again, it is the responsibility of the administrators to ensure that this does not happen.
- Active Directory uses the attribute streetAddress for a user or group's physical or postal address. Directory Server uses the RFC2798 inetOrgPerson attribute street for this purpose. However, as defined in RFC2256, streetAddress is an alias for street. To compound the confusion, Active Directory also has the street attribute, but it is not an alias for streetAddress but a separate attribute that can hold an independent value. Windows Sync maps streetAddress in Windows to street in Directory Server, and therefore, precludes the use of the street attribute in Active Directory.
NT4-Specific Limitiations
The NT4 LDAP Service attempts to reflect the NT4 NTLM user database (as accessed via the Net API) in LDAP. In general, this works well, but there are some fundamental incompatibilities between LDAP schema and the underlying data store. These incompatibilities are listed below:
- The schema supported by the NTLM database is severely limited compared to Active Directory. There is little support for information beyond username and full name. The missing attributes therefore cannot be synchronized.
- There is no support for the incremental Dirsync found in Active Directory. What this means is that every time the Directory Server performs a synchronization pass, it will pull the complete set of all entries from NT4. This has implications for the consistency of data because if a modification is made to an entry on the Directory Server side and the same entry is read from NT4 in a synchronization operation before the change has been propagated outbound, then the change will be undone.
- There is no support for tombstone entries in NT4. What this means is that entries deleted from NT4 will not be automatically deleted from the Directory Server side. It will be necessary to delete those entries manually.
- NT4 has no surname attribute. However, the inetOrgPerson object class requires surname have a value. In order to allow the use of the standard person schema with NT4, when new user entries are created in the sync process, they are given a surname attribute value that is equal to the NT user name. This can be changed later by the admistrator to the correct value. This issue only applies to new entries created in Directory Server by a sync operation. If the associated Directory Server entry for an NT4 user account already exists, its surname attribute is left unchanged.
Troubleshooting
If synchronization does not seem to be functioning properly, see the Windows event log and/or Directory Server error log for information on any potential problems.
You can also enable replication logging for more detailed information on synchronization to be recorded in the error logs:
- In the Console, click the Configuration tab, select Logs from the navigation menu on the right, and open the Error Log.
- Scroll down to error log level, and select Replication from the menu. Hit save.
This will produce verbose logging from the sync code that can help in diagnosing problems.
There is a problem with the location of your keystore, the keystore filename, the path is not escaped correctly, or you have configured wrong keystore password in the usersync.conf file.
The port you are attempting to use is already in use.
It is mandatory to set a password for the admin account for the NT4 LDAP service. There is no default password.
Make sure that the directory suffixes, Windows domain and domain host, and the administrator DN and password are correct. Also verify that the port numbers used for LDAPS is correct. If all of this is correct, make sure that Active Directory or teh Windows machine are running.
One of the sync peer servers has not been properly configured for SSL communication. Examine the Directory Server access log file to see if the connection attempt was received by the Directory Server. You may also find helpful messages in the Directory Server's error log file.
To narrow down the source of the misconfiguration, try to establish an LDAPS connection to the Directory Server. If this connection attempt fails, check all values (port number, hostname, search base, and so forth) to see if any of these are the problem. If all else fails, reconfigure the Directory Server with a new certificate.
If the LDAPS connection is successful, it is likely that the misconfiguration is on the Windows server. Check that you have properly configured the NT4 LDAP Service and Password Sync for SSL and that the NT4 LDAP Service is running. Examine the Windows event log file for error messages.