Hi Kornel,

I have never had much luck debugging that error message directly.  But that indicates something is not correct with  a) your keytab file, or b) your Kerberos SPN / AD / DNS setup causing your client to not send the correct ticket for the configured SPN.  

There are many reasons why you could receive that error message, but it ultimately means the ticket received from the client did not match any valid entries in your keytab file.

The fact that kinit works indicates that your /etc/krb5.conf settings are correct.  It also means that using Basic Auth as provided by mod_kerb_auth should work as well.  It does not indicate that your keytab is correct or that your Kerberos clients are sending in correct ticket.

To debug:

The best way for me to debug that error message was to run tcpdump on the webserver, make a request with a Windows client, then inspect the tcpdump with Wireshark.  Wireshark makes it very easy to see the whole conversation, and it also has a nice GUI interface for inspecting the Kerberos handshake within the HTTP conversation.  If I remember correctly, you should see something like this:

CLIENT:  GET /

SERVER: 401 Authorization Required, WWW-Authenticate: Negotiate, WWW-Authenticate: Basic

CLIENT: GET /, WWW-Authenticate: Negotiate <---- Inspect this request.  Dig into the Negotiate header and figure out what SPN was sent with the ticket.  Ensure that the SPN matches what was used for your keytab.

SERVER: OK, here's your document

In our case, we ran into this problem because we had multiple DNS entries pointing to the same IP address.  Use `dig -x 1.2.3.4`, where 1.2.3.4 is the IP address of your webserver / virtualhost.  Ensure that only a single DNS entry is being returned and that it matches the SPN you setup in your keytab.

There are many other reasons why it could be failing, but watching the HTTP conversation is a good start.  Verify the DNS entries like I said.  Finally, learn to use the "setspn" command on your Windows AD controller.  `setspn -q HTTP/yourwebserver.yourdomain.com` will query your AD for the SPN name and should only return a single correct entry.

A great reference for setting up Kerberos with a Windows AD environment is here: http://grolmsnet.de/kerbtut/

Good luck, and don't give up!

-Brandon Kirsch

2012/1/5 Kornél Keserű <keseruk <at> gmail.com>

Hi all,

Recently we got the task of setting up SSO for a web portal developed by us. The server in question is CentOS, running an Apache with mod_auth_kerb configured and the KDC is an Active Directory. We are using versions 1.9 of the krb5... packages.

We followed the documentation for setting up Kerberos SSO with Apache but we were unable to make it working with our Windows XP test client.

We are using keytab file to identify the service to the AD. Previously we have successfully tested the setup using the console commands kvno, kinit, etc.

The only symptoms we have are some debug/error messages in the apache log:

[debug] src/mod_auth_kerb.c(1074): [client ...] GSS-API major_status:000d0000, minor_status:000186a4

[error] [client ...] gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, )

Could you please give me hints on how to locate the problem? What further symptoms can be collected about such issue (and how)?

Is there a way to decode the minor_status code received from the underlying mechanism?

Thanks a lot for any help,

Kornel

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
modauthkerb-help mailing list
modauthkerb-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthkerb-help