mod_auth_kerb: gss_accept_sec_context() failed
Michael Ströder
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)
Any clue here? Many thanks in advance.
Ciao, Michael.
Andrew Cobaugh
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."
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
--andy
Michael Ströder
> On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder <mic...@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.
How can I gather more debug log messages?
> 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!
Ciao, Michael.
Andrew Cobaugh
> Andrew Cobaugh wrote:
>> On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder <mic...@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
Michael Ströder
> Andrew Cobaugh wrote:
>> On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder <mic...@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.
>
> How can I gather more debug log messages?
Well, I set LogLevel debug in httpd.conf now and got the following
messages in Apache's error_log:
------------------------------ snip ------------------------------
[debug] src/mod_auth_kerb.c(1635): [client 10.1.1.5]
kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1635): [client 10.1.1.5]
kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1247): [client 10.1.1.5] Acquiring creds for
HTTP/nb2.stroe...@DOM2.ADTEST.LOCAL
[debug] src/mod_auth_kerb.c(1392): [client 10.1.1.5] Verifying client
data using KRB5 GSS-API
[debug] src/mod_auth_kerb.c(1408): [client 10.1.1.5] Client didn't
delegate us their credential
[debug] src/mod_auth_kerb.c(1108): [client 10.1.1.5] GSS-API
major_status:000d0000, minor_status:96c73a1f
[error] [client 10.1.1.5] gss_accept_sec_context() failed: Unspecified
GSS failure. Minor code may provide more information (, Decrypt
integrity check failed)
------------------------------ snip ------------------------------
Hmm...
>> 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!
I've applied this patch.
Ciao, Michael.
Michael B Allen
> [debug] src/mod_auth_kerb.c(1247): [client 10.1.1.5] Acquiring creds for
> HTTP/nb2.stroe...@DOM2.ADTEST.LOCAL
> [debug] src/mod_auth_kerb.c(1392): [client 10.1.1.5] Verifying client
> data using KRB5 GSS-API
> [debug] src/mod_auth_kerb.c(1408): [client 10.1.1.5] Client didn't
> delegate us their credential
> [debug] src/mod_auth_kerb.c(1108): [client 10.1.1.5] GSS-API
> major_status:000d0000, minor_status:96c73a1f
> [error] [client 10.1.1.5] gss_accept_sec_context() failed: Unspecified
> GSS failure. Minor code may provide more information (, Decrypt
> integrity check failed)
The "Decrypt integrity check failed" error means that the GSS service
located an entry in the keytab file with the target SPN but the
encryption key, key version number or encryption type was not exactly
the same as that used to encrypt the service ticket.
If this error occurs while you're trying to install or update the HTTP
service account, it's a good bet that the cause is an old cached HTTP
service ticket on the client. Meaning the cached ticket was encrypted
with an old encryption key, key version number, encryption type
combination. To fix this problem, you simply need to purge your client
credential cache (such as by logging off and back on) or wait long
enough for the ticket to expire. That will force the client to
reacquire a new ticket generated with the most current encryption key,
key version number and encryption type.
One tool that is helpful with examining your client credential cache
and with purging tickets is the kerbtray.exe utility from the Resource
Kit Tools package available through MS' website. Run kerbtray.exe and
then right click on it's bright green systray icon and select "purge
tickets". Whenever you run ktpass it's usually a good idea to purge
your client's tickets.
If this does not solve your problem then you should run ktpass again
and note the encryption key and key version number (the encryption
type should be the default which is RC4). Then recopy the keytab and
verify with ktutil that the encryption key and key version number are
in fact correct.
To get delegation to work with Firefox, you must go into about:config
and add the servername or domain name to
network.negotiate-auth.delegation-uris property.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/