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:
		
- ntUniqueIdcontains 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.
- ntUserDeleteAccountis set automatically when a Windows entry is synchronized but must be set manually for Directory Server entries. If- ntUserDeleteAccounthas the value- true, the corresponding Windows entry is deleted when the Directory Server entry is deleted.
- ntDomainUsercorresponds to the- samAccountNameattribute for Active Directory entries. User entries only.
- ntGroupTypeis 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
Copy linkLink copied to clipboard!
				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
Copy linkLink copied to clipboard!
				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
Copy linkLink copied to clipboard!
					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
Copy linkLink copied to clipboard!
					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
Copy linkLink copied to clipboard!
					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 bothstreetAddressandstreetas 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 Sync mapsstreetAddressin the Windows entry tostreetin Directory Server. To avoid conflicts, thestreetattribute should not be used in Active Directory.
- Only one Directory Serverstreetattribute value is synced 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.
8.4.2.4. Constraints on the initials Attribute
Copy linkLink copied to clipboard!
					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
Copy linkLink copied to clipboard!
				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
Copy linkLink copied to clipboard!
				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.