Problems with Kerberos and delegation account

ahh thanks for the fast reply - the literal string "host" - doesnt this have to match the hostname on the server where the service is running?

best regards /ti

Not at all ;-)

hmm - what does this part of the string then define?

best regards /ti

ok makes sense - got a step further - I can resolve my webserver and dns works fine but this error tells me that I stil have "something" missing in the config:

Dec 18 13:47:29 bigip1 info websso.1[7758]: 014d0011:6: 5b4c38d9: Websso Kerberos authentication for user 'thomas' using config '/Common/KerbSSO' Dec 18 13:47:29 bigip1 debug websso.1[7758]: 014d0046:7: 5b4c38d9: adding item to WorkQueue Dec 18 13:47:29 bigip1 debug websso.1[7758]: 014d0018:7: sid:5b4c38d9 ctx:0x9bf8498 server address = ::ffff:192.168.12.20 Dec 18 13:47:33 bigip1 err websso.1[7758]: 014d0019:3: 5b4c38d9: Kerberos: Failed to resolve IP address: ::ffff:192.168.12.20 Dec 18 13:47:33 bigip1 err websso.1[7758]: 014d0048:3: 5b4c38d9: failure occurred when processing the work item

As far as I could see in the setup of the SSO I didn't need to change anything else here - the DNS server from the F5 is pointing to the DC and my domain name is equal to this realm (and if some reads the start of this question I wrote AAA serveres - this was a wrong term - it is the SSO I am fighting with since we have the serverside auth here) best regards /ti

ok - found the error - simple matter of wrong setup of my dns - but now I faced teh next problem - my website hasn't got the same domain-name/realm as the windows domain - do I need to add these int that keytab then?

best regards /ti

Hi again Can some tell my the error here: Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: ctx: 0x9bf8498, SERVER: TMEVT_REQUEST

Dec 18 13:49:09 bigip1 info websso.1[7758]: 014d0011:6: bb99ef55: Websso Kerberos authentication for user 'ti' using config '/Common/ADPKerbSSO'

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0046:7: bb99ef55: adding item to WorkQueue

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0018:7: sid:bb99ef55 ctx:0x9c3be18 server address = ::ffff:192.168.12.20

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0021:7: sid:bb99ef55 ctx:0x9c3be18 SPN = HTTP/win2k8web1.testdom.dk@TESTDOM.DK

Dec 18 13:49:09 bigip1 info websso.1[7758]: 014d0022:6: bb99ef55: Kerberos: realm for user ti is not set, using server's realm TESTDOM.DK

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0023:7: S4U ======> ctx: bb99ef55, sid: 0x9c3be18, user: ti@TESTDOM.DK, SPN: HTTP/win2k8web1.testdom.dk@TESTDOM.DK

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: Getting UCC:ti@TESTDOM.DK@TESTDOM.DK, lifetime:36000

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: Found UCC:ti@TESTDOM.DK@TESTDOM.DK, lifetime:36000 left:35867

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: UCCmap.size = 1, UCClist.size = 1

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: ti@TESTDOM.DK server: HTTP/win2k8web1.testdom.dk@TESTDOM.DK - trying to fetch

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: S4U ======> trying to fetch S4U2Proxy ticket for user: ti@TESTDOM.DK server: HTTP/win2k8web1.testdom.dk@TESTDOM.DK

Dec 18 13:49:09 bigip1 err websso.1[7758]: 014d0005:3: Kerberos: can't get S4U2Proxy ticket for server HTTP/win2k8web1.testdom.dk@TESTDOM.DK - Requesting ticket can't get forwardable tickets (-1765328163)

Dec 18 13:49:09 bigip1 err websso.1[7758]: 014d0024:3: bb99ef55: Kerberos: Failed to get ticket for user ti@TESTDOM.DK

Dec 18 13:49:09 bigip1 debug websso.1[7758]: 014d0001:7: ctx: 0x9bf8498, SERVER: TMEVT_NOTIFY

Dec 18 13:49:09 bigip1 err websso.1[7758]: 014d0048:3: bb99ef55: failure occurred when processing the work item

hi again I thought that I played safe if I defined "deletegagtio to any service" instead. I'll try specify each individual computer there instead which might be the same as we do with the setspn command KDC and realm should be correct for my testing purpose. But - how do I trick it when the site I reference on the webserver f.ex is "www.myhosting.dk" and my default realm is "testdom.dk"

best regards /ti

Hi again

That's means user forest and resource forest are not the same ? In that case, your in a Cross Domain KCD use case.

Let me know if your are in this situation.

well - more or less - depends on how we look at it - the windows domain is still the same and the webserver is also still member of that domain but if we have a website with a different domain (eg realm) - hosted on that webserver - do you have any idea of which impact this has on it? Should I just define a different SPN value in the SSO config (and this also then needs som maintaince of the keytab file) User and resource fores is still the same - the users are members of the windows domain etc - but the site they access could be named some different domain extension best regards /ti

Would it be safe to say the host name of the web site doesn't match the AD domain name? Ex. a web server named www.example.com in the MYDOMAIN.COM domain.

Normally, when a user in a domain is talking to a web server in the same domain, the servicePrincipalName of that web server will reflect the host name that the browser used in its request. With a proxy in place, however, that's not necessarily important any more. Ultimately, the Kerberos AAA just needs to be able to identify the web server by its SPN. When the SSO profile starts, it'll take the IP address of the chosen web server, reverse resolve its name from the DC, and then derive the SPN from that value. If the host name of the web server computer and the SPN of the web server aren't the same, this process will obviously not work. That then is when you would use an SPN pattern in the Kerberos SSO profile. SSO will disregard the PTR lookup and use the SPN specified in this field. It doesn't matter that the realm name in the SPN is different than the domain realm for two reasons:

1. An SPN is just a name. A browser will derive its Kerberos request from that name, but otherwise it's just an identifier to an account.

    

2. Assuming the realm name of the web server was from some other trusted domain, KCD's cross-domain policy would prevent this from working at all. Kerberos constrained delegation, per RFC, does not allow SPNs to cross domain boundaries. We can do cross domain authentication as long as the Kerberos SSO service account and the web server are in the same domain (the user can be in a different domain).

    

Using the SPN Pattern field in the Kerberos SSO profile has another implication though. The normal PTR lookup allows for multiple web services with their own SPNs. If you use an SPN pattern, all of the web servers would need to be "owned" by that one SPN. If that's not the case, or you can't configure it to be that way, then you need to makes sure that a PTR lookup for that server's IP address returns the correct SPN (not necessarily the host name of the machine).

As for the SSO service account, there are generally two options:

1. Specify and use the Pre-Windows 2000 NETBIOS name of the account in the account name field. You'll still need to give it an SPN so that you can configure delegation though.

    

2. Specify and use an arbitrary SPN. For this to work, you must enter the SAME SPN value in both the User Logon Name field of the account, and its servicePrincipalName field (ie. host/arbitary-sso-account.domain.com). You then specify this SAME SPN value in the Kerberos SSO account name field. The "host/" portion is not explicitly required, except 1) it's traditional best practice and 2) you need some service identifier (ex. http/, foo/, bar/, blah/, etc.) to make it a valid SPN-formatted string. You also don't have to add the domain realm to the SPN, but that to is traditional best practice and also helps resolve ambiguity in a true cross-domain environment.