16.5. Synchronizing Users
Users are not automatically synchronized between Directory Server and Active Directory. Synchronization both directions has to be configured:
- Users in the Active Directory domain are synchronized 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 synchronized 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
ntUserobject class and thentUserCreateNewAccountattribute; thentUserCreateNewAccountattribute (even on an existing entry) signals the Directory Server Windows Synchronization plug-in to write the entry over to the Active Directory server.New or modified user entries with thentUserobject class added are created and synchronized 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 synchronized 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
sAMAccountNameattribute for Active Directory entries. - ntUniqueId. This contains the value of the
objectGUIDattribute 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 synchronized over but must be set manually for Directory Server entries. If
ntUserDeleteAccounthas the valuetrue, 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 synchronized on Active Directory.
16.5.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 16.2, “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 16.1, “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 16.5.2, “User Schema Differences between Red Hat 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 synchronized 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.
| |
| cn[a] | physicalDeliveryOfficeName |
| description | postOfficeBox |
| destinationIndicator | postalAddress |
| facsimileTelephoneNumber | postalCode |
| givenname | registeredAddress |
| homePhone | sn |
| homePostalAddress | st |
| initials | street |
| l | telephoneNumber |
| teletexTerminalIdentifier | |
| mobile | telexNumber |
| o | title |
| ou | usercertificate |
| pager | x121Address |
[a]
The cn is treated differently than other synchronized 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.
| |
16.5.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.
16.5.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.
16.5.2.2. Password Policies
Both Active Directory and Directory Server can enforce password policies such as password minimum length or maximum age. Windows Synchronization 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 synchronized to the other system. The default password syntax setting on Directory Server mimics the default password complexity rules that Active Directory enforces.
16.5.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,
streetAddressis an alias forstreet. Active Directory also has thestreetattribute, but it is a separate attribute that can hold an independent value, not an alias forstreetAddress. - Active Directory defines both
streetAddressandstreetas single-valued attributes, while Directory Server definesstreetas 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 Synchronization maps
streetAddressin the Windows entry tostreetin Directory Server. To avoid conflicts, thestreetattribute should not be used in Active Directory. - Only one Directory Server
streetattribute value is synchronized to Active Directory. If thestreetAddressattribute is changed in Active Directory and the new value does not already exist in Directory Server, then allstreetattribute values in Directory Server are replaced with the new, single Active Directory value.
16.5.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.
16.5.3. Configuring User Synchronization 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.
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
ntUserobject class - The
ntUserDomainIdattribute, to give the Windows ID - The
ntUserCreateNewAccountattribute, to signal to the synchronization plug-in to sync the Directory Server entry over to Active Directory
For example, using the
ldapmodify utility:
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 16.5.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 Red Hat Directory Server 11 Configuration, Command, and File Reference.
Note
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 synchronized 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.
16.5.4. Configuring User Synchronization for Active Directory Users
Synchronization for Windows users (users which originate in the Active Directory domain) is configured in the sync agreement.
To enable user synchronization:
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt set --sync-users="on" --suffix="dc=example,dc=com" example-agreement
To disable user synchronization, set the
--sync-users option to off.
