Help with SPNEGO error

Wed Oct 30 18:11:01 EDT 2019

Thanks, all. This helped. I had failed to understand that the client would do a reverse look-up on the IP it had connected to for Shibboleth. In our case, we have a GSLB routing connections via dynamic DNS to SLBs that have the real servers behind them. I already had the main service cname's principal and the principals of each of the real servers in my service's keytab, but we didn't have principals for the SLBs, and the SLBs are what the client is talking to. We added these, and we're further along.

Now, of course, we're getting errors about the client using NTLM even though we followed the instructions on the wiki about browser configuration, but I suspect we're missing something. At least a new error is progress. I think we can take it from there.

Thanks again,
Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Simon Lundström
Sent: Wednesday, October 30, 2019 6:08 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Help with SPNEGO error

Yes, DNS and time are the main culprits, in that order, when dealing 
with Kerberos IME.

As said before having the same forward and backwards DNS-record for your 
IP is needed.

You can, if DNS roundrobin is your only choice, have a service principal 
for the forward and all the backwards records in your keytab and it will 
work, e.g (with faked data):

$ host idp.su.se
idp.su.se has address 127.0.0.1
idp.su.se has address 127.0.0.2
$ host 127.0.0.1
1.0.0.127.in-addr.arpa domain name pointer idp1.su.se
$ host 127.0.0.2
2.0.0.127.in-addr.arpa domain name pointer idp2.su.se
# ktutil -k /etc/krb5.keytab-http-idp.su.se list --timestamp # Heimdal
/etc/krb5.keytab-http-idp.su.se:

Vno  Type                     Principal                     Date        Aliases
  1  aes256-cts-hmac-sha1-96  HTTP/idp.su.se at SU.SE  2019-10-30
  1  aes256-cts-hmac-sha1-96  HTTP/idp1.su.se at SU.SE 2019-10-30
  1  aes256-cts-hmac-sha1-96  HTTP/idp2.su.se at SU.SE 2019-10-30
# klist -tek /etc/krb5.keytab-http-idp.su.se # MIT Kerberos
Keytab name: FILE:/etc/krb5.keytab-http-idp.su.se
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   1 30/10/19 13:33:37 HTTP/idp.su.se at SU.SE (aes256-cts-hmac-sha1-96)
   1 30/10/19 13:33:37 HTTP/idp1.su.se at SU.SE (aes256-cts-hmac-sha1-96)
   1 30/10/19 13:33:37 HTTP/idp2.su.se at SU.SE (aes256-cts-hmac-sha1-96)

BR,
- Simon

On Tue, 2019-10-29 at 13:04:55 +0100, Mak, Steve wrote:
>> 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.

Always a good tip. Also tcpdumping on port 88 are sadly often essential as well.

>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.

Sadly some will probably clients be out of your control. But they might 
be negligible.

>________________________________
>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
>in https://shibboleth.1660669.n2.nabble.com/SPNEGO-amp-IDP-3-2-1-td7625753.html.
>(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
>by Scott.)
>
>This problem seems to affect some browsers (IEs) only. Have you tried with other browsers
>(Firefox, Chrome) too?
>
>  Daniel
>--
>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

>-- 
>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

-- 
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