Kerberos SSO across External trust

There are a few things you need to make cross-domain Kerberos work here:

1. The account name should be in SPN format. A sAMAccountName becomes ambiguous in cross-domain Kerberos. In the AD delegation account, change the user logon name (userPrincipalName) to the same value as the servicePrincipalName, and then apply this same SPN to the Account Name field in the Kerberos SSO. This SPN should then live in three places.

    

2. You must programmatically assert the session.logon.last.domain value for users in the external domain. So for example, if the user is from example.com, you must assign session.logon.last.domain = expr { "EXAMPLE.COM" }.

    

3. APM must be able to both resolve and communicate with the remote KDC. Make sure that the F5 can resolve this domain by name and return the IPs of the KDCs, and that these IPs are accessible over TCP and UDP port 88.

    

Hello again !

We fixed our configuration and now it's looks like this:

Username: session.logon.last.username

User Realm Source: session.logon.last.domain

Kerberos realm: CONTOSO.LOCAL

KDC: empty

Account Name: host/admin.contoso.local@CONTOSO.LOCAL

SPN Pattern: empty

Clients from contoso.local domain successfully obtains tickets and evertyhing work fine. But for Example.local it's stuck at TGS req. In our /var/log/apm we have this:

 Oct 10 13:48:55 BigIp info websso.1[9143]: 014d0011:6: 29061622: Websso Kerberos authentication for user 'test_user' using config '/Common/Kerberos_SSO_CONTOSO.local' 
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0046:7: 29061622: adding item to WorkQueue
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0018:7: sid:29061622 ctx:0x5a709e08 server address = ::ffff:10.1.1.1
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0021:7: sid:29061622 ctx:0x5a709e08 SPN = HTTP/s-web-01.CONTOSO.local@CONTOSO.LOCAL
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0023:7: S4U ======> ctx: 29061622, sid: 0x5a709e08, user: test_user@EXAMPLE.LOCAL, SPN: HTTP/s-web-01.CONTOSO.local@CONTOSO.LOCAL
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0001:7: Getting UCC:test_user@EXAMPLE.LOCAL@CONTOSO.LOCAL, lifetime:36000
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0001:7: TGT expires:1412970127 CC count:1
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0001:7: Initialized UCC:test_user@EXAMPLE.LOCAL@CONTOSO.LOCAL, lifetime:36000 kcc:0x5a7095f8
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0001:7: UCCmap.size = 2, UCClist.size = 2
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: test_user@EXAMPLE.LOCAL server: HTTP/s-web-01.CONTOSO.local@CONTOSO.LOCAL - trying to fetch
Oct 10 13:48:55 BigIp debug websso.1[9143]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: test_user@EXAMPLE.LOCAL - trying to fetch
Oct 10 13:48:55 BigIp err websso.1[9143]: 014d0005:3: Kerberos: can't get S4U2Self ticket for user test_user@EXAMPLE.LOCAL - Server not found in Kerberos database (-1765328377)
Oct 10 13:48:55 BigIp err websso.1[9143]: 014d0024:3: 29061622: Kerberos: Failed to get ticket for user test_user@EXAMPLE.LOCAL
Oct 10 13:48:55 BigIp err websso.1[9143]: 014d0048:3: 29061622: failure occurred when processing the work item
Code

In WireShark we have TGS-REQ such as: KDCOptions - Forwardable, Canonicalize Realm - EXAMPLE.LOCAL Server Name (Principal) : host/admin.contoso.local And for it we this reply: error_code: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (7)

Can you help us where we need to investigate next ?

In WireShark you should see APM communicate first with the local KDC (CONTOSO.LOCAL), initial AS_REQ/REP and then a TGS_REQ to the other realm. The local KDC issues an inter-realm TGT that APM uses to communicate directly with the remote realm. So you should see APM start talking directly to EXAMPLE.LOCAL, and send the inter-realm TGT in a TGS_REQ. Where in this process do you see the server principal unknown message? Can APM resolve and communicate with the KDC in EXAMPLE.LOCAL?

Kevin, thank you for your reply!

In our wireshark we have this actions: AS-REQ - client Name - user@EXAMPLE.LOCAL(Server Name - krbtgt/EXAMPLE.LOCAL, Realm - EXAMPLE.LOCAL)

AS-REP - ticket for this user

TGS-REQ - Realm - CONTOSO.LOCAL, Server Name - krbtgt/EXAMPLE.LOCAL

TGS-REP - Realm - CONTOSO.LOCAL, Client name - host/admin.contoso.local, Server Name - krbtgt/EXAMPLE.LOCAL

TGS-REQ - Realm - EXAMPLE.COM, Server Name - host/admin.contoso.local

KRB-ERROR - error_code: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (7)

And for other question - Yes, our APM can resolve both domains.

I compared, i have principal_unknown error in second TGS req.

Our domain can see each others, which DNS records i should check ?

Going to go out on a limb here, but I believe that Kerberos Protocol Transition (KPT) DOES NOT work across non-transitive (external) trusts. It does, however, work across transitive (forest) trusts. I've tested this locally and have gotten the same exact error message. It's not an APM thing specifically, but rather a protocol limitation. Funny thing is I've actually seen this in writing somewhere, but now can't find anything to officially substantiate that claim. For what it's worth you can actually test this outside of an access policy:

kinit -f [SPN of delegation service account]
** prompts for password to that account
kvno -C -U [user@OTHER_REALM] [SPN of delegation service account]

Example:

kinit -f host/krbsrv.bravo.com
Password for host/krbsrv.bravo.com@BRAVO.COM:

This generates the AS_REQ message. No response means it worked and you've cached a new TGT.

kvno -C -U al.user@alpha.com host/krbsrv.bravo.com

The -C and -U stand for constrained delegation and protocol transition. The user is specified by its UPN and you're pointing at the delegation account. If it works you'll get something like this.

host/krbsrv.bravo.com@BRAVO.COM: kvno = 2

If it doesn't work, as in with your external non-transitive trust configuration, you'll get a "Server not found in Kerberos database" error message and "KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN" in the Windows event viewer.

That's an interesting read, but it doesn't once mention Protocol Transition (S4U2Self), which is what I believe is the limiting factor here. I applied the recommended settings and got the same errors. Moreover, here's something from Microsoft:

http://technet.microsoft.com/en-us/library/cc772683%28v=ws.10%29.aspx

When you use protocol transition across Active Directory forests, both forests must be operating at the Windows Server 2003 forest functional level and two-way forest trust must be established between the forests

That seems to imply that a forest trust is indeed required. I'm still testing this, but all roads seem to be leading to the same conclusion.