Chapter 7. Identity: Integrating with Microsoft Active Directory

Identity Management uses active synchronization to integrate user data stored in an Active Directory domain and the user data stored in the IPA domain. Critical user attributes, including passwords, are synchronized between the services.

The capability to sync Active Directory and IPA domains is inherent when an IPA server is first installed. The synchronization process is configured by creating agreements between the IPA server and the Active Directory domain controller.

This chapter describes how to configure synchronization, how to configure Active Directory for integration with IPA, and how to configure Windows systems within the Active Directory domain to be aware of the IPA domain.

7.1. About Active Directory and Identity Management

Within the IPA domain, information is shared among servers and replicas by copying that information, reliably and predictably, between the data masters (servers) and other data masters. This process is replication.

A similar process can be used to share data between the IPA domain and a Microsoft Active Directory domain. This is synchronization.

7.1.1. About Active Directory Synchronization

Synchronization is the process of copying data back and forth between Active Directory and Identity Management.

Synchronization is defined in an agreement between an IPA server and an Active Directory domain controller. The sync agreement defines all of the information required to identify sync-able user entries (like the subtree to synchronize and requisite object classes in the user entries) as well as defining how account attributes are handled. The sync agreements are created with default values which can be tweaked to meet the needs of a specific domain. When two servers are involved in synchronization, they are called peers.

Synchronization is most commonly bi-directional. Information is sent back and forth between the IPA domain and the Windows domain in a process that is very similar to how IPA servers and replicas share information among themselves. It is possible to configure synchronization — or certain data areas — to only sync one way. That is uni-directional synchronization.

To prevent the risk of data conflicts, synchronization is configured between one Identity Management server and one Active Directory domain controller. The Identity Management server propagates changes back to the IPA domain, while the domain controller propagates changes back to the Windows domain.

There are some key features to IPA synchronization:

A synchronization operation runs every five minutes.
Synchronization can only be configured with one Active Directory domain. Multiple domains are not supported.
Synchronization can only be configured with one Active Directory domain controller. However, it is possible to have a list of failover Active Directory domain controllers. Likewise, there can be a list of failover IPA servers to keep synchronization uninterrupted.
Only user information is synchronized.
Both user attributes and passwords can be synchronized.
While modifications are bi-directional (going both from Active Directory to IPA and from IPA to Active Directory), new accounts are only uni-directional. New accounts created in Active Directory are synchronized over to IPA. However, user accounts created in IPA must also be added in Active Directory before they will be synchronized.
Account lock information is synchronized by default, so a user account which is disabled in one domain is disabled in the other.
Password synchronization changes take effect immediately.

When Active Directory users are synchronized over to IPA, certain attributes (including Kerberos and POSIX attributes) will have IPA attributes are automatically added to the user entries. These attributes are used by IPA within its domain. They are not synchronized back over the corresponding Active Directory user entry.

Some of the data in synchronization can be modified as part of the synchronization process. For examples, certain attributes can be automatically added to Active Directory user accounts when they are synced over to the IPA domain. These attribute changes are defined as part of the synchronization agreement and are described in Section 7.3.3, “Changing the Behavior for Syncing User Account Attributes”.

7.1.2. Attributes Which Are Synchronized

Identity Management synchronizes a subset of user attributes between IPA 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 IPA user entries, with no changes to the attribute name or value format.

Table 7.1. User Schema That Are the Same in Identity Management and Windows Servers

cn^[a]	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
^[a] The `cn` is treated differently than other synced attributes. It is mapped directly (`cn` to `cn`) when syncing from Identity Management to Active Directory. When syncing from Active Directory to Identity Management, however, `cn` is mapped from the `name` attribute on Windows to the `cn` attribute in Identity Management.

Some attributes have different names but still have direct parity between IPA (which uses 389 Directory Server) and Active Directory. These attributes are mapped by the synchronization process.

Table 7.2. User Schema Mapped between Identity Management and Active Directory

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 syncing from Identity Management to Active Directory. When syncing from Active Directory `cn` is mapped from the `name` attribute in Active Directory to the `cn` attribute in Identity Management.

7.1.3. User Schema Differences between Identity Management and Active Directory

Even though attributes may be successfully synced between Active Directory and IPA, 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.

7.1.3.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 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. 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 Identity Management.

7.1.3.2. Values for street and streetAddress

Active Directory uses the attribute streetAddress for a user or group'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 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 389 Directory Server defines street 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 to street in Identity Management. To avoid conflicts, the street attribute should not be used in Active Directory.
Only one Identity Management 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 Identity Management, then all street attribute values in Identity Management are replaced with the new, single Active Directory value.

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