Help with SPNEGO error
makst at upenn.edu
Tue Oct 29 08:04:55 EDT 2019
> IdP is reachable at idp.example.org, which is a CNAME to server1.example.org.
> The client may try to get a service ticket for HTTP/server1.example.org at EXAMPLE.ORG.
I've found it handy to do a klist after an attempt to see which service tickets my client has to verify the service principal names that I'm expecting.
My team has observed that certain clients will follow CNAMES to A records and some won't, depending on OS+browser combos. The only solution that seemed to work for almost all cases was to have everything be A records.
You can try toggling things like rdns = false to see if that helps.
From: users <users-bounces at shibboleth.net> on behalf of Daniel Lutz <daniel.lutz at switch.ch>
Sent: Tuesday, October 29, 2019 7:31 AM
To: users at shibboleth.net <users at shibboleth.net>
Subject: Re: Help with SPNEGO error
Wessel, Keith [28.10.19 23:00]:
> We're experimenting more with SPNEGO and are currently running into an error resulting in a SPNEGONOTAVAILABLE exception:
> 2019-10-28 16:05:50,237 - ERROR [net.shibboleth.idp.authn.spnego.impl.SPNEGOAuthnController:180] - Error extracting principal name from security context, check for hostname mismatch or other causes of a missing service ticket
> I see a reference to this in the list archives from a few years ago with no real resolution: https://shibboleth.1660669.n2.nabble.com/SPNEGO-amp-IDP-3-2-1-td7625753.html
> The explanation from SWITCH was that the client had a valid Kerberos ticket, but the service for getting a "service ticket" was not available.
While searching my archives, I found a hint to the solution to the problem described
(Unfortunately we missed to send a comment to the list and to add a note
to the documentation back then.)
Is your service DNS name a CNAME pointing to another DNS name?
In this case, the client may use a wrong service principal name (SPN).
Please can you check your DNS names of your IdP service?
Example (according to my understanding):
IdP is reachable at idp.example.org, which is a CNAME to server1.example.org.
The client may try to get a service ticket for HTTP/server1.example.org at EXAMPLE.ORG.
(See e.g. https://docs.microsoft.com/en-us/previous-versions/office/sharepoint-server-2010/gg502606(v=office.14)#kerberos-authentication-and-dns-cnames)
(Why Java "accepts" the ticket in this case is not clear to me. This could be a bug, as mentioned
This problem seems to affect some browsers (IEs) only. Have you tried with other browsers
(Firefox, Chrome) too?
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users