Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm having issues accessing Exchange WebDav / OWA from any machine but the IIS & Exchange server.

We've got a small development domain running Windows 2003. One server (which we'll call IIS_box) runs IIS and Exchange 2003. The IIS_Box has Outlook Web Access setup on an /Exchange/ virtual directory, permissions deny anonymous users and both basic authentication and integrated windows authentication are enabled.

On IIS_Box, accessing http://IIS_Box.ourDomain.net/Exchange/ presents users with the OWA application without prompting for a username/password. However, going to http://IIS_Box/Exchange/ the user is presented with a username/password dialog.

If the user does not enter and username and password they recieve a 401.2 Unauthorized: Access denied due to server configuration error. If the user attempts to enter a username and password, they get a 401.1 Unauthorized: Access is denied due to invalid credentials.

From any other machine, the user is presented with the username/password dialog and gets the 401 errors whether they use the FQDN or just the bare server name.

Anyone have any idea what the problem is and how we fix it?

EDIT:

Following on from Jeff's answer below, the clients are using IE7.

On IIS_Box, adding the non-FQDN URL to the "intranet" zone on IIS_Box allows that one to work. Fantastic!

However, adding both plain and FQDN URLs to the "intranet" zone on the other machines doesn't. The URLs are now shown as "Local Intranet" but I'm still getting Basic Auth prompts and the 401 errors.

If I go into the client IE settings, under Advanced..Security, if I DISABLE "Enable Integrated Windows Authentication" it all works fine (if it's in the intranet zone). I didn't have to turn off this setting on IIS_Box!

However, it only works fine within IE, not in code using the WebDAV interface - I've tried running/debugging in Visual Studio and as a compiled/stand-alone executable. Arrghh!

EDIT 2:

After some digging, it appears that "Enable Integrated Windows Authentication" actually enables negiotiating between Kerberos and NTLM (in IE7 at least).

With it disabled, NTLM is used.
With it enabled, Kerberos or NTLM is negoitated. If Kerberos is not supported NTLM is used. If it is supported but fails, NTLM is not used.

Thus, I'm off to see if we have underlying Kerberos issues...

share|improve this question

2 Answers 2

What web browser? I know on IE, the rules about what is "intranet" and therefore what will be allowed to send NTLM auth to the webserver are quite byzantine.

Basically, I suspect client browser configuration particularly if the browser is IE. The browser has to believe that the URL is blessed "intranet" to send NTLM credentials at all; if it thinks the URL is not intranet, it won't even try to send NTLM auth.

share|improve this answer
    
Browser is IE7. Adding the non-FQDN URL to the "intranet" zone on IIS_Box allows that one to work. Fantastic! However, adding bnoth plain and FQDN URLs to the "intranet" zone another machine doesn't :( - they are now shown as "Local Intranet" but I'm still getting Basic Auth prompts and the 401 errors. –  Grhm Feb 18 '10 at 11:19
    
OK. Going into the client IE settings. Under Advanced..Security, if I DISABLE "Enable Integrated Windows Authentication" it all works fine (if it's in the intranet zone). Why DISABLING means that NTLM works i don't know, but it works in IE - but not in code running in Visual Studio using the WebDAV interface. –  Grhm Feb 18 '10 at 12:24
up vote 0 down vote accepted

Turns out I had two issues.

  1. The website was not recognised as an "Intranet Site" and hence it probably wasn't attempting Kerberos/NTLM auth at all.

  2. We were having Kerberos errors behind the scenes. I was accessing IIS_Box and the eventlog had errors with a KRB_AP_ER_MODIFIED message about host/IIS_Box.ourDomain.net not matching HTTP/IIS_Box.ourDomain.net.

The first issue was fixed following Jeff's suggestion - thanks.
The second was sorted by running the follwoing command on the domain controller:
    setspn -A HTTP/IIS_Box.ourDomain.net IIS_Box

I'm posting this resolution in case anyone else has similar issues and finds this question. (I hate finding loads of people have had the same problem as me, but not being able to find how they fixed it.)

share|improve this answer

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.