2

Iv'e got a Java app that is SSO-enabled using Kerberos under the URL http://alf-test.example.com/. Unfortunately somethings not working, the AD says it doesn't know the service principal. This is the TGS-REQ exchange:

Request:

Kerberos TGS-REQ
Record Mark: 1499 bytes
    0... .... .... .... .... .... .... .... = Reserved: Not set
    .000 0000 0000 0000 0000 0101 1101 1011 = Record Length: 1499
Pvno: 5
MSG Type: TGS-REQ (12)
padata: PA-TGS-REQ
KDC_REQ_BODY
    Padding: 0
    KDCOptions: 40810000 (Forwardable, Renewable, Canonicalize)
    Realm: EESERV.LOCAL
    Server Name (Service and Instance): HTTP/alf-test.example.com
        Name-type: Service and Instance (2)
        Name: HTTP
        Name: alf-test.example.com
    till: 2037-09-13 02:48:05 (UTC)
    Nonce: 632225483
    Encryption Types: rc4-hmac rc4-hmac-old rc4-md4 des-cbc-md5 des-cbc-crc rc4-hmac-exp rc4-hmac-old-exp

Reply:

Kerberos KRB-ERROR
Record Mark: 125 bytes
    0... .... .... .... .... .... .... .... = Reserved: Not set
    .000 0000 0000 0000 0000 0000 0111 1101 = Record Length: 125
Pvno: 5
MSG Type: KRB-ERROR (30)
stime: 2011-06-08 12:06:23 (UTC)
susec: 23385
error_code: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (7)
Realm: EESERV.LOCAL
Server Name (Service and Instance): HTTP/alf-test.example.com
    Name-type: Service and Instance (2)
    Name: HTTP
    Name: alf-test.example.com
e-data

However, the following works:

kinit HTTP/alf-test.example.com

Also, I get this output when I want setspn to list the service principal names, which looks good to me:

setspn -l test-alfrescohttp
Registered ServicePrincipalNames for CN=Alfresco-Test HTTP,CN=Users,DC=example,DC=com:
    HTTP/alf-test
    HTTP/alf-test.example.com

So, the service principal seems to exist, but I constantly see the KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN error in Wireshark when the browser first hits the host. I'm confused, what could be wrong here?

Best regards, Michael

Michael Böckling
  • 301
  • 3
  • 15

2 Answers2

3

KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN means the KDC has no idea who holds the SPN, at your case the requested SPN is HTTP/self-test.example.com

The two common reasons for this are:

  1. the SPN doesn't exists on any account in the Active Directory Forest (doesn't seems to be your case)
  2. there are more then one account that is holding the same SPN (duplicate SPN)

You probably have a duplicate SPN somewhere, hence two accounts or more are holding the same SPN.

To check the AD forest what account(s) hold an SPN run the following command:

setspn -Q HTTP/self-test.example.com

That should show you all the accounts (if any) that carry that SPN.

A * (wildcard) is also valid if you wish on using for a query

e.g. setspn -Q HTTP/self-test*

squillman
  • 37,618
  • 10
  • 90
  • 145
Akila
  • 31
  • 2
1

Requesting a ticket for Realm: EESERV.LOCAL
Should request ticket for Realm: EXAMPLE.COM

Cause same as source of Registered ServicePrincipalNames for CN=Alfresco-Test HTTP,CN=Users,DC=eeserv,DC=local:

Assuming service principal exists in AD and is properly configured, changing this may be sufficient. Don't know how to change.

84104
  • 12,698
  • 6
  • 43
  • 75
  • You are right, but unfortunately, that was a mistake on my side. I forgot to replace the domain part with example.com. – Michael Böckling Jun 21 '11 at 10:00
  • Can you please edit your original post and sanitize as appropriate? Else leave the domain names as is. Your typos make it hard to answer your question. The SPN unknown response was received as the KDC the request went to couldn't find something with the relevant SPN. Is this KDC from the same domain as when the setspn -l was issued against? your kinit is working as that kerberos client is configured to find the KDC for the realm where the SPN is registered. – maweeras Jul 16 '11 at 19:47