This is a discussion on Re: Access problem Apache/mod_auth_kerb/AD - Kerberos ; Hi Florian I had the same problem. There is an error in mod_auth_kerb when using the system SPNEGO. You have to use the mod_auth_kerb internal SPNEGO. I was testing on RHEL5 and had to recompile with internal SPNEGO and it ...
I had the same problem. There is an error in mod_auth_kerb when using
the system SPNEGO. You have to use the mod_auth_kerb internal SPNEGO.
I was testing on RHEL5 and had to recompile with internal SPNEGO and it
On Wed, 2007-11-21 at 14:36 +0100, Florian Dautermann wrote:
> I have a the following problem:
> Our KDC is a Windows 2003 AD Server with address "company.corp"
> which is also the name of the domain. We have an Apache
> Webserver running on an OpenSuse with mod_auth_kerb (5.3).
> Its name is "department.location.company.corp". It has a
> valid keytab file (for
> HTTPfirstname.lastname@example.org) with
> which it can get tickets. The WebServer is accessed via "http://department.location.company.corp:1081/site".
> Some hosts can access the WebServer correctly.
> The other hosts who cannot access the WebServer are
> Windows XP Pro machines, hooked into the domain with a
> domain user logged on. Access is not possible via: IE6,
> IE7, Mozilla despite correct configuration (Integrated
> Windows Authentication is on, correct zone is set...).
> Access is possible via the following ways: running the
> browsers explicitly as the users domain account; using
> MIT Kerberos for Windows in combination with mozilla
> (switching network.auth.use-sspi to false). Kerbtray
> shows a TGT in the MSLSA cache.
> In case of a failure, Apache log shows that the client
> is sending an NTLM token. Network sniffers show, that
> there is no communication between the client and the KDC.
> One really funny thing about the whole thing is that
> the error appears exclusively if the user is in the local
> Administrators group. (User logs on; it is working; user
> is granted administrative rights; logs off and on again;
> it does not work). Removing the user from Administrator
> group again afterwards does not solve the problem.
> I guess somehow the Microsoft SSPI is the problem, but
> I do not know how to fix it.
> Any ideas or thoughts are appreciated.
> Kerberos mailing list Kerberos@mit.edu
Med Venlig Hilsen / Kind Regards
Ørholmgade 6 st tv
Copenhagen N 2200