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).

 

Kevin,

 

 

Thank you very much for you reply. That cleared up a lot of things.

 

 

I removed the Basic Auth branch as you said. I didn't realize I could do that.

 

 

Also I thought the SSO credential mapping was there to tell the BIG-IP to store the Kerberos ticket, so it could be presented to the MSSP server afterwards.

 

When I remove it, I get a lot of messages in the session log saying that an SSO name could not be found and that SSO is disabled. Can I ignore these? Normally, I'd think that something wouldn't work if the log has warnings & errors.

 

 

I knew that 12345@ZHAW.CH@ZHAW.CH couldn't work, but I didn't know what to do with it. I thought that with the option 'Split the domain from full username' enabled, the initial 12345@ZHAW.CH would become 12345. It seems however, that this only happens with the SSO credential mapping in the AP.

 

 

I think client side Kerberos works already they way we've got it configured. I need to have a look at the server side, though. I'm not sure if the two session variables are acquired correctly.

 

 

I'll tell you my results.

 

 

Thanks again,

 

Stefan

Kevin,

 

 

Do have an example on how the two session variables can be acquired?

 

 

Cheers,

 

Stefan

A quick way to test server side Kerberos is to simply inject arbitrary username and domain session variables before the Allow block in the VPE (overriding whatever the client side process is creating). Also notice the Credential Source fields in the Kerberos SSO profile configuration. These are the session variables the SSO will use to do Kerberos. I generally change the "session.sso.token.last.username" to "session.logon.last.username", because it makes more sense semantically next to session.logon.last.domain, but it really doesn't matter. So if you create a variable assign agent directly before the Allow block in the VPE, and assign session.logon.last.username (or session.sso.token.last.username depending on the SSO profile), and session.logon.last.domain with arbitrary name and domain values, you'll be able to directly test the server side Kerberos authentication. You could also technically remove all of the client side authentication (start-variable assign-allow) so that your test is only influenced by the server side processes.

 

These variables should already be in the session cache from the client side Kerberos.You can validate that by looking in the variables section of the reports page for that session, you can log it to /var/log/apm, or you can throw in a message box agent that displays %{session.logon.last.username} and %{session.logon.last.domain}.

I am hoping someone still looking at this post.. I am running into same issue with kerberos and cannot find the reason. First do we need to use both AAA Kerberos and SSO Kerberos? I can access server URL with kerberos and works fine for both domains

 

We have domain1 and domain2 inherited from Domainmain and have two way transitive trusts between forests.

 

Our APM policy as follows: 401->(negotiate)->Kerberos Auth-> SSO Credential Mapping-> Check incoming users domain-> if "@domain1" -> "WEBSSO::select /Common/SSO-domain1" -> domain1-variable-assigned (using split) -> allow if "@domain2" -> "WEBSSO::select /Common/SSO-domain2" -> domain2-variable-assigned (using split) -> allow

 

Since all services resides in domain1 we have service account mapped in domain1 to SPN HTTP/URL.com@domain1. We have user account also in domain2 that we are using in Domain2 SSO configuration with setspn to HTTP/URL.com@domain2

 

It works fine for domain1 user (both AAA kerberos and SSO). AAA Kerberos works fine for domain2 but fails at SSO. Found following in logs:

 

/frontend/kerberos-AP:frontend:c053507b: metadata len 430 /frontend/kerberos-AP:frontend:c053507b: Found HTTP 401 response for SSO configuration '/frontend/SSO-Kerberos-Domain2' type:'kerberos' /frontend/kerberos-AP:frontend:c053507b: Websso Kerberos authentication for user 'User1' using config '/frontend/SSO-Kerberos-Domain2' /frontend/kerberos-AP:frontend:c053507b: adding item to WorkQueue /frontend/kerberos-AP:frontend:c053507b: ctx:0x9f131e8 SPN = HTTP/xyz.com@domain2 S4U ======> /frontend/kerberos-AP:frontend:c053507b: ctx: 0x9f131e8, user: User1@domain2, SPN: HTTP/xyz.com@domain2 /frontend/kerberos-AP:frontend:c053507b: Kerberos: Failed to get ticket for user User1@domain2