Setting up S4U2Proxy with FreeIPA

Let’s pick an example. In FreeIPA users, groups, hosts, services, and other resources are stored in an LDAP database. FreeIPA has its own web-based user interface which provides all kinds of operations. You want to create a simplified web application for everyday use by your fellow admin. An admin would sign-in into an application using his Kerberos credentials and then create users and groups, set or reset user passwords. When creating users, an application would automatically place them in some predefined groups. Sounds simple? Let’s first see what exactly that involves.

First, an admin Joe would obtain his Kerberos TGT ticket using kinit utility or, if SSSD is in use, this would happen automatically upon logon. Then he would use his browser to connect to the web application. The web browser will ask the KDC server to issue a ticket to HTTP service running on the host where web application runs (let’s say, it is web.example.com), by constructing a service principal HTTP/web.example.com@EXAMPLE.COM.

At web server’s side we would run Apache httpd software with mod_auth_kerb module enabled. mod_auth_kerb would pick up Kerberos authentication and set up web application environment, by defining user name to the Kerberos principal. If admin’s ticket is allowed for forwarding, it will be given by the browser and placed into the Kerberos credentials cache and the cache name will be defined in KRB5CCNAME environmental variable. At this point our web application would know who has been authenticated to it.

Now, our web application wants to talk to LDAP server. It needs to first have a ticket granting ticket from the KDC in order to obtain a ticket to LDAP service. Then it would ask for a ticket to LDAP service. By default that would be a ticket issued for principal HTTP/web.example.com@EXAMPLE.COM. If our web application wants to use the credentials forwarded by the user, KDC should have first allowed it. If “constrained delegation” is in use, this wouldn’t happen automatically, we need to set up it first. Then the application which doesn’t have user’s TGT, can use the ticket browser gave to the application as “an evidence ticket” and KDC would issue it a ticket on user’s behalf.

How S4U2Proxy is configured, highly depends on the software in use. FreeIPA has its own database driver for KDC, called ipadb. This driver knows how FreeIPA places services, users, and groups in LDAP tree (and much more). Additionally, it knows about S4U2Proxy arrangement.

In FreeIPA rules defining S4U2Proxy are placed in a separate container in LDAP, called cn=s4u2proxy,cn=etc,$SUFFIX. Each entry under cn=s4u2proxy should be of two types:

When FreeIPA is configured, you can find following when querying cn=s4u2proxy container:

Let’s ignore CIFS-related parts for the moment. They are required for cross-forests trusts to Active Directory. Each delegation entry contains list of member principals allowed to delegate user credentials and list of targets to whom they are allowed to delegate these credentials. Although this is not really required, create a new entry per each server-target configuration.

In our case we are interested in having a web server running on web.example.com to talk to LDAP server running on ipa.example.com.

This scenario is detailed below, using FreeIPA 3.2 as provided in Fedora 19. Following four steps are needed to configure S4U2Proxy constrained delegation.

Let’s review what we have at this point:

What is left? Configuring actual web application, of course!

Our web application will run on Apache web server with mod_auth_kerb module enabled. Below is a basic configuration for any Kerberos-enabled server enrolled in FreeIPA domain:

For any application in '/var/www/cgi-bin' Kerberos authentication is required, only users from EXAMPLE.COM realm will be allowed if they exist on the system, and that Kerberos service name for this directory will be comprised of HTTP and the machine’s host name (web.example.com). Additionally we specify the keytab which contains key material for HTTP/web.example.com@EXAMPLE.COM.

With mod_auth_kerb module a configuration must include KrbConstrainedDelegation On to allow mod_auth_kerb to request delegation on behalf of the authenticated principal. Additionally KrbConstrainedDelegationLock should be defined to some value to prevent multiple processes to step over each other. This is a global parameter and should be set outside of a VirtualHost.

In order to obtain the keytab we need to use ipa-getkeytab utility on the web server:

Every time ipa-getkeytab is run against the principal, its service key is refreshed. For clusterized environments it means you only need to fetch the keytab once and copy it securely to all cluster nodes.

On SELinux-enabled systems we also need to restore SELinux context for the keytab and allow httpd to communicate with LDAP server:

Additionally, on systemd-powered systems with MIT Kerberos 1.10 and above you need to force using specific location for Kerberos credentials caches. This is because MIT Kerberos 1.10+ by default stores credentials in a credentials cache of type DIR:. On Fedora 18 and 19 this directory is only allowed to be created at login. For our web server we simply override KRB5CCNAME variable in '/etc/sysconfig/httpd':

where 48 is uid of apache user. The name can be selected at random, it should be in a location where httpd process can write. On systemd-powered systems every '/tmp' is actually private to the process of the service you started.

This is it! Restart Apache and see how your web application works. I made a simple shell script to illustrate. The script shows content of the credentials cache and then runs LDAP query to see this host’s record:

Note that in the script standard error is redirected to the standard output so that we can see SASL messages.

For the application itself we also need to make sure SELinux labels are in place:

If debug log level is enabled for the Apache web server, following messages will accompany the request in the error_log (logging prefixes removed to retain clarity):

In this output two things stand out. First, mod_auth_kerb performs constrained delegation using S4U2Proxy protocol. Second, client has delegated the credentials. In the actual script output we can see that ldapsearch indeed authenticated to LDAP server using admin@EXAMPLE.COM credentials. This is also visible in the access_log:

Indeed, our little client (curl) asked for a resource, got response to authenticate, negotiated Kerberos authentication, and finally received the output of the script. Here is what we get if we run it as an IPA admin:

Finally, SASL authenticated to LDAP server as admin@EXAMPLE.COM, just as we wanted.