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:[EMAIL PROTECTED] Sent: Montag, 05. Juli 2004 01:29 To: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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/[EMAIL PROTECTED]; > 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/[EMAIL PROTECTED], 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 [EMAIL PROTECTED] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
