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…
Best Answer
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.