Questo contenuto non è disponibile nella lingua selezionata.
6.3. About Synchronized Attributes
Identity Management synchronizes a subset of user attributes between IdM and Active Directory user entries. Any other attributes present in the entry, either in Identity Management or in Active Directory, are ignored by synchronization.
Note
Most POSIX attributes are not synchronized.
Although there are significant schema differences between the Active Directory LDAP schema and the 389 Directory Server LDAP schema used by Identity Management, there are many attributes that are the same. These attributes are simply synchronized between the Active Directory and IdM user entries, with no changes to the attribute name or value format.
User Schema That Are the Same in Identity Management and Windows Servers
- cn[2]
- physicalDeliveryOfficeName
- description
- postOfficeBox
- destinationIndicator
- postalAddress
- facsimileTelephoneNumber
- postalCode
- givenname
- registeredAddress
- homePhone
- sn
- homePostalAddress
- st
- initials
- street
- l
- telephoneNumber
- mail
- teletexTerminalIdentifier
- mobile
- telexNumber
- o
- title
- ou
- userCertificate
- pager
- x121Address
Some attributes have different names but still have direct parity between IdM (which uses 389 Directory Server) and Active Directory. These attributes are mapped by the synchronization process.
Identity Management | Active Directory |
---|---|
cn[a] | name |
nsAccountLock | userAccountControl |
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 mapped directly (cn to cn ) when synchronizing from Identity Management to Active Directory. When synchronizing from Active Directory cn is mapped from the name attribute in Active Directory to the cn attribute in Identity Management.
|
6.3.1. User Schema Differences between Identity Management and Active Directory
Even though attributes may be successfully synchronized between Active Directory and IdM, there may still be differences in how Active Directory and Identity Management define the underlying X.500 object classes. This could lead to differences in how the data are handled in the different LDAP services.
This section describes the differences in how Active Directory and Identity Management handle some of the attributes which can be synchronized between the two domains.
6.3.1.1. Values for cn Attributes
In 389 Directory Server, the
cn
attribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Identity Management 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 Identity Management, then all of the Identity Management 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 Identity Management uses uid
. This means that there is the potential to rename the entry entirely (and accidentally) if the cn
attribute is edited in the Identity Management.
6.3.1.2. Values for street and streetAddress
Active Directory uses the attribute
streetAddress
for a user's postal address; this is the way that 389 Directory Server uses the street
attribute. There are two important differences in the way that Active Directory and Identity Management use the streetAddress
and street
attributes, respectively:
- In 389 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 389 Directory Server definesstreet
as a multi-valued attribute, as specified in RFC 4519.
Because of the different ways that 389 Directory Server and Active Directory handle
streetAddress
and street
attributes, there are two rules to follow when setting address attributes in Active Directory and Identity Management:
- The synchronization process maps
streetAddress
in the Active Directory entry tostreet
in Identity Management. To avoid conflicts, thestreet
attribute should not be used in Active Directory. - Only one Identity Management
street
attribute value is synchronized to Active Directory. If thestreetAddress
attribute is changed in Active Directory and the new value does not already exist in Identity Management, then allstreet
attribute values in Identity Management are replaced with the new, single Active Directory value.
6.3.1.3. Constraints on the initials Attribute
For the
initials
attribute, Active Directory imposes a maximum length constraint of six characters, but 389 Directory Server does not have a length limit. If an initials
attribute longer than six characters is added to Identity Management, the value is trimmed when it is synchronized with the Active Directory entry.
6.3.1.4. Requiring the surname (sn) Attribute
Active Directory allows
person
entries to be created without a surname attribute. However, RFC 4519 defines the person
object class as requiring a surname attribute, and this is the definition used in Directory Server.
If an Active Directory
person
entry is created without a surname attribute, that entry will not be synchronized over to IdM since it fails with an object class violation.
6.3.2. Active Directory Entries and POSIX Attributes
When a Windows user account contains values for the
uidNumber
and gidNumber
attributes, WinSync does not synchronize these values over to Identity Management. Instead, it creates new UID and GID values in Identity Management.
As a result, the values for
uidNumber
and gidNumber
are different in Active Directory and in Identity Management.
[2]
The
cn
is treated differently than other synchronized attributes. It is mapped directly (cn
to cn
) when synchronizing from Identity Management to Active Directory. When synchronizing from Active Directory to Identity Management, however, cn
is mapped from the name
attribute on Windows to the cn
attribute in Identity Management.