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.

### 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).

### 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.

### 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:

### 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.

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.