Apache2, Kerberos: gss_accept_sec_context() failed: An unsupported mechanism was requested

I want to use Kerberos and Apache 2 on linux with mod_auth_kerb.

I added .htaccess to my project with following:

#SSLRequireSSL
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd Off
KrbAuthRealms DOMAIN.COM
Krb5KeyTab /etc/httpd/httpd.keytab
KrbLocalUserMapping On
require valid-user

When I tried to test my single sign on on IE or Firefox I get the following error in apache log:

[Thu Jan 19 21:03:27 2012] [error] [client 10.65.0.1] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

I don't know what is it and what I should do to make it work.

My aim is to get REMOTE_USER to be filled by AD user name. But now I can't do anything because of this error...

Solution 1:

In a simple setup, using mod_auth_gssapi and FreeIPA as the krb5 server and to generate keytabs, I found out that adding the following next to the AuthType command addressed the issue.

BrowserMatch Windows gssapi-no-negotiate

Based on the answer from andsens, it seems indeed this is happening on Windows clients that try to use NTLM. GssapiAllowedMech krb5 and GssapiBasicAuthMech krb5 don't give a successful outcome to the negotiation, so the only solution seems to be to disable the negotiation. I cannot guarantee this is accurate, though, but it worked for me.

The corresponding documentation is here

Solution 2:

I have discovered another reason for this error:
Windows tries to authenticate with NTLM. Actually that is the root of the problem.

I don't understand how recreating the keytab helped, the error would then be something along the lines of "Key table entry not found".
Windows tries to authenticate via NTLM when it cannot acquire a ticket from the KDC.
For me, the reason for that was that my server was not located within the same realm. The domain was ad.domain.com, but my server was located at something.domain.com. I am sure you can allow this somehow as well, but the easy fix is simply to change the hostname pointing to the server (and then creating a new keytab for that domain).

Solution 3:

There was problem with principals. I recreated /etc/httpd/httpd.keytab and added HTTP principial correctly and all works fine!