Forum Discussion

Son_of_Tom_1379's avatar
Son_of_Tom_1379
Icon for Nimbostratus rankNimbostratus
Jul 13, 2014

Client side Kerberos with Portal Access List object

Hey There,

 

Hoping somebody can help, tearing my hair out as usual.

 

I have an access policy which performs the following:

 

Browser matches IE -> IP Subnet Matches internal -> 401 responce -> Kerberos Auth -> WebTop

 

The webtop contains some portal access list objects which I'll be configuring with SSO at some stage. For now I'm just trying to get some external links such as Google to work.

 

In the policy, if the browser or IP Subnet are not matched the user is presented with a logon page via some fall back branches.

 

When accessing a portal access list link post Kerberos authentication, the web page just sits there as "waiting for etc...". If accessing the same portal access list link post logon page/AD authentication, the link works fine.

 

The idea here is that Kerberos will silently present the web portal (which it does), and we can authorise an external Linux web host with some post info (that's the SSO part which I'm not quite up to).

 

I've been through various iterations, including referencing a separate VS for the external site, using iRules to disable the policy when referencing /f5-w- URI's, and even cross comparing session variables between logon page/AD auth and manually assigning them within the Kerberos path.

 

I'm fairly green when it comes to this (and I haven't even gotten to the SSO yet).

 

Thanks

 

APM
application delivery
deployment
devops
iRules
security

10 Replies

Sort By
  • kunjan_118660's avatar
    kunjan_118660
    Icon for Cumulonimbus rankCumulonimbus
    Jul 13, 2014

    If kerberos auth is where the application hangs, do a packet capture at the client side to see at which stage it hangs

     

     

    • 1) You should see a 401 challenge from APM
    • 2) Kerberos traffic(port 88) from client to KDC ( if not cached)
    • 3) The response from client to APM with Authorization header.
    • Son_of_Tom_1379's avatar
      Son_of_Tom_1379
      Icon for Nimbostratus rankNimbostratus
      Jul 13, 2014
      Thanks for the response Kunjan, I do not have an SSO profile attached to the portal access list object (nor do I wish to). Kerberos itself is working fine for client side access to the portal, adding the site to the IE intranet zone shoots me straight through to the webtop perfectly. It just 'appears' that something that would normally happen with the logon page/AD auth does not happen when using Kerberos. I'm certainly new to the land of client side Kerberos as I'm used to using the logon page, perhaps I'm missing something obvious. Keep in mind that I'm not yet trying SSO, and when I do it is to an external Linux web host so will be forms based authentication, not Kerberos. Thanks again
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus
    Jul 13, 2014

    If kerberos auth is where the application hangs, do a packet capture at the client side to see at which stage it hangs

     

     

    • 1) You should see a 401 challenge from APM
    • 2) Kerberos traffic(port 88) from client to KDC ( if not cached)
    • 3) The response from client to APM with Authorization header.
    • Son_of_Tom_1379's avatar
      Son_of_Tom_1379
      Icon for Nimbostratus rankNimbostratus
      Jul 13, 2014
      Thanks for the response Kunjan, I do not have an SSO profile attached to the portal access list object (nor do I wish to). Kerberos itself is working fine for client side access to the portal, adding the site to the IE intranet zone shoots me straight through to the webtop perfectly. It just 'appears' that something that would normally happen with the logon page/AD auth does not happen when using Kerberos. I'm certainly new to the land of client side Kerberos as I'm used to using the logon page, perhaps I'm missing something obvious. Keep in mind that I'm not yet trying SSO, and when I do it is to an external Linux web host so will be forms based authentication, not Kerberos. Thanks again
  • kunjan_118660's avatar
    kunjan_118660
    Icon for Cumulonimbus rankCumulonimbus
    Jul 13, 2014

    Just give a try, assuming the backend web server doesn't like the header.

    when SERVER_CONNECTED {   
   if {[HTTP::header exists Authorization]}{        
      HTTP::header remove Authorization   
   }   
}
    • Son_of_Tom_1379's avatar
      Son_of_Tom_1379
      Icon for Nimbostratus rankNimbostratus
      Jul 13, 2014
      Hey Kunjan, I've given the above a go, it required a fastHTTP profile so I've reconfigured the forwarding testing VS for Google to use one, attached an iRule and no go. It also no longer works when using the logon page/AD auth, which was working previously (I've reverted the configuration since) Kind Regards Frazer
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus
    Jul 13, 2014

    Just give a try, assuming the backend web server doesn't like the header.

    when SERVER_CONNECTED {   
   if {[HTTP::header exists Authorization]}{        
      HTTP::header remove Authorization   
   }   
}
    • Son_of_Tom_1379's avatar
      Son_of_Tom_1379
      Icon for Nimbostratus rankNimbostratus
      Jul 13, 2014
      Hey Kunjan, I've given the above a go, it required a fastHTTP profile so I've reconfigured the forwarding testing VS for Google to use one, attached an iRule and no go. It also no longer works when using the logon page/AD auth, which was working previously (I've reverted the configuration since) Kind Regards Frazer
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 14, 2014

    Try that same code in the HTTP_REQUEST_RELEASE event with a standard VS and http profile:

     

    when HTTP_REQUEST_RELEASE {   
    if {[HTTP::header exists Authorization]}{        
        HTTP::header remove Authorization   
    }   
}

    The idea here is to remove the Kerberos Authorization header at the last possible moment before traffic is released to the server, with the assumption that this header is causing problems at the application.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 14, 2014

    The only thing Kerberos adds to the request is an Authorization HTTP header. If you have decrypted access to the server side data (between F5 and the web server), try to take a capture (TCPDUMP, WireShark, etc.) and compare the working and non-working requests. Without the iRule you should probably see that client side Authorization header passing through. With the iRule it should not be there. The fact that you're getting to the webtop through the Kerberos auth path suggests that the access policy VPE itself is fine, but that there's something in the request to the web server that is different.