Forum Discussion

Le_Coyote_53930's avatar
Le_Coyote_53930
Icon for Nimbostratus rankNimbostratus
Aug 25, 2015

Kerberos delegation on 11.5.3

Hello gurus

 

Is there a way to configure Kerberos delegation on BigIp 11.5.3?

 

The doc referenced at https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-5-1/42.html and applicable to 11.5.3. refers to configuration screens that we cannot find on 11.5.3 LTM.

 

By Kerberos delegation I mean end-to-end kerberos authentication from the end-user browser down to the application server through the BigIp. NOT Kerberos termination at BigIP and then between BigIp and the application server, there is another authentication mechanism.

 

In the sequence diagram below, Service 1 would be BigIp LTM and service 2 would be the application server selected from the pool (either a common SPN or a SPN by server).

 

Thx for any valuable input.

 

 

5 Replies

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

  • 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?

     

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

     

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

     

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus

    Le Coyote,

     

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

     

    Hope this helps,

     

    N