Integrating FreeIPA with Active Directory
Building Bridges
A directory service usually provides a wealth of information on top of the classic user and group accounts, including machine and service accounts, security rules, and possibly DNS information and other data that administrators would like to store centrally to deliver to clients in the domain.
Such data can, of course, be stored either in an Active Directory (AD) or in any other directory service, although it is not irrelevant which clients then have access to the data. For example, an AD provides more of a native interface for Windows clients than for POSIX clients. This in turn affects how well the client integration works and what data these clients can retrieve, evaluate, and implement from the directory service.
Therefore, it is very importance that you define from the beginning which data should be available to Linux clients from Windows AD. Do you just want to authenticate AD users to access resources on a Linux system, or should they also be able to evaluate appropriate security rules for access to the resources? Where should these security rules be stored? The AD may provide the corresponding functions, but the solutions provided are oriented more toward Windows clients than Linux systems.
Ultimately, you have two types of integration. First is the option to integrate Linux clients directly in a Windows domain and manage them using an AD domain controller. The second option is a kind of indirect integration based on data synchronization or domain trust. With data synchronization, user accounts with previously defined attributes are replicated in a different directory service, which then makes these account available to Linux clients. However, I won't delve into the implementation of this any further at this point because this type of indirect integration has a load of disadvantages. Instead I'll just point out the available literature on the subject [1].
Direct vs. Indirect Integration
Winbind, which comes from the Samba project, is often used in an open source environment for direct integration. The manual configuration of the necessary PAM and NSS modules, which are required for access to the LDAP and Kerberos server of a Windows domain controller, is also performed by some administrators. However, these days, the System Security Services Daemon (SSSD) [2] is used most of the time in such scenarios. This approach, together with the software [3], is the simplest way to integrate Linux clients directly into an existing Windows domain and therefore to manage them using the existing Windows tools. Proprietary tools also exist for this task: The authentication services available from Dell and originally developed by Quest will certainly be well known to a few administrators.
Direct integration requires that only a single identity store, the Active Directory, exists and is therefore the only source from which user information can be queried. This is often a requirement of various compliance regulations. However, it is the security-relevant information related to user and group accounts managed using a Windows AD that is insufficiently available to Linux clients. Just think about configuration data for sudo, SELinux Role-based Access Control (RBAC) policies, or other infrastructure-related data (e.g., for operating an automounter).
This kind of data can only be stored in a Windows AD to a very limited extent and very laboriously, which means that distributing the necessary configuration data for the indirect integration of Linux clients then needs be accomplished with the use of other management tools, such as Puppet, Foreman, Chef, or similar tools.
This approach certainly scales sufficiently for a manageable number of client systems, but it definitely is not a satisfactory solution in large environments. In such cases, you would be better off going for indirect integration based on a Kerberos trust. Here, I present an example setup based on the FreeIPA identity management framework [4].
Trust Relationships Allow Data Transfer
A domain trust is a trust relationship established between two or more domains. Such a trust relationship can, for example, be set up where domains are located in a common AD structure (forest). Here, users from one domain can be authenticated by a domain controller (DC) from the other domain. Two-way and transitive trust relationships between the domains that Windows sets up by default are responsible for this. Either Kerberos V5 or NTLM are used as protocols for this, although Kerberos is the default for Active Directory domains.
The FreeIPA open source identity management framework also provides a Kerberos realm and can present it to a Windows AD as part of a separate Kerberos structure. In turn, Windows is able to establish a trust relationship with such a Kerberos realm – even if it does not belong to a Windows domain. In this case, I am talking about a cross-realm trust. Windows users then have the option to access resources on a Linux system, which is part of the Kerberos realm with which a trust relationship was established. Because FreeIPA doesn't currently provide a global catalog server, it is effectively a one-way trust, meaning that users can't access resources from the Windows domain from the FreeIPA.
The Windows account is still just saved on the Windows domain controller. The Windows domain controller also authenticates this account. Unlike the integration of Linux on the basis of data synchronization, no additional software needs to be installed on the domain controllers.
The fact that there is a trust relationship between the Windows realm and the FreeIPA realm means that, for starters, all accounts managed by the DC can natively access Linux resources in the FreeIPA realm. This also applies to Windows accounts from other domains for which there are transitive trusts relationships. Access can also be limited, of course, but more on that later.
FreeIPA (via PAM, NSS, and various helper applications) provides a native interface for Linux and other Unix clients, so it is the perfect tool for holding other domain-relevant data in a central location and making the Linux and Unix clients available, as required. The security-related policies mentioned at the beginning of the articles are included in this, as well as SSH user and host keys, SELinux user mappings, and other data. Only the authentication of users of the AD domain occurs via the AD trust. The FreeIPA framework makes all other data available to its own client systems.
Own DNS Zones Required
A few preparations need to be made first. Both the AD and FreeIPA need standalone DNS zones because both environments store information about the Kerberos infrastructure used in SRV and TXT records in the DNS. Whether you splash out on a completely independent DNS zone for FreeIPA or whether you set it up below the existing DNS zone in the AD domain doesn't matter for now. In any case, you should make sure the zone has a proper delegation. In test environments, you can also work with corresponding forwarders. In the following example, the DNS zone of the AD domain is coe.muc.redhat.com. The FreeIPA environment receives a sub-zone called linux.coe.muc.redhat.com. This is managed via the BIND DNS server integrated in FreeIPA.
Furthermore, I assume that you already have an existing FreeIPA installation. If you don't, you can set one up using:
ipa-server-install
To use the latest features, you need to install version 4.1 of FreeIPA and version 1.12 of the client service SSSD. The setup presented here works with older versions but requires a bit more manual work here and there. A Windows Server 2008 R2 or later is required on the Windows side.
Installing samba4 for SID Resolution
The FreeIPA system must have an additional component for setting up a trust relationship with a Windows domain: samba4. To install and configure it, log in as an administrator on a FreeIPA master and then start the setup:
# kinit admin # ipa-adtrust-install --netbios-name=linux -a password
In doing so, make sure to specify the correct NetBIOS name for the FreeIPA environment. At the moment, you still need to repeat this setup on each FreeIPA master. However, the plan for future releases is that you will only have to perform this operation on one master.
Once you have successfully run through the setup tool, you should have a samba4 instance on the FreeIPA system. This can be used to provide multiple MS RPC services which, among other things, perform name resolution for SIDs (security identifiers) from the Windows environment. Unlike POSIX systems, Windows users and groups are assigned such a SID to identify them uniquely. This consists of the domain SID and a user-specific part – the relative identifier (RID).
If a Windows user logs on to a FreeIPA system later, the user's Kerberos ticket contains a whole array of such SIDs. They are combined in an MS-PAC (privilege account certificate) structure and must be resolved appropriately to, for example, detect which of the Windows groups the user is a member. FreeIPA isn't familiar with these group to start with because no data is synchronized between the different domains with a trust.
Establish Trust to the AD
Now you can make the actual trust to the root domain of an AD structure (Listing 1). To do so, you need the administrator password for the domain with which you want to establish the trust. Another possibility is initiating the trust from the Windows side and then defining a password there that can be used on the FreeIPA server when setting up the trust. However, to simplify things, I won't describe that process any further.
Listing 1: Establishing Trust
### Set up a trust to an AD domain using "ipa trust-add". # ipa trust-add --type=ad coe.muc.redhat.com --admin Administrator --password
In this example, I have established a trust relationship to the root domain of an AD structure. The domain's SID can be detected from the output of ipa trust-add. If you want to determine which other domains also belong to the AD structure, you can do so by calling up ipa trustdomain-find (Listing 2).
Listing 2: Showing Domains
### IPA can display all domains in a larger AD structure. # ipa trustdomain-find coe.muc.redhat.com Domain name: coe.muc.redhat.com Domain NetBIOS name: COE Domain Security Identifier: S-1-5-21-2960236960-1249552018-43539955 Domain enabled: True Domain name: dinslaken.coe.muc.redhat.com Domain NetBIOS name: DINSLAKEN Domain Security Identifier: S-1-5-21-4284198935-782209572-831170663 Domain enabled: True
FreeIPA is able to evaluate the transitive trust relationships between the individual Windows domains so that users from all domains of this structure can access resources in the FreeIPA domain. Listing 3 shows an example for different users from the two domains of the AD structure. In Listing 4, you can see how you exclude individual domains from the trust relationship to deny these domain users access to FreeIPA resources.
Listing 3: Evaluating Trust Relationships
### You can resolve users from all domains of the AD structure using getent getent passwd mucuser@COE.MUC.REDHAT.COM mucuser@coe.muc.redhat.com:*:1557801105:1557801105:mucuser:/home/coe.muc.redhat.com/mucuser: getent passwd dinuser@DINSLAKEN.COE.MUC.REDHAT.COM dinuser@dinslaken.coe.muc.redhat.com:*:946601116:946601116:dinuser:/home/dinslaken.coe.muc.redhat.com/dinuser:
Listing 4: Excluding Domains
### Individual domains can be excluded from the trust so that it is no longer possible to access FreeIPA resources. ipa trustdomain-disable coe.muc.redhat.com dinslaken.coe.muc.redhat.com -------------------------------------------------- Disabled trust domain "dinslaken.coe.muc.redhat.com" -------------------------------------------------- ipa trustdomain-find coe.muc.redhat.com Domain name: coe.muc.redhat.com Domain NetBIOS name: COE Domain Security Identifier: S-1-5-21-2960236960-1249552018-43539955 Domain enabled: True Domain name: dinslaken.coe.muc.redhat.com Domain NetBIOS name: DINSLAKEN Domain Security Identifier: S-1-5-21-4284198935-782209572-831170663 Domain enabled: False
The First Login
If everything has worked fine up to now, you should be able to log in to a FreeIPA system using a Windows account (Listing 5). As you can see, the login works, and the user from the Windows domain has access to the system. A corresponding POSIX UID and GID has been generated from the Windows users and groups SIDs.
Listing 5: Logging In to FreeIPA from Windows
ssh -l mucuser@COE.MUC.REDHAT.COM tscherf61 id mucuser@COE.MUC.REDHAT.COM uid=1557801105(mucuser@coe.muc.redhat.com) gid=1557801105(mucuser@coe.muc.redhat.com) groups=1557801105(mucuser@coe.muc.redhat.com), 1557800513(domain users@coe.muc.redhat.com)
During the login process on the Linux client, the client service running there – SSSD – tries to authenticate the user for the AD domain controller and, if successful, receives a Kerberos TGT (Ticket-Granting Ticket). This contains the previously mentioned PAC structure from which the FreeIPA server forms the corresponding POSIX IDs and sends them back to the Linux host in a new Kerberos service ticket. The SSSD unpacks the data and stores it in its cache for future access. At this point, the authentication process on the client is complete.
Calling up klist,
klist Ticket cache: KEYRING:persistent:0:0 Default principal: mucuser@COE.MUC.REDHAT.COM
displays the Kerberos tickets issued for the Windows user on the logged-on host.
Considering or Ignoring POSIX Attributes
In a Windows AD schema it has been possible for some time to define POSIX attributes that can be enabled using the identity management for UNIX (IMU) – formerly known as Services for UNIX (SFU) – component. You can then enter the desired attributes in the properties of a Windows user (e.g., the UID and GID), as well as the desired home directory and other POSIX information.
FreeIPA recognizes this and would revert automatically to the attributes stored in the AD, instead of defining new attributes. When creating the trust, you can explicitly determine how FreeIPA should behave if POSIX attributes are already defined in the AD. Using
ipa trust-add --range-type=ipa-ad-trust-posix
you can determine what POSIX attributes stored in the AD should be used. However, the statement says that these attributes are to be ignored and that FreeIPA should generate separate IDs each time.
Windows Groups and Security Rules
The FreeIPA framework uses group information for many security rules (e.g., sudo, SELinux, HBAC) to decide whether access for a specific user is allowed or not. However, because the framework isn't in the know about the Windows groups – after all, they're located externally and aren't stored on the FreeIPA systems – you need to use a little trick to be able to use them with the desired set of rules.
The trick consists of including all desired Windows groups in corresponding external (non-POSIX) groups; then, you can nest them in POSIX groups, which you can ultimately use in your set of rules. Listing 6 shows how you can nest all domain users from the Windows domain in a POSIX group via an external group from the FreeIPA server.
Listing 6: Using Windows Groups
### You need to use a few tricks to be able to use Windows groups on the FreeIPA.
# ipa group-add --desc='COE users external map'coe_domain_users_external --external
---------------------------------------
Added group "coe_domain_users_external"
---------------------------------------
Group name: coe_domain_users_external
Description: COE users external map
# ipa group-add --desc='COE users'coe_domain_users
------------------------------
Added group "coe_domain_users"
------------------------------
Group name: coe_domain_users
Description: COE users
GID: 1691800008
# ipa group-add-member coe_domain_users_external --external 'COE\Domain Users'
[member user]:
[member group]:
Group name: coe_domain_users_external
Description: COE users external map
External member: S-1-5-21-2960236960-1249552018-43539955-513
-------------------------
Number of members added 1
-------------------------
# ipa group-add-member coe_domain_users --groups coe_domain_users_external
Group name: coe_domain_users
Description: COE users
GID: 1691800008
Member groups: coe_domain_users_external
-------------------------
Number of members added 1
-------------------------
You can use the coe_domain_users group from now on to implement host-based access control rules, for example, and just grant members of this group access to certain systems. You can, of course, apply this procedure to all Windows groups.
Conclusions
FreeIPA provides a comprehensive integration of Linux environments in existing Windows AD structures. Unlike direct integration of Linux clients, the framework provides a native interface and makes it easy to access the Active Directory.
Using this interface, Linux clients can benefit from the usual security mechanisms and don't have to use a trimmed-down range of functions if they are made available via an AD domain controller. Another advantage of this form of integration is that Windows admins keep control of their domains, and Linux admins can provide their clients the necessary data via the FreeIPA framework.