Product SiteDocumentation Site

Chapter 8. Identity: Integrating with Active Directory Through Cross-Realm Kerberos Trusts

8.1. The Meaning of "Trust"
8.1.1. How Trust Works: Transparency Between Kerberos and DNS Realms
8.1.2. Trust in Contrast to Synchronization
8.1.3. Active Directory Users and FreeIPA Features: sudo and Host-Based Access Control Policies
8.1.4. Potential Issues with Group Mapping and SIDs
8.1.5. Active Directory Users and FreeIPA Administration
8.2. Environment and Machine Requirements to Set Up Trusts
8.2.1. Domain and Realm Names
8.2.2. NetBIOS Names
8.2.3. Integrated DNS
8.2.4. Firewalls and Ports
8.2.5. Clock Settings
8.2.6. Supported Username Formats
8.2.7. Trust Can Only Be Configured Once
8.3. Setting up Trust with FreeIPA as a DNS Subdomain of Active Directory
8.4. Setting up Trust with FreeIPA and Active Directory in Different DNS Domains
8.5. Creating FreeIPA Groups for Active Directory Users
8.6. Using SSH from Active Directory Machines for FreeIPA Resources
8.7. Using Trust with Kerberized Web Applications
Kerberos allows the configuration of trusted realms. Each realm has its own resources and users, yet the trust relationship allows users of any trusted realm to obtain tickets and connect to machines or services in a peer realm as if they were members of that peer realm.
Because of differences in the way that Windows and Linux domains implement LDAP services, DNS management, and even Kerberos realms, it is difficult to establish a direct trust between Active Directory and Linux domains manually. A trust relationship using FreeIPA centrally defines and establishes the Kerberos trust and DNS mappings so that Active Directory users can access Linux hosts and services completely transparently, using one set of credentials.

8.1. The Meaning of "Trust"

Kerberos has the ability to create a relationship between two otherwise separate realms. This is called a cross-realm trust. This is described in some detail in Managing Single Sign-On and Smart Cards. These realms create a shared ticket and key so a member of one realm is perceived as a member of both realms. One realm trusts another.

8.1.1. How Trust Works: Transparency Between Kerberos and DNS Realms

Both Active Directory and FreeIPA manage a variety of core services: Kerberos, LDAP, DNS, certificate services. For these two disparate domains to be integrated transparently, all of these core services need to be able to interact cleanly with one another.
Those services can be broken into two major points of interaction: a Kerberos realm and a DNS domain. Certificate services, LDAP entries, and other services can be managed independently for Active Directory and FreeIPA. The place where they interect is where identities need to be authenticated (Kerberos) and a mechanism to route queries between domains (DNS).

8.1.1.1. Components Involved in Trusts

FreeIPA cross-realm trusts leverage four primary components:
  • Active Directory
  • Samba, to perform identity lookups on Active Directory and retrieve user and group security identifiers (SIDs) for authorization information
  • SSSD, to cache user, group, and ticket information for users and to map Kerberos and DNS domains
  • FreeIPA
Applications and Services for Trust
Figure 8.1. Applications and Services for Trust

8.1.1.2. Active Directory and FreeIPA Directories

One of the most common backends for user identities is Active Directory, and many environments — even primarily Linux or heterogenous environments — rely on Active Directory for user management. In many environments, however, that means that an entirely different set of users must be defined to access Linux systems.
Trusts allows a natural division of labor in an IT environment between user administration (in Active Directory) and Linux or data center management (through FreeIPA). All user accounts can be stored in Active Directory, without needing to recreate user accounts on Linux systems, while all Linux systems can still be centrally managed using native Linux tools.
Trust Direction: Active Directory Users to Linux Resources
Figure 8.2. Trust Direction: Active Directory Users to Linux Resources

Trusts, then, are essentially unidirectional. Active Directory users can access FreeIPA resources and services, but FreeIPA users cannot access Active Directory resources. Trust allows Windows administrators and users to be able to access and manage Linux resources[4].
A trust relationship is established between a single Active Directory domain and a single FreeIPA domain.

NOTE

No Windows machine can be a client of the FreeIPA domain in a trust environment. All Windows machines must be in the Active Directory domain.
A relationship is established between the Active Directory environment and the FreeIPA environment through a trust agreement, which identifies the involved domains and the settings for the trust environment.

8.1.1.3. DNS Domains

Both Active Directory and FreeIPA can define DNS services, and those DNS domains must interact cleanly with each other. There are two potential DNS configurations:
  • The DNS domains can be independent.
  • FreeIPA can be configured as a subdomain of Active Directory.
In both cases, the different domains forward requests to each other as necessary and maintain different DNS namespaces. It is just a matter of defining how they recognize each other for forwarding queries.

IMPORTANT

Both Active Directory and FreeIPA must be configured with integrated DNS servers.
Separate DNS Domains
In this case, there are two entirely different namespaces, such as ipaexample.com and adexample.com. For these domains to communicate, they must be configured as conditional forwarders of each other's domain.
Trust with Separate DNS Domains
Figure 8.3. Trust with Separate DNS Domains

FreeIPA as a Subdomain
In this case, FreeIPA is a namespace within the larger Active Directory space, such as linux.example.com and example.com. FreeIPA can be configured to send all requests to the Active Directory domain (a forward-only policy) or it can send queries first to Active Directory and then attempt to resolve them itself (a foward-first policy).
Trust with FreeIPA as a DNS Subdaomin of Active Directory
Figure 8.4. Trust with FreeIPA as a DNS Subdaomin of Active Directory

8.1.1.4. Kerberos Realms, Authentication, and Authorization

Group information in Active Directory is stored in a list of identifiers in each Kerberos ticket for Active Directory users in a special dataset called privileged access certificates or MS-PAC. The group information in the PAC has to be mapped to the Active Directory groups and then to the corresponding FreeIPA groups to help determine access. A PAC is essentially an account usability extension.
Understanding the group mapping for trusts can help clarify how groups should be structured in trust environments.
Microsoft uses a special authorization structure called privileged access certificates or MS-PAC. A PAC is embedded in a Kerberos ticket as a way of identifying the entity to other Windows clients and servers in the Windows domain.
On FreeIPA resources, if an Active Directory user requests a ticket for a service, then FreeIPA forwards the request to Active Directory to retrieve the user information. The PAC information sent back by Active Directory is embedded in the Kerberos ticket.

NOTE

All Kerberos communication for both Active Directory and FreeIPA for trusts uses GSS-API.
FreeIPA (through SSSD, as a FreeIPA client), extracts the Active Directory group security identifiers (SIDs) from the PAC. FreeIPA then compares the Active Directory SIDs in the PAC to the group SIDs configured as members in FreeIPA groups. If the Active Directory group is a member of a FreeIPA group, then the FreeIPA group SID is added to the PAC, and the Kerberos ticket is updated with the new PAC.
FreeIPA, SSSD, and Active Directory
Figure 8.5. FreeIPA, SSSD, and Active Directory

That new ticket is then used to generate a service ticket for the user, and the user is granted access to the FreeIPA-hosted services. according to their access rules. Additionally, the FreeIPA group information in the SSSD user cache is updated to include the mapped FreeIPA groups for the Active Directory user.
SSSD stores multiple TGTs and tickets for each user, as new services are accessed.
A simpler way of saying this is that Active Directory supplies a list of groups for each user, based on an identifier for the group. FreeIPA compares that list of Active Directory groups to memberships in FreeIPA groups (where each group member is identified by that SID, rather than by a name or DN). If the Active Directory groups to which the user belongs are known to the FreeIPA domain, then the user is recognized by the FreeIPA domain.
The crucial factor to realize in this is that Active Directory users are recognized to the FreeIPA domain not by their Active Directory user entry, but by their Active Directory group memberships. In a sense, Active Directory users are not trusted by the FreeIPA domain — Active Directory groups are.
But this method of mapping Active Directory group SIDs to FreeIPA group members means that group structure in FreeIPA is important. Active Directory groups have different attributes than Linux groups and, therefore, different attributes than FreeIPA groups. Most critically, Active Directory groups are not POSIX groups, while FreeIPA groups are.
FreeIPA has introduced an intermediary, non-POSIX group type, external groups, which allow entities outside FreeIPA or a Linux system to be added as member. That external group can then be added to a standard FreeIPA (POSIX) group as a member.
When Active Directory groups are added to a FreeIPA group, they can be idenfitied by their SID or by name, in the formats DOMAIN\group_name or group_name@domain. FreeIPA then resolves the group name to the SID and stores the SID as the group member entry, to be compared to any offered user PAC.
Actually configuring groups for Active Directory users is described in Section 8.5, “Creating FreeIPA Groups for Active Directory Users”.

IMPORTANT

Both Active Directory and FreeIPA must be configured with integrated certificate services.
All sessions in a trust environment are ultimately secured with Kerberos tickets, but users have different login options:
  • Ticket-based authentication through kinit
  • Simple username/password authentication that is negotiated into a ticket
  • Passwordless authentication that is negotiated into a ticket (depending on the Kerberos client configuration

8.1.2. Trust in Contrast to Synchronization

Trusts and synchronization are fundamentally different approaches to integrating a FreeIPA domain and Active Directory domain. The structure of trust domains (outlined in Section 8.1.1, “How Trust Works: Transparency Between Kerberos and DNS Realms”), the complexity of group assignments, the location of user and group entries, and other factors all influence which solution is most effective for a given environment.
Synchronization has a certain simplicity in its overall topology and setup, and it has a relatively small administrative footprint. However, it is much more limited in how it handles directory data, its ability to map entries, its overall performance, and its security.
Table 8.1. Positives and Negatives of Using Sync
Positives of Sync Negatives of Sync
  • Simple setup procedures
  • Few rules about the Active Directory configuration, including being agnostic about DNS and Kerberos domains
  • Users and groups can originate in both Active Directory and FreeIPA domains
  • Active Directory users can function as FreeIPA users, including as administrators
  • Windows machines can be added as clients to the FreeIPA domain
  • Limited set of synchronized attributes and problematic data mapping
  • Potential data inconsistency between Active Directory and FreeIPA entries for the same user
  • Different LDAP versions, synchronization protocols, and other technology differences
  • Delays in relaying updates between directories
  • Decreased performance
  • Security implications of syncing passwords — or administrative complexity for maintaining different passwords for the same user account in difference locations

The initial environment configuration for trusts is much more complex than synchronization, but it has advantages in simplifying single sign-on to systems, web applications, or terminals; not requiring additional directory administration; and preserving data integrity.
Table 8.2. Positives and Negatives of Using Trusts
Positives of Trusts Negatives of Trusts
  • Pulls in authentication, group, and authorization data automatically when a user logs in
  • Allows true single sign-on, with a single stored password and without having to synchronize passwords between directories
  • Caches data in a local database
  • Allows users to be entirely defined in a single domain, yet have access to multiple domains
  • Can be configured without having to know or restructure the underlying directory trees
  • Allows Kerberos authentication, username/password authentication (which generates a Kerberos ticket), or passwordless logins
  • Has very specific DNS configuration requirements
  • Can potentially have long wait times to retrieve data when a user initially logs in
  • Prefers that users be located in a single directory and resources in another
  • Windows machines cannot be clients of the FreeIPA domain

NOTE

There is no clear migration path from using synchronization to using trusts because the entries already exist in the backend FreeIPA LDAP directory. This means that Active Directory user entries (or all user entries, if FreeIPA users are also synced) are duplicated, which can lead to odd behavior with logins, group associations, and lookups.

8.1.3. Active Directory Users and FreeIPA Features: sudo and Host-Based Access Control Policies

Active Directory users cannot be added directly to a FreeIPA group as a member. This means that policies and configuration in FreeIPA which rely on group associations — such as host-based access control rules and sudo policies — must be configured in a kind of daisy-chain.
The Active Directory user is added to an Active Directory group, then that Active Directory group is added to a FreeIPA external group, which is added as a member to a POSIX group. The sudo, host-based access controls, and other policies are applied against that POSIX group and, ultimately, through nesting memberships applied to the Active Directory user when accessing FreeIPA domain resources.
  Active Directory Server                    Identity Management Server
---------------------------    -------------------------------------------------------
|   AD user -> AD group ->| -> | External Group -> POSIX Group -> sudo/HBAC policies |
---------------------------    -------------------------------------------|-----------
      ^                                                                   V
      |--------------------------------------------------------------------

NOTE

Testing tools such as hbactest will not work with trusted users because the trusted user group associations are resolved dynamically, not stored in the FreeIPA directory.

8.1.4. Potential Issues with Group Mapping and SIDs

Losing Kerberos Tickets
Running any command to obtain a SID from the Samba service — such as net getlocalsid or net getdomainsid — kills any existing admin ticket in the Kerberos cache.
Cannot Verify Group Membership for Users
There is no way to verify that a specific trusted user is associated with a specific FreeIPA group, external or POSIX.
Cannot Display (Remote) Active Directory Group Memberships for an Active Directory User
For Linux system users, local group associations can be shown for a user using the id command. However, Active Directory group memberships are not displayed with id for Active Directory users, even though they are with Samba tools.
The wbinfo command can be used to obtain a SID for an Active Directory user and then to display groups associated with that SID.
[root@ipaserver ~]# wbinfo -n ADDOMAIN\\jsmith
S-1-5-21-1689615952-3716327440-3249090444-1104 SID_USER (1)

[root@ipaserver ~]# wbinfo --user-domgroups=S-1-5-21-1689615952-3716327440-3249090444-1104
S-1-5-21-1689615952-3716327440-3249090444-513
S-1-5-21-1689615952-3716327440-3249090444-1106
The same query using id shows only the user information, not the Active Directory group membership information.
[root@ipaserver ~]# id ADDOMAIN\\jsmith
uid=1921801104(jsmith@adexample.com) gid=1921801104(jsmith@adexample.com) groups=1921801104(jsmith@adexample.com)

TIP

To work around this, ssh into a FreeIPA client machine as the given Active Directory user. After the first successful login, the Active Directory group memberships are detected and returned in the id search.
[root@ipaserver ~]# id ADDOMAIN\jsmith
uid=1921801107(jsmith@adexample.com) gid=1921801107(jsmith@adexample.com) groups=1921801107(jsmith@adexample.com),129600004(ad_users),1921800513(domain users@adexample.com)

8.1.5. Active Directory Users and FreeIPA Administration

Trust relationships are unidirectional. Active Directory users exist only within the Active Directory domain and are limited to what resources within the FreeIPA domain they can access. Active Directory users are not administrators for FreeIPA because they do not exist within FreeIPA.
Active Directory users, then, cannot use any FreeIPA administrative tools, including the web UI and command-line tools.


[4] Trusted users, however, cannot manage FreeIPA itself.