Kerberos SSO issues

There are a few things worth noting:

 

 

1. Since you're denying BASIC access, you can probably remove that branch from the 401 agent.

 

2. As you're doing Kerberos to the MSSP servers, you really don't need the SSO credential mapping agent either - that's for forms.

 

3. The service principal name you're supplying (12345@ZHAW.CH@ZHAW.CH) won't work, as it is incorrectly formatted.

 

 

It may be better to take a step back and discuss the different pieces in play here. APM splits Kerberos authentication into two distinct "regions" - client side and server side. These sides have relatively nothing to do with one another other than the user ID and realm that is *usually* acquired from the client side authentication.

 

 

The VPE and AAA are client side functions. Users connect to the VIP, get a 401, go get a Kerberos ticket, then present that ticket back to the VIP. The ticket, encoded in the Authorization header of the request, passes through the 401 and is decrypted by the Kerberos agent (if the AAA is correctly configured). At this point client side Kerberos is done.

 

 

The SSO profile is for server side Kerberos. It uses its AD service account to perform protocol transition and constrained delegation to the back end web servers (it's still protocol transition even if the client side is also Kerberos). The only thing it needs from the client side is the two session variables: session.logon.last.username and session.logon.last.domain. How you acquire those variables is up to you, and can be "finessed" as needed before the access policy reaches the Allow block. The username variable should be either the userPrincipalName (without the realm) or sAMAccountName attributes of a domain user. The domain variable is the AD domain realm (in all uppercase).