Forum Discussion
NimbostratusClient 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
10 Replies
kunjan_118660Cumulonimbus
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_1379Thanks 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
kunjanIf 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_1379Thanks 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
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_1379Hey 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
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_1379Hey 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
Employee
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
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.
