kerberos and ntlm authentication using APM

One of the beauties of APM's authentication FULL proxy is its native distinction between client side and server side authentication functions. While you can do client side certificate to server side Kerberos, the only things that Kerberos really needs is a valid domain username and realm, and it doesn't matter how it gets those. That said, you present a few (doable) challenges in your request that should be addressed separately.

 

 

Configuring server side Kerberos SSO

 

As I mentioned before, Kerberos SSO only needs a valid username and domain realm to authenticate a user to a service. There are, however, a few other things that you have to configure to get Kerberos SSO working:

 

 

1. Kerberos SSO is a protocol transition and constrained delegation mechanism, and as it isn't a proper member of the domain, it needs an account in the domain to do its bidding. Create a standard user account in the AD. In the User Logon Name field, create an arbitrary servicePrincipalName. This account will be used to delegate to other services and get tickets on behalf of users, so it needs to have an SPN assigned (user accounts don't normally have SPNs). An SPN is a string that represents a service and a name, so for example "host/krbsvc.example.com", where "host/" is the service and "krbsvc.example.com" is the object's name. This SPN must be unique in the domain, so it's best to create one from scratch. The User Logon (pre-windows 2000) name isn't important. Once the account is created, open up ADSIEDIT.msc or the advanced view in Active Directory Users and Computers. In ADSIEDIT, find the account and option its properties. In ADUC, open the account and go to the Attribute Editor tab. In both, find the (blank) entry for servicePrincipalName and enter the SAME SPN that you entered for the User Logon name (ex. host/krbsvc.example.com). It's not required, but probably best practice to give the SPN a fully qualified name in your domain. You can also create the SPN with the SETSPN command. Close and re-open the account properties and you'll now see a Delegation tab. Go to that tab, select "Trust this user for delegation to specified services only" and "Use any authentication protocol". This last option enabled protocol transition. Now click the Add button, find the servers that you'll be providing SSO to, and then select their http/ SPNs. So if you have 10 web servers in a BIG-IP pool with Kerberos SSO applied, you'll need to configure this account to be able to delegate to the SPNs of those web servers.

 

 

2. Create your Kerberos SSO profile. Enter the Kerberos Realm, your domain name in all upper case. Then enter the SPN that you created for the domain service account in the Account Name field. In this case however, enter the SPN with the realm (ex. host/krbsvc.example.com@EXAMPLE.COM). This will allow cross-domain authentication to work if you ever need that. Set the account's password. Now here's where it gets a little tricky. Depending on your environment, your web servers will be "owned" by different entities. I'm not going to dive into the complexities of the Kerberos protocol here, but to say that Kerberos is governed by encryption keys that are tied to SPNs. If you're using IIS, the application pool for a given site will be owned by someone or something. If you've not touched it, then by default the application pool will be owned by the host server and the SPN will be "http/". If however you've configured the application pool to be owned by another entity, a user account perhaps, then that account needs an SPN assigned to it for Kerberos authentication to work. This is all very important because of the way APM load balances Kerberos-enabled servers. When the LTM chooses a server from a pool, APM performs a reverse DNS lookup to get the name of the server based on that IP. It takes that name, adds "http/" to the front and "@" to the back to derive an SPN. So if the IIS application pool isn't owned by the server, the SPN Pattern field in the Kerberos SSO profile allows you to "short circuit" this process. One other interesting caveat (in 11.3) is that you can't put an explicit string in this field (ex. http/mywebservers.example.com@EXAMPLE.COM). You need to create a hosts entry on the BIG-IP (under System) that points every server IP in the pool to this static name, then use the %s string replacement in your SPN pattern (ex. htt/%s@EXAMPLE.COM). The reverse DNS lookup still happens, but the Hosts entry will trump any real data and return the desired name (ex. mywebservers.example.com). One final important point when configuring the Kerberos SSO profile. In the Credentials Source section there are two values, Username Source and User Realm Source. These are the APM session values that the Kerberos SSO will use to perform authentication. Somewhere in your access policy you must ensure that these values are set to a valid username and realm name for the SSO to consume. That can come from a client certificate, logon page, LDAP/AD query, or anywhere at all.

 

 

3. Ensure that the BIG-IP's time is synchronized with the domain. Kerberos is very picky about time skew. Ensure that BIG-IP is configured with the domain's DNS. The BIG-IP should be able to perform forward and reverse DNS entries for objects in the domain.

 

 

This is really all there is to server side Kerberos SSO. If you run into problems, check your SPNs and install Wireshark on the DC (if possible) to capture the Kerberos traffic for troubleshooting.

 

 

 

Failing over between server side Kerberos and NTLM SSOs

 

This one is interesting, especially if you consider that the SSO methods are generally preemptive (they don't wait for a 401 to pass credentials). You can certainly switch SSO methods via iRule, but the condition by which you decide that is the tough bit. You could, for instance, switch to NTLM if the user entered a valid username and password, and do Kerberos if the user only entered a username (and some other auth vector like RSA token or smartcard), but it would be less trivial (though not impossible) to switch from Kerberos to NTLM in the event of a 401 response. I'd recommend a reconsideration of your requirements and use cases before attempting this.

 

 

 

Passing client side Kerberos through if it exists

 

Again, without digging into the depths of the Kerberos protocol, authentication is based upon encryption keys and associated SPNs (names). A unique SPN is associated with a unique encryption key. So when a client requests a resource within a domain, a resource that requires Kerberos authentication, the client will go to the domain controller (KDC) and request a ticket to that service BY NAME. That ticket will have information about both the client and service and be wrapped in encryption keys owned by user and services. If you ask for a service by the wrong name, the KDC will encrypt it with the wrong key and the service won't be able to decrypt it. Now when you're accessing a resource through a proxy, you're typically requesting it by some name that is associated with the IP address on the proxy. So if the web server's SPN is, for example, http/server1.example.com, and the client is accessing a proxy using the name http://www.example.com, the client would ask the KDC for a ticket to http/www.example.com. If the proxy just passed that traffic through to the server, then the server wouldn't be able to do anything with it (wrong name = wrong encryption key). So you have two options:

 

 

1. Make the name that the client requests, as associated with the IP on the proxy server, the same SPN that owns the web server's application pool. You'll necessarily need to assign the application pool to a domain (user) account a) because you'll need to be able to load balance and you're only making a ticket request for ONE name, and b) the client may know how to get to server1.example.com directly and completely bypass the proxy. To your request, the implication here is that you'd have to sniff the initial request for an Authorization header and bypass the logon page in APM.

 

 

2. Proxy the client side Kerberos. This is a completely different Kerberos configuration that I won't dive into, but no more complicated than the first. To your request, the implication here is roughly the same in that you have to sniff for the Authorization header and bypass the 401 and Kerberos Auth agents and go to a logon page instead.