Kerberos delegation on 11.5.3

Le Coyote,

I believe you will need to have an APM license to enable Kerberos authentication.

Hope this helps,

N

we have APM as well but still cannot figure out how to configure the Kerberos delegation.

A couple of things:

1. The Kerberos delegation function that you're referring to is an artifact of the old ACA (advanced client authentication) module that has been deprecated. You may have it in 11.5 because you licensed it with an older version and upgraded, but that product will cease to exist very soon.

    

   "By Kerberos delegation I mean end-to-end kerberos authentication from the end-user browser down to the application server through the BigIp"

    

2. That isn't delegation, it's just pass-through. Delegation is where a client would pass it's forwarding ticket to another service that then requests Kerberos tickets on its behalf. That's what APM would give you and what the old ACA Kerberos delegation would have given you.

    

For end-to-end (non-delegated) Kerberos to work through the BIG-IP, you have to consider that the client is going to be fetching the ticket to the (backend) services on its own. A client browser will use the FQDN in the URL as the servicePrincipalName to request, so if the VIP's URL is www.example.com and the backend server's SPN is internal.domain.com, then the browser is going to attempt (and probably fail) to get a ticket for www.example.com. Long story short, in order to do Kerberos pass-through, the external VIP FQDN must match the correct internal SPN.

Thanks - I'm not referring to a pass through but to a real delegation (use of "through" word was confusing :-)) as per the diagram I included where indeed "a client would pass it's forwarding ticket to another service that then requests Kerberos tickets on its behalf."

is there any clearly documented instructions on how to do this with APM?

APM can absolutely do this, but it isn't a simple delegate service as you're describing. APM is an authentication proxy, and as such uses separate processes for both client side and server side Kerberos. The client would pass a non-delegated ticket to the client side of APM, and APM would perform Kerberos Protocol Transition and Constrained Delegation to the server on the server side. This is essence allows you to do one side without the other. So to clarify, APM cannot consume and delegate forwarded Kerberos tickets as you're describing.

For APM Kerberos to work, you need a client side APM Kerberos configurtion:

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-aaa-auth-config-11-2-0/4.html?sr=47873427

which once successful produces a set of session variables, in particular session.logon.last.username (ex. bob.user@domain.com) in UPN format. Then you apply an APM Kerberos SSO profile to the access policy:

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-sso-config-11-2-0.pdf?sr=47873443

This requires as input the username and the domain, which can be extracted from the UPN in the client side Kerberos transaction using a variable assignment agent in the visual policy:

session.sso.token.last.username = return [lindex [split [mcget {session.logon.last.username}] "@"] 0]

session.logon.last.domain = return [lindex [split [mcget {session.logon.last.username}] "@"] 1]

The simplest configuration, with client side and server side Kerberos would look something like:

start -> 401 Auth -> Kerberos Auth -> Variable assign -> Allow

where the 401 and Kerberos Auth agents would handle client side Kerberos, the variable assignment would split the UPN into separate username and domain session variables, and the SSO would be applied to policy itself and be triggered at the Allow block.