Integrating FreeIPA with Active Directory

Building Bridges

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Migration from LDAP to FreeIPA
    The change from centralized user authentication on a vanilla LDAP server to the FreeIPA identity management solution is easier than many admins think. Given attention to a few points, the migration takes very little time and effort.
  • A REST interface for FreeIPA
    Access to the FreeIPA identity management framework is usually handled via a graphical web interface or a command-line tool, but the framework can also be queried directly via the JSON-RPC API.
  • Save money with Samba as the domain controller on a legacy Windows NT-style domain
    Samba can act as a PDC or BDC on a Windows NT4-style domain. Compared with a Windows-only solution, Samba saves money on licensing, and users can log in from Linux or OS X.
  • Linux configuration with OpenLMI
    One of the biggest hurdles for prospective Linux administrators is a lack of standards for configuring systems based on different Linux distributions. The Open Linux Management Infrastructure – OpenLMI – is looking to establish and define a standard approach to configuring such systems.
  • Samba 4 appliances by SerNet and Univention
    Shortly after the Samba team finalized Samba 4 in December 2012, SerNet and Univention integrated the new Samba into their appliances that give administrators an easy way to set up and test a Samba 4-based Active Directory domain controller.
comments powered by Disqus