Win2003 KDC -- Apache/mod_spnego on Solaris: "Decrypt integri ty c heck failed"

[BERG Dietmar]

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