Product SiteDocumentation Site

8.2. About Synchronized Attributes

8.2.1. User Attribute Synchronization

FreeIPA synchronizes a subset of user attributes between FreeIPA and Active Directory user entries. Any other attributes present in the entry, either in FreeIPA 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 FreeIPA, there are many attributes that are the same. These attributes are simply synchronized between the Active Directory and FreeIPA user entries, with no changes to the attribute name or value format.
User Schema That Are the Same in FreeIPA 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 FreeIPA (which uses 389 Directory Server) and Active Directory. These attributes are mapped by the synchronization process.
Table 8.1. User Schema Mapped between FreeIPA and Active Directory
FreeIPA 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 FreeIPA to Active Directory. When syncing from Active Directory cn is mapped from the name attribute in Active Directory to the cn attribute in FreeIPA.

8.2.1.1. User Schema Differences between FreeIPA and Active Directory

Even though attributes may be successfully synced between Active Directory and FreeIPA, there may still be differences in how Active Directory and FreeIPA 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 FreeIPA handle some of the attributes which can be synchronized between the two domains.
8.2.1.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 FreeIPA 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 FreeIPA, then all of the FreeIPA 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 FreeIPA uses uid. This means that there is the potential to rename the entry entirely (and accidentally) if the cn attribute is edited in the FreeIPA. 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 FreeIPA.
8.2.1.1.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 FreeIPA 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 FreeIPA:
  • The synchronization process maps streetAddress in the Active Directory entry to street in FreeIPA. To avoid conflicts, the street attribute should not be used in Active Directory.
  • Only one FreeIPA 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 FreeIPA, then all street attribute values in FreeIPA are replaced with the new, single Active Directory value.
8.2.1.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 FreeIPA, the value is trimmed when it is synchronized with the Active Directory entry.
8.2.1.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 synced over to FreeIPA since it fails with an object class violation.

8.2.1.2. Active Directory Entries and RFC 2307 Attributes

Windows uses unique, random security IDs (SIDs) to identify users. These SIDs are assigned in blocks or ranges, identifying different system user types within the Windows domain. When users are synchronized between FreeIPA and Active Directory, Windows SIDs for users are mapped to the Unix UIDs used by the FreeIPA entry. Another way of saying this is that the Windows SID is the only ID within the Windows entry which is used as an identifier in the corresponding Unix entry, and then it is used in a mapping.
When Active Directory domains interact with Unix-style applications or domains, then the Active Directory domain may use Services for Unix or IdM for Unix to enable Unix-style uidNumber and gidNumber attributes. This allows Windows user entries to follow the specifications for those attributes in RFC 2307.
However, the uidNumber and gidNumber attributes are not actually used as the uidNumber and gidNumber attributes for the FreeIPA entry. The FreeIPA uidNumber and gidNumber attributes are generated when the Windows user is synced over.

NOTE

The uidNumber and gidNumber attributes defined and used in FreeIPA are not the same uidNumber and gidNumber attributes defined and used in the Active Directory entry, and the numbers are not related.

8.2.2. Group Attribute Synchronization

8.2.2.1. About Windows Group Types

In Active Directory, there are two major types of groups: security and distribution. Security groups are most similar to groups in FreeIPA, since security groups can have policies configured for access controls, resource restrictions, and other permissions. Distribution groups are for mailing distribution. These are further broken down into global and local groups. The FreeIPA ntGroupType supports all four group types:
  • -21483646 for global/security (the default)
  • -21483644 for domain local/security
  • 2 for global/distribution
  • 4 for domain local/distribution

8.2.2.2. Group Attributes Synchronized between FreeIPA and Active Directory

Only a subset of FreeIPA and Active Directory attributes are synchronized. These attributes are hard-coded and are defined regardless of which way the entry is being synchronized. Any other attributes present in the entry, either in FreeIPA or in Active Directory, remain unaffected by synchronization.
Some attributes used in FreeIPA 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.3, “Group Entry Attributes That Are the Same between FreeIPA and Active Directory” shows attributes that are the same between the FreeIPA 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 FreeIPA, 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.2, “Group Entry Attribute Mapping between FreeIPA and Active Directory” shows the attributes that are mapped between the FreeIPA and Windows servers.
For more information on the differences in ways that FreeIPA and Active Directory handle some schema elements, see Section 8.2.2.3, “Group Schema Differences between FreeIPA and Active Directory”.
Table 8.2. Group Entry Attribute Mapping between FreeIPA and Active Directory
FreeIPA Active Directory
cn name
ntUserDomainID name
ntGroupType groupType
uniqueMember
member
 Member[a]
[a] The Member attribute in Active Directory is synced to the uniqueMember attribute in FreeIPA.

Table 8.3. Group Entry Attributes That Are the Same between FreeIPA and Active Directory
cn o
description ou
l seeAlso
mail

8.2.2.3. Group Schema Differences between FreeIPA and Active Directory

Although Active Directory supports the same basic X.500 object classes as FreeIPA, 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. FreeIPA has no concept of local and global groups, and, therefore, it is possible to create entries in FreeIPA that violate Active Directory's constraints when synchronized.

[2] The cn is treated differently than other synced attributes. It is mapped directly (cn to cn) when syncing from FreeIPA to Active Directory. When syncing from Active Directory to FreeIPA, however, cn is mapped from the name attribute on Windows to the cn attribute in FreeIPA.