F5 is upgrading its customer support chat feature on My.F5.com. Chat support will be unavailable from 6am-10am PST on 1/20/26. Refer to K000159584 for details.

Forum Discussion

eric_haupt1's avatar
eric_haupt1
Icon for Nimbostratus rankNimbostratus
Oct 04, 2018

APM KCD SSO - Requesting ticket can't get forwardable tickets (-1765328163) but works eventually

I'm running into this well known KCD SSO error. I have APM performing the necessary SSO variable definitions using LDAP queries which map certificate IDs (Domain userPrincipalName) to sAMAccountNames...
application delivery
BIG-IP Access Policy Manager (APM)
action_-_322447's avatar
action_-_322447
Icon for Nimbostratus rankNimbostratus
Oct 11, 2018

Just my 2c, might not be relevant to your situation.

 

I experienced something similar when I was trying to set up an office online server and attach it to our SharePoint VIP with smart card auth. Turns out I didn't need to mess with SPNs/configure Kerberos or anything. SharePoint ACLs were handling the access to the files and the IIS site used anonymous authentication.

 

eric_haupt1's avatar
eric_haupt1
Icon for Nimbostratus rankNimbostratus
Oct 31, 2018

Kevin,

 

We can replicate the issue every time. When it works I see the "S4U==OK" - note that I see this after the first attempt. It's just on the first attempt I see the "Cannot get forwardable" ... the second time I get "S4U==OK" but I don't process through fully without a "401" back. The third time I get "S4U==OK" and process through to the webapp with "200 OK" everytime.

 

In the packet captures we've taken, we see nothing out of the ordinary except a "response too big" or something along those lines for the TGT initially.

 

I can't allow APM to define the SPN using DNS so my patterns are always fully crafted in the SSO profile - This is just our standard.

 

I'm working to get access to the KDCs and IIS myself to perform packet captures do hopefully do a more thorough inspection. The config on the F5 side should work... everything is in place and correct and a similar config has worked flawlessly for use for over 2 years with hundreds of clients per day.

 

Now: the only difference I can think of is the service account. On the primary domain I can use host/service.account and it works fine. That is how I have the other domain configured. I will set a new service account with the host/service.account.domain.name and retest.

 

I have a case open... but nothing noted just yet. I'm getting ready to go from 13.1.1 to 13.1.1.2 in the next few days as well.

 

Thanks