Forum Discussion

cgallimore_1748's avatar
cgallimore_1748
Icon for Nimbostratus rankNimbostratus
Mar 28, 2016
Solved

F5 APM seems to be choosing NTLM over Kerberos - cache issue?

Hello DevCentral, the scenario here is that we previously setup an application to perform NTLMv2 SSO and now have a need to perform Kerberos. When we changed the Portal Access resource to use Kerberos configuration, it is still using NTLMv2 instead. The Kerberos setup on the APM is correct as it is working for other applications and on the server as it is working for internal users. Is it possible that the F5 is just caching the chosen form of authentication since it was setup to perform NTLMv2 before? I will also mention that while tracing apm logs in SSO debug mode I do not see any attempts to perform Kerberos at all.

 

Thanks for any help.

 

  • No, there's not any cache that works that way in APM.

     

    You've probably forgotten to include resource-items in your Portal Access List or the items don't match the actual items being requested. APM doesn't necessarily know all of the URLs/hosts/ports/schemes that are included as part of your web app. So the resource-items are the way to define it if you want it to switch between SSOs for you.

     

    It could also be that your resource-items overlap with another Portal Access List.

     

3 Replies

  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account

    No, there's not any cache that works that way in APM.

     

    You've probably forgotten to include resource-items in your Portal Access List or the items don't match the actual items being requested. APM doesn't necessarily know all of the URLs/hosts/ports/schemes that are included as part of your web app. So the resource-items are the way to define it if you want it to switch between SSOs for you.

     

    It could also be that your resource-items overlap with another Portal Access List.

     

    • cgallimore_1748's avatar
      cgallimore_1748
      Icon for Nimbostratus rankNimbostratus
      Thank you for the quick response. I double checked the resource items, as we do have a couple that overlap but they all have Kerberos as their SSO Configuration. I also moved the portal access item in question to the 2nd ACL spot and the logs still seem to indicate that it is not trying Kerberos. Would you have any suggestions on what to look at next?
  • Turned out I had NTLM assigned on the Access Profile itself that must have been superseding the Portal Access configuration.