8.4. 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 theobjectGUID
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. IfntUserDeleteAccount
has the valuetrue
, the corresponding Windows entry is deleted when the Directory Server entry is deleted.ntDomainUser
corresponds to thesamAccountName
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”.
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 |
cn | physicalDeliveryOfficeName |
description | postOfficeBox |
destinationIndicator | postalAddress |
facsimileTelephoneNumber | postalCode |
givenName | registeredAddress |
homePhone | sn |
homePostalAddress | st |
initials | street |
l | telephoneNumber |
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 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 forstreet
. Active Directory also has thestreet
attribute, but it is a separate attribute that can hold an independent value, not an alias forstreetAddress
. - Active Directory defines both
streetAddress
andstreet
as single-valued attributes, while Directory Server definesstreet
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 tostreet
in Directory Server. To avoid conflicts, thestreet
attribute should not be used in Active Directory. - Only one Directory Server
street
attribute value is synced to Active Directory. If thestreetAddress
attribute is changed in Active Directory and the new value does not already exist in Directory Server, then allstreet
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”.
Directory Server | Active Directory | |||
---|---|---|---|---|
cn | name | |||
ntGroupAttributes | groupAttributes | |||
ntGroupId |
| |||
ntGroupType | groupType |
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.