Kerberos SSO issues

Question

Hello F5 Community&nbsp;
I'm the appointed admin of our new F5 BIG-IP appliances (11.2.1) at our company. I'm trying to get Kerberos SSO to work but some things I just can't get right. I've read a lot of the documentation on the web (F5 official only) about the APM in general, the Kerberos configuration, SSO credential mapping and so on.&nbsp;
I have a configuration in place which looks correct but doesn't work as it should. There are messages in the session log that indicate errors.&nbsp;
Before I get to the problem, a bit of information:&nbsp;
 - The SSO shall be used for MS SharePoint 2010 servers (LB of two web frontend servers)&nbsp;
 - The configuration for MSSP is done via the F5 iApp&nbsp;
 - I've got an AccessPolicy attached to the HTTPS virtual server of the iApp&nbsp;
 - I've got a SSO configuration for Kerberos with a delegation account as documented by F5&nbsp;
 - I've got a AAA Server (Kerberos) with a keytab file for this service&nbsp;
 - My access policy looks like this: http://i.imgur.com/9ISpZ.png&nbsp;
Now, the following entries in the session log bug me:&nbsp;
Kerberos: realm for user 12345@ZHAW.CH is not set, using server's realm ZHAW.CH&nbsp;
Kerberos: Failed to get ticket for user 12345@ZHAW.CH@ZHAW.CH&nbsp;
\N: failure occurred when processing the work item&nbsp;
We do have the following in the logs:&nbsp;
\N: Username used for SSO contains domain information. Please enable 'Split domain from full Username' option in Logon Page if domain info should be separated from username for SSO to work properly&nbsp;
\N: Could not find SSO domain&nbsp;
In our case the "Logon Page" is the HTTP 401 Response part on the AP. And the option to split the domain from the full username is set. It does not make a difference, though. The log says the same with or without the option enabled.&nbsp;
When I try to access the site, the first thing I get is a popup window to enter my credentials (Basic Auth), I hit ESC and try to access the URL again which then works. oO&nbsp;
I'll gladly send/upload the session log to anyone who's willing to help. It would be much aprechiated.&nbsp;
 &nbsp;
Thanks in advance,&nbsp;
Stefan&nbsp;

kevin_stewart · Answer

There are a few things worth noting: 
&nbsp;  
&nbsp; 1. Since you're denying BASIC access, you can probably remove that branch from the 401 agent. 
&nbsp; 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. 
&nbsp; 3. The service principal name you're supplying (12345@ZHAW.CH@ZHAW.CH) won't work, as it is incorrectly formatted. 
&nbsp;  
&nbsp; 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.  
&nbsp;  
&nbsp; 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. 
&nbsp;  
&nbsp; 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). &nbsp;

stefan_schnyder · Answer

Kevin, 
&nbsp;  
&nbsp; Thank you very much for you reply. That cleared up a lot of things. 
&nbsp;  
&nbsp; I removed the Basic Auth branch as you said. I didn't realize I could do that. 
&nbsp;  
&nbsp; 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. 
&nbsp; 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 &amp; errors. 
&nbsp;  
&nbsp; 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. 
&nbsp;  
&nbsp; 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. 
&nbsp;  
&nbsp; I'll tell you my results. 
&nbsp;  
&nbsp; Thanks again, 
&nbsp; Stefan

stefan_schnyder · Answer

Kevin, 
&nbsp;  
&nbsp; Do have an example on how the two session variables can be acquired? 
&nbsp;  
&nbsp; Cheers, 
&nbsp; Stefan

kevin_stewart · Answer

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. &nbsp;

kevin_stewart · Answer

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

Forum Discussion

Kerberos SSO issues

6 Replies

SSO Login Update Coming to DevCentral

Kevin - June 2026 Featured F5er

Tyler - May 2026 Featured Member

Recent Discussions

migrate from serie I to R. Cluster LTM-GTM

F5 https monitor receive string

What configuration issue am I experiencing with this 130-domain VS ?

F5 System Scanner - How I deployed it at scale

Ivanti MDM Core & F5 LTM/ASM with mTLS

Related Content

APM Cookbook: Single Sign On (SSO) using Kerberos

SSO Login Update Coming to DevCentral

Troubleshooting Kerberos Constrained Delegation: Strong Encryption Types Allowed for Kerberos

client-initiated SSO issue

Kerberos SSO Clients Not Getting Ticket

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS