Kerberos SSO with two realms

Question

I am working on a solution depicted in the attached file.&nbsp;
 &nbsp;
Clients are expected to authenticate with a Form-Based front-end provided by F5 APM and using a back-end Active Directory forest (realm1).&nbsp;
Then they are supposed to have a transparent logon to a Web server located in another Active Directory forest  (realm2) that trusts the user account forest.&nbsp;
 &nbsp;
Everything works well except the SSO part which is not transparent and pops a username/password dialog in the browser.&nbsp;
In Wireshark traces i see a KDC_ERR_S_PRINCIPAL_UNKNOWN error.&nbsp;
 &nbsp;
In the packet details I see that APM sets an incorrect realm when trying to get the user's TGT as following:&nbsp;
&nbsp;
and sends it to the Realm2 KDC. As the Realm2 KDC knows nothing about the Realm1 this request fails with the error above.&nbsp;
 &nbsp;
SSO setup details:&nbsp;
 &nbsp;
Username: session.logon.last.username&nbsp;
User Realm Source: session.logon.last.domain&nbsp;
Kerberos realm: Realm2 (server's realm in capital letters)&nbsp;
KDC: empty  (as recommended in the manual for different user and server realms)&nbsp;
SPN Pattern: empty&nbsp;
 &nbsp;
VPE Policies are shown in the attached picture.&nbsp;
 &nbsp;
Could anyone confirm whether SSO is supported in the cross-forest trust scenarios?&nbsp;
The APM documentation mentions that user and server realms can be different.&nbsp;
 &nbsp;
Any hints will be appreciated&nbsp;
 &nbsp;
Thank you in advance&nbsp;
APM Version 11.3.0&nbsp;
 &nbsp;

kevin_stewart · Answer

APM Kerberos SSO does support cross-forest trust as long as you specify the user's real realm. Are you specifying the user's domain name in the session.logon.last.domain variable? You may need to set it manually. 
&nbsp;  
&nbsp; Also, are you seeing the server principal unknown error directly after the call for "krbtgt/Realm1@Realm2"? For cross-forest Kerberos to work both domains must be able to communicate and have a Kerberos keys in each others realms. So if you need to authenticate realm1 users to a realm2 service, the SSO agent must first get a ticket from its own domain for the KDC in the other domain (this is the krbtgt/Realm1@Realm2 ticket request). Once the SSO agent has this ticket, it uses it very much like a TGT to realm2 to request access to the service in realm2. The SSO agent must also be able to resolve both realms.

lloyd_56248 · Answer

Hi, in my experience DNS has to be rock solid for Kerberos Constrained Delegation to work. I would have Kerberos working for one domain, then introduce the second. You might want to add a final SSO Credential Mapping to the policy also.

kevin_stewart · Answer

SSO credential mapping is not necessarily required for Kerberos SSO. The credential mapping agent simply plugs the required username and password values into the right session (token) variables for things like form-based SSO. As long as you're populating the correct session variables in the access policy (as determined by the username and domain source fields in the Kerberos SSO profile), you should be good to go. For testing purposes you can also arbitrarily set the session.logon.last.username and session.logon.last.domain to known good user and domain values to bypass everything but the SSO. 
&nbsp;  
&nbsp; But I would agree that DNS is absolutely critical. APM must be able to resolve (forward and reverse) each of the domains.   
&nbsp;  
&nbsp; I would also not that while the APM Kerberos SSO username source defaults to session.sso.token.last.username (what the credential mapping agent would use), I typically reset it to session.logon.last.username (as East Coast has also apparently done). 
&nbsp;  &nbsp;

east_coast_1151 · Answer

Posted By Kevin Stewart on 03/19/2013 07:56 AM&nbsp;
APM Kerberos SSO does support cross-forest trust as long as you specify the user's real realm. Are you specifying the user's domain name in the session.logon.last.domain variable? You may need to set it manually.&nbsp;
&nbsp;
Also, are you seeing the server principal unknown error directly after the call for "krbtgt/Realm1@Realm2"? For cross-forest Kerberos to work both domains must be able to communicate and have a Kerberos keys in each others realms. So if you need to authenticate realm1 users to a realm2 service, the SSO agent must first get a ticket from its own domain for the KDC in the other domain (this is the krbtgt/Realm1@Realm2 ticket request). Once the SSO agent has this ticket, it uses it very much like a TGT to realm2 to request access to the service in realm2. The SSO agent must also be able to resolve both realms.
 &nbsp;
Thank you for the prompt response.&nbsp;
&nbsp;
1. Yes, the user's realm is specified as the user's domain name ( session.logon.last.domain). I checked the variable value before SSO and it contains the good value.&nbsp;
2. Yes, I am seeing the error right after the cross-realm TGS request for . I tried to set a principal with the this exact name in Realm2 and the UNKNOWN PRINCIPAL error moved to the next step when APM tries to get a TGS for itself in the user's realm. This represents moving from the step 2 to the step 3 on the diagram below.&nbsp;
http://msdn.microsoft.com/en-us/library/cc246109.aspx&nbsp;
3. DNS records are good and all KDC and DC records are set correctly. I use Microsoft DNS in both forests and each of them has a stub zone for another forest. I see also in Wireshark traces that DNS records are all resolved properly.&nbsp;
4. The forest trust is established using standard Microsoft Active Directory GUI tools, so I have not played with manual settings for krbtgt keys and principals.&nbsp;
---&nbsp;
I did a lot of research today and encountered some vague mentions that the Kerberos S4U2Self feature might be not working with one-way trusts because some referrals might be missing.&nbsp;
Anyone can confirm that?&nbsp;
 &nbsp;
So I decided to try to give it a try and to make the trust bidirectionnal and ... surprise ... SSO started working properly.&nbsp;
However, I need to keep a one-way trust because the resource forest is located at a service provider site and our company can't trust it.&nbsp;
So I am still looking for a Kerberos solution with one-way trust and very interested to know if F5 APM support it.&nbsp;
 &nbsp;
Do you know if  it is possible?&nbsp;
May be I can define manually some principals or spn without setting a complete two-way trust?&nbsp;
 &nbsp;
Thank you for your help&nbsp;
 &nbsp;
 &nbsp;
 &nbsp;
 &nbsp;

kevin_stewart · Answer

East Coast, you may already know this, but for the larger audience, your suspicions were correct. Kerberos S4U does in fact require a two-way trust between domains/forests. 
&nbsp;  
&nbsp; http://support.microsoft.com/?kbid=954739 
&nbsp; http://msdn.microsoft.com/en-us/magazine/cc188757.aspx 
&nbsp;  
&nbsp; Thanks to some internal F5 folks for finding these articles. I wasn't sure either. 
&nbsp;  
&nbsp; That said, I see a potential alternative. Given that you're authenticating the user via form logon, you have the credentials (and I assume the domain) to perform an HTTP Basic or NTLM authentication to the web server.

Forum Discussion

Kerberos SSO with two realms

8 Replies

F5 Architecture Track Sessions - AppWorld 2026

Recent Discussions

VIP is not responding on SYN after enabling other modules like ASM, APM and AFM.

2026 301a exam

F5OS login with admin/root failed via console

UCS Encryption Question

Unblock Request WAF

Related Content

Troubleshooting Kerberos Constrained Delegation: Strong Encryption Types Allowed for Kerberos

Kerberos is Easy - Part 2

Kerberos Is Easy - Part 1

APM Cookbook: Single Sign On (SSO) using Kerberos

Kerberos Authentication Failing for Exchange 2016 Behind F5 Cloud WAF

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS