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 and then using the sAMAccountName within the KCD WebSSO profile within the access policy. The service account I am using of course has "use any auth protocol" and the appropriate HTTP/fqdn SPN hard coded to rule out reverse lookup issues for dynamic SPN creation by APM. What I am seeing is:

 

  1. Upon first login with APM SSO, my service account SPN gets a TGT and then fails to get the HTTP/service ticket with the error "Requesting ticket can't get forwardable tickets (-1765328163)"

     

  2. I kill the APM session and restart - Now when I log in, I pull the ticket for the user, but IIS throws up a few 401's with a login prompt for a three or so URIs. I "cancel" on each and then pass through to the web resource (200 OKs)

     

  3. I kill the APM session and re-login - Now I see APM debug grabbing the cached ticket and I seamlessly pass through to the desired web resource.

     

So basically it works... I just need to run through APM three times for everything to work seamlessly. The first time I cannot get a service ticket, the next time IIS doesn't accept the ticket I present, the last time everything is 200 OK and there are no issues.

 

Any ideas?

 

APM
application delivery

23 Replies

Sort By
Show More
  • 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 12, 2018

      action_; My deployment definitely requires SSO with KCD variables. My APM essentially does client-cert auth from any user anywhere and then proxies this user through into an internal sharepoint on a private domain/realm. We use identifiers within the cert the client provides to validate the client within the AD domain. All they need to provide is their cert and PIN to use it. APM takes care of the rest. From Sharepoint's perspective, all the IIS front-ends see is the F5 float IP making connections and sending TGS tickets on behalf of domain users.

       

      I went from 11.6.1 HF2 to 13.1.1 last night with no change to this particular issue, but I really didn't expect things to change. My suspicion is something in this tenant domain, but I can't point fingers just yet...

       

    • Kevin_Stewart's avatar
      Kevin_Stewart
      Icon for Employee rankEmployee
      Oct 12, 2018

      By tenant domain, do you a separate trusted domain for user accounts?

       

      If so, there are a few things you need to do:

       

      • You must ensure that the domains have a full two-way transitive trust (it wouldn't work at all if this wasn't the case)
      • The APM SSO account and the target service (assuming IIS) must be in the SAME domain.
      • APM must be able to DNS resolve (SRV records) the trusted domain and must have direct connectivity to it.
      • To avoid ambiguity, the APM SSO account should use a full SPN that identifies what domain it's in (ex. host/f5kdc.example.com). This same string is needed in three places: the APM SSO username, the AD delegation account's userPrincipalName and servicePrincipalName.
    • eric_haupt1's avatar
      eric_haupt1
      Icon for Nimbostratus rankNimbostratus
      Oct 29, 2018

      Kevin,

       

      There won't be any trust between these domains. I call this a "tenant" domain from a network perspective. It exists completely separate from our primary infrastructure for security directives a long time ago.

       

      • APM SSO account and the target service are in the same domain

         

      • DNS resolution... I configured host entries for this domain (6 servers) on the LTM/APM but it would be better to be able to define DNS "domains" in TMOS for things like this. I have this cluster leveraging a GTM DNS Delivery listener and I use an irule to select the DNS pool based on DNS Question name... so requests with names containing "*tenant.domain" go to the two tenant DCs. I need to revalidate this. This domain/Realm has also been defined in krb5.conf.

         

      The APM SSO account is specific to this domain, but does not contain the full domain name. Is this a requirement or are you suggesting simply for best practice? This will be my only application that is off of my primary domain.

       

      I opened a TAC case on this... but so far nothing has been identified as erroneous in the config.