Apache SSPI authentication domain issue

nbyinfrastructure
nbyinfrastructure used Ask the Experts™
on
Hi all

I've revised the below after more testing today.

I'm using Apache 2.2.6 on a Windows 2003 Server, and am authenticating users with mod_auth_sspi 1.0.4 for certain parts of our intranet site. I'm simply requiring them to provide valid AD credentials so we can grab things like their user name and email address.

When I visit http://server/dev/, SSPI works perfectly, seemlessly authenticating IE users, and providing a login box for users on Firefox. However, when I visit http://server.uk.domain.com/dev/ (giving the FQDN of the Apache server) SSPI gives a login box even on IE, and users have to login with their full domain and user name rather than just the user name.

Is there any way to get SSPI to ignore the domain OF THE SERVER? It's as if it's wanting the domain "uk.domain.com", whereas the client is proving UK\username. SSPIOmitDomain seems to omit the domain from the resulting server variables, rather than ignoring it altogether.

Any help would be much appreciated!

The relevant setup in my apache.conf is:

<VirtualHost *:80>
ServerName server.uk.domain.com
ServerAlias server
....
</VirtualHost>

<LocationMatch "/dev/">
    Allow from all
    order allow,deny
    AuthName "Windows Passthrough"
    AuthType SSPI
    SSPIAuth On
    SSPIAuthoritative On
    SSPIOfferBasic Off
    SSPIDomain uk.domain.com
    Require valid-user
    Satisfy Any
</LocationMatch>
...
</VirtualHost>

Any ideas where I'm going wrong?

Many thanks

Laurence
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
OK, we found the answer through a combination of packet sniffing and lateral thinking! Thought I'd post the solution because more googling shows that other people are falling into the same trap as me.

A Wireshark Capture showed that the issue wasn't at the Apache end, it was at the client end. Apache was sending an identical Authentication Failed (401) response. In the first case (http://server/) the client was responding with an NTLM negotiation. In the second case (http://server.uk.domain.com) the client was simply accepting the 401 response.

We spotted that IE was identifying server.uk.domain.com as being in the Internet zone rather than correctly placing it in the Intranet zone. Therefore the security settings were preventing it from authenticating via NTML or SSPI. If you add the domain into the Intranet Sites list, voila seamless authentication.

A bit of googling shows that while many people have this issue, noone seems to have a good answer (in fact I found an MSDN blog which suggested that Microsoft err on the side of caution with detection). I think the tack we're going to take is to specify the Intranet sites list via a GPO.

Hope this helps somebody!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial