Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I've been trying to figure this out off and on for a few days now, and I think I just have a fundamental lack of understanding :)

I have Apache2 running in a windows environment serving up our company intranet. I'd like to be able to pass through the windows authenticated user so that I'm able to use it on the PHP side. At the moment, it's sort of working.

If I set up a virtual host that resolves directly to the server name, everything works as expected if I browse to http:// webserver

<VirtualHost *:80>
   DocumentRoot "C:/www/test/public"
   ServerName WEBSERVER

   <Directory "C:/www/test/public">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all

    AuthName "Test"
    AuthType SSPI   
    SSPIAuth On
    SSPIAuthoritative On
    SSPIOmitDomain On

    SSPIUsernameCase Upper
    SSPIPackage NTLM
    SSPIPerRequestAuth on

    require valid-user
 </Directory>
</VirtualHost>

In this case, WEBSERVER is the name of the actual machine in the domain that hosts our internal sites.

If I use an alias that resolves to WEBSERVER, I get the prompt that asks me for my user/pass (which successfully validates if I provide the correct details).

This example generates the prompt if I browse to http:// sub.internaldomain.com, where sub.domain.com resolves to WEBSERVER:

<VirtualHost *:80>
   DocumentRoot "C:/www/test2/public"
   ServerName sub.internaldomain.com

   <Directory "C:/www/test2/public">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all

    AuthName "Test2"
    AuthType SSPI   
    SSPIAuth On
    SSPIAuthoritative On
    SSPIOmitDomain On

    SSPIUsernameCase Upper
    SSPIPackage NTLM
    SSPIPerRequestAuth on

    require valid-user
 </Directory>
</VirtualHost>

Both tests are bare bones Zend Framework applications that are just trying to dump out $_SERVER. The first example above gives me the correct REMOTE_USER value while the second example has it if I enter in a valid user/pass on the prompt (or not at all if I remove the valid-user requirement).

Any thoughts??

share|improve this question
add comment

migrated from stackoverflow.com Apr 6 '13 at 14:28

This question came from our site for professional and enthusiast programmers.

2 Answers

You didn't mention it anywhere, but you are using IE, along with NTLM SSO. IE only engages in automatic NTLM handshakes with sites that it deems to be in the Intranet Zone. Otherwise it will throw the popup prompt to explicitly ask for credentials. (Even in the Trusted Zone)

So the question is, how does it know a site is in the intranet? Well, first, if you use a short name like in your first example (no dots), it assumes it is in the intranet and it can be resolved using the DNS suffix search list. It will also look-up the explicitly added list of sites in various Zones at the Local Machine and User levels. There are further heuristics that it uses to detect the intranet, based on proxy configuration etc. if you have "Automatically Detect Intranet" option checked. But in your case I am surprised that your default corp AD domain wasn't already added to the Intranet Zone. If this is the case then using the FQDN of your host WEBSERVER.internaldomain.com would also have resulted in the prompt. Not anymore though, since you already added *.internaldomain.com to the Intranet Zone.

It doesn't have anything to do with the resolved IP, this all happens before the DNS resolver. In fact, I think IE considers all IPs to be non-intranet unless otherwise specified. I mean if you were to use the IP in the URL, it would prompt.

Also note that Firefox doesn't do any such automatic intranet detection. It just relies on an explicit list of sites that you specify manually in network.negotiate-auth.trusted-uris. It will only trust those for automatic NTLM SSO. You would need to use a customized user.js or Mozilla.cfg file to achieve the same results as you got with a GPO for IE.

share|improve this answer
add comment

I just thought I'd post the solution I found for completeness in case anyone else runs into this.

I simply had to include *.internaldomain.com to the list of trusted intranet sites within the browser (we just pushed a policy change). For whatever reason, even though that domain resolves to an internal IP address it wasn't being recognized as such.

Everything is working as expected now!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.