Fedora2/Apache2 and Key Version Error

[Scott Moseman]

Cleared my tickets (had some old ones) and tried it all over again.
I get this ticket in the kerbtray with this format...

krbtgt/REALM at REALM
Client Name smoseman at REALM
Service Name krbtgt/REALM at REALM
Target Name krbtgt/REALM at REALM

I can login using the username/password prompt and nothing is
changed in the kerytray after successfully logging in through that.

But Apache2 is still giving us the same error messages as before.

PS- Should we assume that mod_auth_kerb on Apache2 is going
to allow us to do SSO without requiring the username/password?
Some responses I found give me the impression that this it not true
and we need to use something like mod_spnego instead.

Thanks,
Scott Moseman


""Nebergall, Christopher"" <cneberg at sandia.gov> wrote:
>
> You can use ethereal a packet sniffer.
>
> http://www.ethereal.com/
>
> But that is not your problem, from your error messages Apache it is
sending
> the header fine. The problem occurs later when the web server is trying to
> process the token sent from the browser.
>
> gss_accept_sec_context() failed: Miscellaneous failure
> > (Key version number for principal in key table is incorrect)
>
> The key in your keytab file does not match the key that the Active
Directory
> has for the server principal or you have changed the key multiple times
> recently IE is using an older version of the key which it will cache till
it
> expires.
>
> But that is confusing when looking at the next message, which makes it
> appear as if the browser was not able to get a service ticket all.
>
> >>Warning: received token seems to be NTLM, which isn't supported...
> >>gss_accept_sec_context() failed: A token was invalid (Token header is
> >>malformed or corrupt)
>
> Run the kerbtray utility from Microsoft to make sure that IE is actually
> getting a service ticket.  Then right click the tray icon and purge the
> tickets, in case your windows box has cached an old ticket.  If that
doesn't
> fix any thing, recreate your keytab using ktutil.
>
> Kerbtray link
>
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/kerbtray
> -o.asp
>
> -Christopher
>
>
> -----Original Message-----
> From: Scott Moseman [mailto:smoseman at novolink.net]
> Sent: Wednesday, August 25, 2004 1:39 PM
> To: kerberos at MIT.EDU
> Subject: Re: Fedora2/Apache2 and Key Version Error
>
> As of right now, this is what our Apache server is saying in the logs...
>
> kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> Acquiring creds for HTTP/fqdn.domain.com at REALM
> Verifying client data using KRB5 GSS-API
> Verification returned code 589824
> Warning: received token seems to be NTLM, which isn't supported...
> gss_accept_sec_context() failed: A token was invalid (Token header is
> malformed or corrupt)
> kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> kerb_authenticate_user_krb5pwd ret=0 user=username at REALM authtype=Basic
>
> We are assuming that our browser (IE60) is not sending Apache2 our
username
> and password credentials via Kerberos.  Is there any way that we could
> validate
> that Apache2 is properly requesting "WWW-Authentication: Negotiate" from
the
> web browser?  I did a telnet to port 80 and used "GET /" but that did not
> tell me
> anything about Negotiate, although I am not sure if I used the right
syntax
> though.
>
> Thanks,
> Scott Moseman
>
>
> "Scott Moseman" <smoseman at novolink.net> wrote:
> >
> > Fedora Core 2 running Apache 2.0.50 using mod_auth_kerb-rc6.
> > Setup Kerberos and made principals for the system and for Apache.
> >
> > Login (pam) access using Kerberos is working great.  No problem.
> > kinit works and authenticates against the ADS.  No problem there.
> >
> > When my browser hits the Apache server, I get this error message:
> >
> > gss_accept_sec_context() failed: Miscellaneous failure
> > (Key version number for principal in key table is incorrect)
> >
> > The website pops up the user/pass prompt (which we want to stop)
> > and I am able to login with my ADS credentials okay.  No problem.
> >
> > Any idea what is causing the above error message in Apache's logs?
> > I have a feeling this is what is stopping us from having SSO working.
> > (The website is in my Intranet Sites and I do have IWA configured.)
> >
> > Thanks,
> > Scott Moseman
> >