Win2003 KDC -- Apache/mod_spnego on Solaris: "Decrypt integri ty c heck failed"
BERG Dietmar
dietmar.berg at alcatel.at
Mon Jul 5 10:55:19 EDT 2004
Thanks, that *is* the solution.
Everything *looked* all right, but wasn't until I changed the password. What fooled me was that the extracted keytab worked; when you extract it using KTPASS.EXE you supply the password, so Windows *can* generate a DES key for the keytab, but does not feed it back to the KDC.
Thanks for your help,
Dietmar
-----Original Message-----
From: Markus Moeller [mailto:huaraz at moeller.plus.com]
Sent: Montag, 05. Juli 2004 01:29
To: kerberos at mit.edu
Subject: Re: Win2003 KDC -- Apache/mod_spnego on Solaris: "Decrypt integrity c heck failed"
Dietmar,
I think as you mention, that you have to change ones the password and then extract the keytab. Windows default is rc4-hmac and aftere setting the DES flag you have to change the password so that Windows can create a DES key.
Regards
Markus
"BERG Dietmar" <dietmar.berg at alcatel.at> wrote in message news:DF27CDCBD2581D4B88431901094E4B4D0154AEEB at attmsx1.aut.alcatel.at...
> Hi all,
>
> I got stuck trying to get Apache 1.3.31 with mod_spnego to work with a
Windows 2003 Server-based AD.
>
> The SPNEGO token received from the client (IE 6.0SP1) is passed to
> krb5,
but it can't be properly decoded by it.
> I've hacked the krb5 libs to produce some more debug output, but I
> simply
don't see what might be wrong.
>
> The same error also occurs with mod_gss_auth_krb5
>
> My environment:
> - OS is Solaris 8 on Sparc
> - MIT krb5 is version 1.3.4
> - Apache is 1.3.31, mod_perl-enabled
> - mod_spnego is 0.0.4, mod_gss_auth_krb5 is 0.0.3
>
> - the user-account in AD has a simple name, with an SPN of
HTTP/some.where at REALM;
> account options have the DES-flag set (is there a need for a
password-change *after* this?)
>
> - KTPASS on Windows has been used to extract keytabs for both the
> plain
user-name and the service principal name
>
> - I can successfully log on from Solaris with MIT kinit with both the
> user
name and the SPN,
> but I can *only* log on through the keytab for the user account,
> *not*
for the service principal
> (same phenomenon as someone else on this list had with Samba)
>
> - the Ticket encoding is DES-CBC-MD5 (at least this is what KERBTRAY
> on
the Windows side says)
>
> Logging output:
> mod_spnego: gss_acquire_cred succeeded
> krb5_kt_get_entry(req->ticket->server=HTTP/some.where at REALM, vno=0,
> enc=3) krb5_kt_get_entry OK
> krb5_c_decrypt() FAILED with -1765328353
> krb5_rd_req FAILED
> mod_spnego: released credential
> mod_spnego: gss_accept_sec_context failed; GSS-API: Miscellaneous
> failure
> mod_spnego: gss_accept_sec_context failed; GSS-API mechanism: Decrypt
integrity check failed
>
>
> What has gone wrong???
>
> Best regards,
> Dietmar
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
More information about the Kerberos
mailing list