mod_auth_kerb: gss_accept_sec_context() failed

[Andrew Cobaugh]

On Mon, Jan 19, 2009 at 11:32 AM, Michael Ströder <michael at stroeder.com> wrote:
> Andrew Cobaugh wrote:
>> On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder <michael at stroeder.com> wrote:
>>> HI!
>>>
>>> I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for
>>> SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to
>>> receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP
>>> SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly
>>> initialized.
>>>
>>> The web browser is Seamonkey and it already sends the
>>> Authorization: Negotiate YIIE0AYGKwYBBQ[..]
>>> in the HTTP request.
>>>
>>> But it does not work. I don't get authorized HTTP access.
>>> In Apache's error_log I find:
>>> gss_accept_sec_context() failed: Unspecified GSS failure.  Minor
>>> code may provide more information (, Decrypt integrity check failed)
>>
>> Are you sure that the keytab specified by Krb5Keytab is consistent
>> with the HTTP service principal that is in AD? That message is the
>> same as saying "your password is wrong."
>
> Yes, I'm pretty sure. Krb5Keytab points to the file I've extracted with
> ktpass.exe and the command-line tool 'strings' extracts the right
> Kerberos realm, "HTTP" and fully-qualified domain name of the server.

Look at the ktutil command. That's the proper way to inspect a keytab.
You'll want to make sure the key version number (kvno) is the same as
what's in AD.

Actually, one simple way to test that the keytab is valid is to do
something like:

kinit -k -t /path/to/keytab HTTP/<your server's fqdn>

It might also help to know what types of keys are associated with that
principal. You can do that by looking at the output of "klist -e"
after performing the kinit command above (assuming it succeeds).

> How can I gather more debug log messages?

Set "LogLevel debug" in httpd.conf

It also might be helpful to look at your Active Directory server logs
to see what principal apache is trying to use. It might be that it's
requesting something other than HTTP/<fqdn>.

>> Also, if you're going to use mod_auth_kerb to do GSS, you'll need a
>> patch so that mod_auth_kerb sets up the GSS environment correclty, so
>> that your application will use the correct KRB5CCNAME:
>>
>> http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch
>
> Many thanks for this information!

Also, just to clarify, that's only if you're doing SPNEGO. I had the
same problem trying to do SPNEGO to allow IMP to connect to an IMAP
server using GSSAPI (through php's imap_open() function). Perhaps I
should prod the developers to actually add in the call to
gss_krb5_ccache_name()....

--andy