15.3. About Synchronized Attributes
User Schema That Are the Same in Identity Management and Windows Servers
Table 15.1. User Schema Mapped between Identity Management and Active Directory
|Identity Management||Active Directory|
15.3.1. User Schema Differences between Identity Management and Active Directory
184.108.40.206. Values for cn Attributes
cnattribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Identity Management
cnattribute is synchronized, then, only one value is sent to the Active Directory peer.
cnvalue is added to an Active Directory entry and that value is not one of the values for
cnin Identity Management, then all of the Identity Management
cnvalues are overwritten with the single Active Directory value.
cnattribute as its naming attribute, where Identity Management uses
uid. This means that there is the potential to rename the entry entirely (and accidentally) if the
cnattribute is edited in the Identity Management. If that
cnchange is written over to the Active Directory entry, then the entry is renamed, and the new named entry is written back over to Identity Management.
220.127.116.11. Values for street and streetAddress
streetAddressfor a user's postal address; this is the way that 389 Directory Server uses the
streetattribute. There are two important differences in the way that Active Directory and Identity Management use the
- In 389 Directory Server,
streetAddressis an alias for
street. Active Directory also has the
streetattribute, but it is a separate attribute that can hold an independent value, not an alias for
- Active Directory defines both
streetas single-valued attributes, while 389 Directory Server defines
streetas a multi-valued attribute, as specified in RFC 4519.
streetattributes, there are two rules to follow when setting address attributes in Active Directory and Identity Management:
- The synchronization process maps
streetAddressin the Active Directory entry to
streetin Identity Management. To avoid conflicts, the
streetattribute should not be used in Active Directory.
- Only one Identity Management
streetattribute value is synced to Active Directory. If the
streetAddressattribute is changed in Active Directory and the new value does not already exist in Identity Management, then all
streetattribute values in Identity Management are replaced with the new, single Active Directory value.
18.104.22.168. Constraints on the initials Attribute
initialsattribute, Active Directory imposes a maximum length constraint of six characters, but 389 Directory Server does not have a length limit. If an
initialsattribute longer than six characters is added to Identity Management, the value is trimmed when it is synchronized with the Active Directory entry.
22.214.171.124. Requiring the surname (sn) Attribute
personentries to be created without a surname attribute. However, RFC 4519 defines the
personobject class as requiring a surname attribute, and this is the definition used in Directory Server.
personentry is created without a surname attribute, that entry will not be synced over to IdM since it fails with an object class violation.
15.3.2. Active Directory Entries and RFC 2307 Attributes
gidNumberattributes. This allows Windows user entries to follow the specifications for those attributes in RFC 2307.
gidNumberattributes are not actually used as the
gidNumberattributes for the Identity Management entry. The Identity Management
gidNumberattributes are generated when the Windows user is synced over.
gidNumberattributes defined and used in Identity Management are not the same
gidNumberattributes defined and used in the Active Directory entry, and the numbers are not related.
cnis treated differently than other synced attributes. It is mapped directly (
cn) when syncing from Identity Management to Active Directory. When syncing from Active Directory to Identity Management, however,
cnis mapped from the
nameattribute on Windows to the
cnattribute in Identity Management.