Schema Elements Synchronized Between Active Directory and Directory Server

All synchronized entries in the Directory Server, whether they originated in the Directory Server or in the Windows server, have the following special synchronization attributes:

ntUniqueId 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 is set automatically when a Windows entry is synchronized but must be set manually for Directory Server entries. If ntUserDeleteAccount has the value true, the

corresponding Windows entry is deleted when the Directory Server entry is deleted.

ntDomainUser corresponds to the samAccountName attribute for Active Directory entries. User entries only.

ntGroupType is set automatically for Windows groups that are synchronized, but must be set manually on Directory Server entries before they are synchronized. Group entries only.

A pre-defined list of attributes are synchronized between Directory Server and Active Directory entries. Some of these attributes are the same, like the givenName attribute in Directory Server matches the

givenName attribute in Active Directory. Because the defined schema in Active Directory and Red Hat Directory Server are slightly different, other attributes are mapped between Active Directory and Red Hat Directory Server; most of these are Windows-specific attributes in Directory Server.

8.4.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 hardcoded 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 8.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 8.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 8.4.2, “User Schema Differences between Red Hat Directory Server and Active Directory”.

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

Directory Server Active Directory

cn 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

Table 8.2. User Schema That Are the Same in Directory Server and Windows Servers cn physicalDeliveryOfficeName description postOfficeBox destinationIndicator postalAddress facsimileTelephoneNumber postalCode givenName registeredAddress homePhone sn homePostalAddress st initials street l telephoneNumber mail teletexTerminalIdentifier manager telexNumber mobile title o userCertificate ou x121Address pager

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

8.4 .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 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. This only happens, however, if the cn attribute is synced. If the change is not synchronized, then the entry is not renamed.

8.4 .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 synched to the other system. The default password syntax setting on Directory Server mimics the default password complexity rules that Active Directory enforces.

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

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

8.4.3. Group Attributes Synchronized Between Directory Server and Active

Directory

Only a subset of Directory Server and Active Directory attributes are synchronized. These attributes are hardcoded 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 group entries 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 8.4, “Group Entry Attributes That Are the Same between Directory Server and Active Directory” 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 8.3, “Group Entry Attribute Mapping 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 8.4.4, “Group Schema Differences between Red Hat Directory Server and Active Directory”.

Table 8.3. Group Entry Attribute Mapping between Directory Server and Active Directory

Directory Server Active Directory

cn name ntGroupAttributes groupAttributes ntGroupId _cn name sAMAccountName ntGroupType groupType

Table 8.4 . Group Entry Attributes That Are the Same between Directory Server and Active Directory

cn member

description ou

l seeAlso

8.4.4. Group 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.

Nested groups (where a group contains another group as a member) are supported and for WinSync are synchronized. However, Active Directory imposes certain constraints as to the composition of nested groups. For example, a global group contain a domain local group as a member. Directory Server has no concept of local and global groups, and, therefore, it is possible to create entries on the Directory Server side that violate Active Directory's constraints when synchronized.