The following provides guidance on the configuration of BIG-IP Local Traffic Manager and Access Policy Manager in support of Apache Web Server Smartcard / Kerberos access using Active Directory as the Key Distribution Center.  This content is part of a series developed to address the configuration of non IIS webservers to support Kerberos Single Sign On and therefore smartcard access, but should be relevant anywhere SSO utilizing Kerberos is needed.  Several assumptions are made concerning the implementation of Active Directory, PKI, and the Linux Distro(s) used.

Base Software Requirements

The following base requirements are assumed for this configuration.

• Microsoft Windows Server 2008 R2 (Active Directory)
• BIG-IP LTM 11.4 or higher (the configuration items will probably work with most versions of 11 but only 11.4 and 11.5 were tested in the scenario)
• Ubuntu Server 13.10 (This is a fairly simple and user friendly distro based on Debian, this was also tested in RHEL/CentOS.)
  • This config will work in other distro’s of Linux, but posting all the difference configurations would just be redundant.  If you need help, reach out to the US Federal Team.

How it Works

The configuration of this scenario is fairly simple.  The majority of the configuration and testing will most likely reside on the Linux side. 

1. The client access and authenticates to APM via a smartcard.
2. Depending on the method of choice, an attribute identifying the user is extracted from the certificate and validated against an AD/LDAP.  In Federal, this step has two purposes; to extract the UPN to query AD for the User (EDIPI@MIL), and to retrieve the sAMAccountName to use for the Kerberos Principal.
3. Once the user has been validated and the sAMAccountName retrieved, the session variables are assigned and the user is granted access.

Base Linux Configuration

Configure Static IP & DNS

You can use the text editor of your own preference, but I like nano so that is what I will document.

You will want to change iface eth0 inet dhcp to static, and change the network settings to match your environment.  Since this scenario uses Windows AD as the KDC, you will want to make sure your DNS points to a domain controller.

Note:  Depending on your distro, you will use dns-nameservers or resolv.conf.

I also removed the DHCP client entirely.  (Not necessary, but I like to clean out things I wont ever use.)

Restart networking

Or

Install LAMP (Linux, Apache, MySQL, PHP)

In Ubuntu, this is fairly simple, you can just do the following.

Then check the box for LAMP, and follow the on-screen instructions, set MySQL password, and then you are done.  If you access the IP of your server from a browser, you will see the default Apache "It Works!" page.

Install & Configure Kerberos

Some distros will ask for default REALM, KDC, and Admin server configs.  In my case it is F5LAB.LOCAL, 192.168.1.5, 192.168.1.5.

krb5.conf

Depending on your distro, there will be a ton of extra settings in the krb5.conf file, some related to Heimdal and some for MIT Kerberos.  The core settings that I needed for success are listed below.

[libdefaults]

Set your default realm, DNS lookups to true, and validate the encryption types.  HMAC is good, Windows does not have DES enabled by default and you should not consider enabling it.

[realms]

KDC:  Domain Controller
admin_server:  Not required, but can also point o Domain Controller
default_domain:  Kerberos Realm

Install Mod_Auth_Kerb

This is required to make Apache support Kerberos.  Some distros include this when you load apache, but here is how you make sure.

Testing

Lets make sure that we configured networking and Kerberos properly.  Use KINIT to test a known user account.  This should reach out to the KDC to get a ticket for the user.  REALMS are case sensitive, so make sure its all upper case.  The following will request a password for the user, and if everything is set up properly, there will be no response. 

You can run KLIST to see your ticket.

An example of what happens when the REALM is entered incorrectly:  KDC reply did no match expectations while getting initial credentials.

Windows Configurations

Configuring SPNs

Since Linux is not the KDC or Admin server, this is done on the Active Directory side. 
Create a user account for each application, with the appropriate Service Principal Names.  Be aware, when we run keytab, all SPNs will be overwritten, with the exception of the SPN used in the command.

Crypto

Pay attention to the encryption types that are / were enabled in the krb5.conf file.  It is important to remember that both DES cipher suites (DES-CBC-MD5 & DES-CBC-CRC) are disabled by default in Windows 7.The following cipher suites are enabled by default in Windows 7 and Windows Server 2008 R2:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC

For the purposes of this guide and the available settings in Windows use RC4-HMAC.  DO NOT enable DES on Windows.

Create a Keytab

Keytabs can be created in windows by using ktpass.  A keytab is a file that contains a Kerberos Principal, and encrypted keys.  The purpose is to allow authentication via Kerberos, without using a password.

Copy the keytab to your linux server(s).  For my use case I put the keytab at /etc/apach2/auth/apache2.keytab

Lock it down - Linux

The security of a keytab is pretty important.  Malicious users with access to keytabs can impersonate network services.  To avoid this, we can secure the keytab’s permissions. 

Testing

Now, we want to make sure everything is looking alright so far.  So lets make sure the keytab looks right, and we can authenticate properly against the KDC.

List the contents of the Keytab

Test Authentication with the S4U SPN

The following commands can be used to initialize the credential cache for the S4U proxy account and then to test authentication with a user account.

Apache Configurations

I was able to get authentication working by adding the following to the default site.  In Ubuntu its /etc/apache2/sites-enabled/000-default.conf.  

BIG-IP Configurations

This portion is actually pretty straightforward.  Configure a standard Virtual Server with a Pool pointing at the Apache Servers.

Configuration Items

•    Kerberos SSO Profile – This is used to authenticate to Apache.
•    Access Profile – The Access profile binds all of the APM resources.
•    iRule – an iRule is used to extract the smartcard certificate User Principal Name (UPN).
•    ClientSSL Profile - This is used to establish a secure connection between the user and the APM VIP. Apply the server certificate, key, and a trusted certificate authority’s bundle file. All other settings can be left at default.
•    HTTP profile – This is required for APM to function. A generic HTTP profile will do.
•    SNAT profile – Depending on other network factors, a SNAT profile may or may not be necessary in a routed environment. If the backend servers can route directly back to the clients, bypassing the BIG-IP, then a SNAT is required.
•    Virtual server –The virtual server must use an IP address accessible to client traffic. Assign a listener (destination) IP address and port, the HTTP profile, the client SSL profile, a SNAT profile (as required), the access profile, and the iRule.

Modify the krb5.conf

APM Kerberos SSO Profile

Create an APM Kerberos SSO profile like the one shown below. Change the Username Source to “session.logon.last.username”, enter the Active Directory domain name (in all upper case), enter the full service principal name of the AD user service account previously created , and enter the account’s password.  The only real change from IIS is the Send Authorization setting, which should be set to “On 401 Status Code.”

Username Source:  session.logon.last.username
User REALM Source:  session.logon.last.domain
Kerberos REALM:  F5LAB.COM
KDC(optional):    
Account Name:  HTTP/lamp.f5lab.com
Account Password:  password
Confirm Account Password:  password
SPN Pattern (optional):
Send Authorization:  On 401 Status

Note:  The full service principal name includes the service type (ex. host/), the service name (ex. krbsrv.alpha.com), and the domain realm name (ex. @ALPHA.COM – in upper case).

KDC can be specified, but is not needed unless you do not configure DNS lookup enabled in the krb5.conf on the F5.  Basically, if you dont tell the F5 how to resolve the KDC, then you need to specify one.

SPN Pattern can help resolve issues if you have issues with DNS/rDNS.  You can specify which SPN you want to sent with either a designated, or dynamic option.

VPE configuration 

The components of the VPE are as follows:

•    On-Demand Cert Auth – Set this to Require.
•    Rule event – Set the ID to “CERTPROC” to trigger the EDIPI extraction iRule code.
•    LDAP Query – Validates the UPN and retrieves sAMAccountName.

Basic CAC iRule

Put it together.

Now that all the functional parts are in place, you can test access to Apache.  If you want to add some code to see what user is hitting your application, you can create a small PHP page containing the following code.

The server variables will echo the current authenticated user name.

Troubleshooting

Kerberos is fairly fault-tolerant, if the requisite services are in place.   That being said, it can be a PITA to troubleshoot.  If Kerberos authentication fails, check the following:

1. The user has a valid ticket.  Use klist, kinit, and kvno as explained previously.
2. Validate basic network connectivity.
3. DNS (Forward & Reverse), ensure no duplicate A or PTR records.  This can be overwritten in the Keberos SSO profile SPN pattern settings.
4. Verify the clocks of the KDC and local server are synced.
5. Turn APM SSO logging up to debug and tail the APM logs (tail -f /var/log/apm).  

Questions?  Contact the US Federal team, Federal [at] f5.com.