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.