Description of problem: The error when the client uses a wrong host name in a web browser to preform HTTP Negotiate authentication is really hard to decipher: cockpit-session: gssapi auth failed: 589824 Invalid token was supplied (Unknown error) major: GSS_C_DEFECTIVE_TOKEN minor: 0 This needs to be more descriptive if we expect people to use kerberos. Version-Release number of selected component (if applicable): krb5-libs-1.12.2-8.fc21.x86_64
Simo, would you happen to know where a more appropriate minor error could be set?
If I understand the problem correctly I am not sure this is a solvable problem. There is no way for the server to know why the client sent an invalid token, the token simply fails to decrypt. If you have control of the web server, you *may* be able to see what it the GET/POST hostname in the URL used (if it is not a relative url) and if it is not matching your name assume that a wrong hostname is the error, yes I am handwaving wildly :-)
Can we get some information about the cases where this is happening?
Greg Hudson pointed out on IRC that this may be relevant or related: http://krbdev.mit.edu/rt/Ticket/Display.html?id=7232
The important question, though, is why you're seeing GSS_S_DEFECTIVE_TOKEN. That's not intended behavior for a ticket decryption failure.
This is an Active Directory domain. I have a server with two host names in DNS: * falcon.borg.lan * falcon.thewalter.lan This is what my keytab looks like (and the computer account is named similarly): Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon 3 host/falcon 3 host/falcon 3 host/falcon 3 host/falcon 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN If use a web browser to connect to 'falcon.borg.lan' (the wrong host name) and perform Negotiate auth. I get the this GSS_S_DEFECTIVE_TOKEN (integer value 589824) from GSSAPI gss_accept_sec_context(). So the question is whether we can detect this situation and provide a more intelligible minor code back to the gss_accept_sec_context() caller?
After some evaluation I think the issue here is that the client is trying to use the IAKERB mechanism, and there is some bug with it. Can you wireshark your connection and see what mechanism is being used ?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The referenced upstream ticket has been merged. Does your issue persist? Additionally, can you provide the information Simo requested?
I believe this issue has been resolved. Please open if the issue persists.