9.3. Synchronizing Users

Users are not automatically synced between Directory Server and Active Directory. Synchronization both directions has to be configured:
  • Users in the Active Directory domain are synced if it is configured in the sync agreement by selecting the Sync New Windows Users option. All of the Windows users are copied to the Directory Server when synchronization is initiated and then new users are synced over when they are created.
  • A Directory Server user account is synchronized to Active Directory through specific attributes that are present on the Directory Server entry. Any Directory Server entry must have the ntUser object class and the ntUserCreateNewAccount attribute; the ntUserCreateNewAccount attribute (even on an existing entry) signals Directory Server Win Syn to write the entry over to the Active Directory server.
    New or modified user entries with the ntUser object class added are created and synced over to the Windows machine at the next regular update, which is a standard poll of entry.

NOTE

A user is not active on the Active Directory domain until it has a password. When an existing user is modified to have the required Windows attributes, that user entry will be synced over to the Active Directory domain, but will not be able to log in until the password is changed on the Directory Server side or an administrator sets the password on Active Directory. This is because passwords stored in the Directory Server are encrypted, and Password Sync cannot sync already encrypted passwords.
To make the user active on the Active Directory domain, reset the user's password.
All synchronized entries in the Directory Server, whether they originated in the Directory Server or in Active Directory, have special synchronization attributes:
  • ntUserDomainId. This corresponds to the sAMAccountName attribute for Active Directory entries.
  • ntUniqueId. This contains the value of the objectGUID attribute for the corresponding Windows entry. This attribute is set by the synchronization process and should not be set or modified manually.
  • ntUserDeleteAccount. This attribute is set automatically when a Windows entry is synced over but must be set manually for Directory Server entries. If ntUserDeleteAccount has the value true, the corresponding Windows entry be deleted when the Directory Server entry is deleted. Otherwise, the entry remains in Active Directory, but is removed from the Directory Server database if it is deleted in the Directory Server.
Setting ntUserCreateNewAccount and ntUserDeleteAccount on Directory Server entries allows the Directory Manager precise control over which users within the synchronized subtree are synced on Active Directory.

9.3.1. User Attributes Synchronized between Directory Server and Active Directory

Only a subset of Directory Server and Active Directory attributes are synchronized. These attributes are hard-coded and are defined regardless of which way the entry is being synchronized. Any other attributes present in the entry, either in Directory Server or in Active Directory, remain unaffected by synchronization.
Some attributes used in Directory Server and Active Directory are identical. These are usually attributes defined in an LDAP standard, which are common among all LDAP services. These attributes are synchronized to one another exactly. Table 9.3, “User Schema That Are the Same in Directory Server and Windows Servers” shows attributes that are the same between the Directory Server and Windows servers.
Some attributes define the same information, but the names of the attributes or their schema definitions are different. These attributes are mapped between Active Directory and Directory Server, so that attribute A in one server is treated as attribute B in the other. For synchronization, many of these attributes relate to Windows-specific information. Table 9.2, “User Schema Mapped between Directory Server and Active Directory” shows the attributes that are mapped between the Directory Server and Windows servers.
For more information on the differences in ways that Directory Server and Active Directory handle some schema elements, see Section 9.3.2, “User Schema Differences between Red Hat Directory Server and Active Directory”.

Table 9.2. User Schema Mapped between Directory Server and Active Directory

Directory Server Active Directory
cn[a] name
ntUserDomainId sAMAccountName
ntUserHomeDir homeDirectory
ntUserScriptPath scriptPath
ntUserLastLogon lastLogon
ntUserLastLogoff lastLogoff
ntUserAcctExpires accountExpires
ntUserCodePage codePage
ntUserLogonHours logonHours
ntUserMaxStorage maxStorage
ntUserProfile profilePath
ntUserParms userParameters
ntUserWorkstations userWorkstations
[a] The cn is treated differently than other synced attributes. It is mapped directly (cn to cn) when syncing from Directory Server to Active Directory. When syncing from Active Directory to Directory Server, however, cn is mapped from the name attribute on Windows to the cn attribute in Directory Server.

Table 9.3. User Schema That Are the Same in Directory Server and Windows Servers

cn[a] physicalDeliveryOfficeName
description postOfficeBox
destinationIndicator postalAddress
facsimileTelephoneNumber postalCode
givenname registeredAddress
homePhone sn
homePostalAddress st
initials street
l telephoneNumber
mail teletexTerminalIdentifier
mobile telexNumber
o title
ou usercertificate
pager x121Address
[a] The cn is treated differently than other synced attributes. It is mapped directly (cn to cn) when syncing from Directory Server to Active Directory. When syncing from Active Directory to Directory Server, however, cn is mapped from the name attribute on Windows to the cn attribute in Directory Server.

9.3.2. User Schema Differences between Red Hat Directory Server and Active Directory

Although Active Directory supports the same basic X.500 object classes as Directory Server, there are a few incompatibilities of which administrators should be aware.

9.3.2.1. Values for cn Attributes

In Directory Server, the cn attribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Directory Server cn attribute is synchronized, then, only one value is sent to the Active Directory peer.
What this means for synchronization is that,potentially, if a cn value is added to an Active Directory entry and that value is not one of the values for cn in Directory Server, then all of the Directory Server cn values are overwritten with the single Active Directory value.
One other important difference is that Active Directory uses the cn attribute attribute as its naming attribute, where Directory Server uses uid. This means that there is the potential to rename the entry entirely (and accidentally) if the cn attribute is edited in the Directory Server. If that cn change is written over to the Active Directory entry, then the entry is renamed, and the new named entry is written back over to Directory Server.

9.3.2.2. Password Policies

Both Active Directory and Directory Server can enforce password policies such as password minimum length or maximum age. Windows Sync makes no attempt to ensure that the policies are consistent, enforced, or synchronized. If password policy is not consistent in both Directory Server and Active Directory, then password changes made on one system may fail when synced to the other system. The default password syntax setting on Directory Server mimics the default password complexity rules that Active Directory enforces.

9.3.2.3. Values for street and streetAddress

Active Directory uses the attribute streetAddress for a user or group's postal address; this is the way that Directory Server uses the street attribute. There are two important differences in the way that Active Directory and Directory Server use the streetAddress and street attributes, respectively:
  • In Directory Server, streetAddress is an alias for street. Active Directory also has the street attribute, but it is a separate attribute that can hold an independent value, not an alias for streetAddress.
  • Active Directory defines both streetAddress and street as single-valued attributes, while Directory Server defines street as a multi-valued attribute, as specified in RFC 4519.
Because of the different ways that Directory Server and Active Directory handle streetAddress and street attributes, there are two rules to follow when setting address attributes in Active Directory and Directory Server:
  • Windows Sync maps streetAddress in the Windows entry to street in Directory Server. To avoid conflicts, the street attribute should not be used in Active Directory.
  • Only one Directory Server street attribute value is synced to Active Directory. If the streetAddress attribute is changed in Active Directory and the new value does not already exist in Directory Server, then all street attribute values in Directory Server are replaced with the new, single Active Directory value.

9.3.2.4. Constraints on the initials Attribute

For the initials attribute, Active Directory imposes a maximum length constraint of six characters, but Directory Server does not have a length limit. If an initials attribute longer than six characters is added to Directory Server, the value is trimmed when it is synchronized with the Active Directory entry.

9.3.3. Configuring User Sync for Directory Server Users

For Directory Server users to be synchronized over to Active Directory, the user entries must have the appropriate sync attributes set.

9.3.3.1. Configuring User Sync in the Console

  1. In the Directory Server Console, select the Directory tab.
  2. For an existing entry, right-click the entry, and click Properties to open the property editor for the entry.
    For a new entry, right-click the main entry in the left window to add the new entry, select User, and then fill in the required entry attributes.
  3. On the left side of the Property Editor, click the NT User link.
  4. In the NT User tab, check the Enable NT Attributes checkbox.
  5. To enable synchronization, two fields are required:
    • Setting a NT User ID
    • Selecting the Create New NT Account checkbox
  6. Selecting the Delete NT Account checkbox means that the corresponding Windows user is deleted if the Directory Server entry is deleted.
  7. Set the other Windows attributes. These attributes are mapped to relevant Windows attributes.
    Additional ntUser attributes can be created either by using the Advanced button; see Section 3.2.4.2, “Modifying Entries Using ldapmodify”.

TIP

Reset the user's password.
A user is not active on the Active Directory domain until it has a password. When an existing user is modified to have the required Windows attributes, that user entry will be synced over to the Active Directory domain, but will not be able to log in until the password is changed on the Directory Server side or an administrator sets the password on Active Directory. Password Sync cannot sync encrypted passwords.
So, to make the user active on the Active Directory domain, reset the user's password.

9.3.3.2. Configuring User Sync in the Command Line

To enable synchronization through the command line, add the required sync attributes to an entry or create an entry with those attributes.
Three schema elements are required for synchronization:
  • The ntUser object class
  • The ntUserDomainId attribute, to give the Windows ID
  • The ntUserCreateNewAccount attribute, to signal to the synchronization plug-in to sync the Directory Server entry over to Active Directory
For example:
/usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com

dn: uid=scarter, ou=People, dc=example,dc=com
changetype: modify
add: objectClass
objectClass:ntUser

add: ntUserDomainId
ntUserDomainId: Sam Carter

add: ntUserCreateNewAccount
ntUserCreateNewAccount: true

add: ntUserDeleteAccount
ntUserDeleteAccount: true
Many additional Windows and user attributes can be added to the entry. All of the schema which is synchronized is listed in Section 9.3.1, “User Attributes Synchronized between Directory Server and Active Directory”. Windows-specific attributes, belonging to the ntUser object class, are described in more detail in the Schema Reference.

TIP

Reset the user's password.
A user is not active on the Active Directory domain until it has a password. When an existing user is modified to have the required Windows attributes, that user entry will be synced over to the Active Directory domain, but will not be able to log in until the password is changed on the Directory Server side or an administrator sets the password on Active Directory. Password Sync cannot sync encrypted passwords.
So, to make the user active on the Active Directory domain, reset the user's password.

9.3.4. Configuring User Sync for Active Directory Users

Synchronization for Windows users (users which originate in the Active Directory domain) is configured in the sync agreement.

9.3.4.1. Configuring User Sync in the Console

  1. Open the Configuration tab and expand the Replication folder.
  2. Open the appropriate database, and select the sync agreement.
  3. Open the Connection tab.
  4. Check the New Windows User Sync checkbox to enable users sync. To disable sync, uncheck the box.
For new sync agreements, select the corresponding users sync checkbox in the sync agreement creation wizard.

9.3.4.2. Configuring User Sync in the Command Line

The attribute to set Active Directory user sync is nsds7NewWinUserSyncEnabled and is set on the sync agreement. To enable user sync, add this attribute to the sync agreement or create a sync agreement with this attribute set to on:
/usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com

dn: cn=ExampleSyncAgreement, cn=userRoot, cn="dc=example, dc=com", cn=mapping tree, cn=config
changetype: modify
replace: nsds7NewWinUserSyncEnabled
nsds7NewWinUserSyncEnabled: on
To disable user sync, set nsds7NewWinUserSyncEnabled: off.