Good to see it works now. As far as I recall the MIT message is clearer in
this case.
Regards
Markus
"Victor Sudakov" wrote in message
news:20141011044626.GB49506@xxxxxxxxxxxxxxxxxxxxxx...
Markus Moeller wrote:
> What if the service principal's name in squid's keytab does not
> coincide with the host's primary FQDN (AKA `hostname`)?
>
> E.g. the squid's keytab contains keys for HTTP/proxy.my.domain while
> the server's actual FQDN is fw.my.domain?
>
> Should it cause the obscure error I have stumbled upon?
I think it could. Can you try the option -s GSS_C_NO_NAME ?
Thank you, Markus! With "-s GSS_C_NO_NAME" it works, at least with the
negotiate_kerberos_auth_test client. I will try later with real hosts
and browsers, though.
I should have guessed this before. The server's `hostname` is
"big.sibptus.transneft.ru", while "proxy.sibptus.transneft.ru" is an A
record pointing to another IP alias of the same server.
If only the Kerberos error message was more informative, something
like "principal not found in the keytab" instead of "mech unknown", I
would have guessed this long ago and would have spared myself a week
of tribulation.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov@xxxxxxxxxxxxxxxx
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
