When signing-in to Office Communications Server 2007 using cached Domain Credentials (e.g. you login to your corporate domain-joined laptop at home), Office Communicator 2007 may prompt you with an additional authentication dialog box:
When Office Communicator 2007 signs in, it also attempts to retrieve availability data via Exchange 2007 Web Services. It does so by leveraging the Autodiscover functionality built into olmapi32.dll's HrGetAutoDiscoverXML function.
Communicator will issue SOAP requests (over HTTPS) to the published Autodiscover (*1) server, who returns the URLs for the Microsoft Exchange 2007 Client Access Server(s) that will feed the availability data back to Office Communicator.
The additional prompt for authentication stems from Communicator being hard-wired to authenticate using NTLM. When IIS (on the Exchange 2007 CAS machines) returns it's WWW-Authenticate headers, it does so in the form of:
When Communicator attempts to negotiate authentication using your cached credentials (over the Internet), it will fail with a "401.2 Unauthorized" (*2), and subsequently prompt you for authentication as above. However, if we force NTLM from either the client side or the server side, we eliminate these additional prompts for credentials.
After de-selecting "Enable Integrated Windows Authentication" (*3) in Internet Explorer (Tools, Internet Options, Advanced, scroll down to the "Security" section), you should no longer receive the additional authentication prompt from Office Communicator 2007 (to retrieve availability + out-of-office data via Autodiscover / Exchange Web Services.
This checkbox & the wording is admittedly a bit misleading in that it DOES NOT turn on/off NTLM; it simply controls whether Internet Explorer and the underlying Win32 API will perform security negotiation against IIS (that is Kerberos or NTLM; checkbox enabled), or simply default to NTLM (checkbox disabled).
This is the registry location/value that this checkbox controls:
Data: 0 (Disabled, unchecked in the UI) or 1 (Enabled, checked in the UI); default is Enabled
Essentially, we are instructing IIS on the Exchange 2007 CAS server(s) to offer NTLM as the first authentication provider (with Negotiate as the fallback provider) in the WWW-Authenticate header.
For Internet Information Services 6.0:
1. On the Exchange 2007 CAS machine(s), start -> run -> cmd -> OK. Change to the C:\Inetpub\AdminScripts directory.
2. Execute the commands below ...
a. Inspecting current status:
C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
The parameter "NTAuthenticationProviders" is not set at this node. (*4)
b. Setting the parameter:
C:\Inetpub\AdminScripts>cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders "NTLM,Negotiate"
NTAuthenticationProviders : (STRING) "NTLM,Negotiate"
c. Verifying the output:
3. Restart the IIS Admin Service (which will restart all dependent services) on the Exchange 2007 CAS machine(s).
For Internet Information Services 7.0: (*5)
Lists configurationappcmd list config /section:windowsAuthentication
Removes NegotiateAppcmd.exe set config /section:windowsAuthentication /-providers.[value='Negotiate']
Adds Negotiateappcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+"providers.[value='Negotiate']" /commit:apphost
Here is a list of the results:
C:\Windows\System32\inetsrv>appcmd list config /section:windowsAuthentication<system.webServer> <security> <authentication> <windowsAuthentication enabled="true" useKernelMode="false"> <providers> <add value="Negotiate" /> <add value="NTLM" /> </providers> </windowsAuthentication> </authentication> </security></system.webServer>
C:\Windows\System32\inetsrv>Appcmd.exe set config /section:windowsAuthentication /-providers.[value='Negotiate']
C:\Windows\System32\inetsrv>appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+"providers.[value='Negotiate']" /commit:apphost
C:\Windows\System32\inetsrv>appcmd list config /section:windowsAuthentication<system.webServer> <security> <authentication> <windowsAuthentication enabled="true" useKernelMode="false"> <providers> <add value="NTLM" /> <add value="Negotiate" /> </providers> </windowsAuthentication> </authentication> </security></system.webServer>
Server-side fix (specific to Exchange 2010):
I had a customer report (my sincere thanks, Elan Shudnow!) that their OAB wasn’t working externally. Once they fixed the OAB, the [Communicator Credentials] prompt went away and other users reported it went away for them as well.
(*1) "Overview of the Autodiscover Service"
(*2) “401.2 Denied by Server Configuration”
(*3) “Integrated Windows Authentication (IIS 6.0)”
(*4) This is expected output as per http://support.microsoft.com/kb/215383
(*5) Big thanks to Jason Dozier for the IIS7 instructions
PingBack from http://blog.a-foton.ru/index.php/2008/10/16/why-is-communicator-prompting-me-for-credentials/
Thanks for this - I was looking all over for this solution! I see the Communicator 2007 R2 does not generate the prompt at all, so I guess the authentication has changed somewhat in that release.
I have a client with a similar issue that I managed to duplicate in a lab setup.
Short version is they are using Kerberos Constrained Delegation from ISA to Exchange for Outlook Anywhere with clients authenticating with NTLM via ISA 2006. Works beautifully. Deployed OCS 2007 and the Edge infrastructure and all the features work as expected with one small hiccup - external, domain joined clients repeatedly get prompted to authenticate to Exchange Web Services, but they never can successfully authenticate so there's an auth mismatch at some point. Having trouble figuring out where. Every single component of Exchange works great inside and outside so I know Autodiscover, EWS, UM and OAB are working fine.
Integrated Auth is enabled on the CAS for both the EWS and Autodiscover virtual directories. I've tried flipping Basic auth on both, or just one or the other and unsuccessfully. The client either gets the endless authentication or it just fails altogether without prompting.
My next step would be to try flipping the authentication provider method around as you indicated as the server-side fix. Any potential issues on the Exchange side with that adjustment?
Any other suggestions?
In terms of reversing the WWW-Authenticate headers provided by IIS (via Exchange CAS), our customers have found no ill side effects, and this workaround has been deployed repeatedly.
I hope this resolves your issue, and if not, feel free to contact me (via the contact form), and we'll go from there.
Hi, this server-side fix is setting this on the Exchange CAS. But what about if we have an ISA in between? I have the exact same setup and errors as Tom.
Thansk in advance
Now sure how to make this change in ISA, but you can use a combination of our STRACE and HttpReplay utilities to find how the WWW-Auth header is being received via the client:
Once you install it, open a cmd prompt, change to "C:\Program Files\STRACE" and issue the following command:
withdll /d:STRACE.dll_IE7 "C:\program files\microsoft office communicator\communicator.exe" (or whichever .exe you're trying to trace; but in this case, communicator.exe)
Take the logfile generated by Strace (default: it goes on the Desktop)
Move it to the C:\Program Files\HttpReplay directory
Open a cmd prompt, change to C:\Program Files\HttpReplay
Issue the following command:
Presto! You should have a nice pretty webpage with all the relevant info. :-)
Senior Escalation Engineer
Microsoft, Unified Communications Team
Hi Scott, thanks alot for your quick answer.
Could it complicate things that i run IE8 on Vista SP2_RC? Because strace doesnt seemt to collect any information.
If i do the client-side fix, i don't get thet popup, but rather a "Exchange Connection Error". It can't access the OAB/OOF... but Outlook can, perfectly..
Thanks in advance
I haven't tried Strace/HttpReplay with IE8 + Vista SP2 RC, but I suspect you're correct. Was trying to save you the hassle of breaking out Network Monitor (or Wireshark).
My recommendation is to engage Microsoft Customer Support Services via http://support.microsoft.com & we'll get it figured out. :-)
Nice article. Exactly what i am looking for.. but it's not working for me.
I'm connected by VPN. Opening Outlook 2007 doesn't prompt me anything. Autodiscover service test is Ok.
Oh yeah. OCS is installed on Windows 2008.
Opening communicator asks me for basic authentication window, but the olf fashionned-one (looks like an IIS6 authentication dialog box, not the one you screenshooted).
Tried the strace tool and so one, but really don't get how to use this trace. Can you be any help ?
Thak you ^^ :)
This did not fix my issue. I publish Outlook Anywhere with ISA.
I followed your article, the only thing that is different now is following:
in your example
<windowsAuthentication enabled="true" useKernelMode="false">
Rest of my config
C:\Windows\System32\inetsrv>appcmd list config /section:windowsAuthentication
<add value="NTLM" />
<add value="Negotiate" />
How can I change it ? Everything else is working perfectly. But I still get the Outlook Integration login. Can it be the windowsAuthentication config.
I'd try using Strace & HttpReplay to dig deeper into this:
- Once you install it, open a cmd prompt, change to "C:\Program Files\STRACE" and issue the following command:
withdll /d:STRACE.dll_IE7 "C:\program files\microsoft office communicator\communicator.exe" (or whichever executable you're going to trace)
- Take the logfile generated by Strace (default: it goes on the Desktop)
- Move it to the C:\Program Files\HttpReplay directory
- Open a cmd prompt, change to C:\Program Files\HttpReplay
- Issue the following command:
Hope this helps,
I have the very same problem Tom Pacyk had, with domain joined clients (using KCD via ISA, which work fine), and non domain joined clients all via ISA, but I've not been able to resolve the problem at all.
What im getting is that when I open communicator client, it fires the login for the mailbox, followed by an autodiscover prompt. When I look the report generated by srace/htpreply, I see that the client is tryingto mame a post to https://autodiscover.domainname/autodiscover/autodiscover.xml. Autodiscover is published via ISA, and if I open Outlook, everything appears to work ok (out of office etc).
I also tried the netiotation methods in IIS (NTLM, negotiate, mentioned at he top of the article), but no luck there at all. After some very late nights, I'm at my wits end with it, and am close to having to raise a call with Microsft, but wanted tp post here first to see if anyone had any other ideas.
Whatever logs need to be posted here, i'll gladly supply.
Hope you can help!
Unfortuantely, the scenario I debugged did not involve ISA (and nor do I claim to be an ISA expert by any means); I think we definitely need to fully understand & resolve this "twist" on the issue, as many customers seem to be hitting the same problem.
My recommendation is to engage Microsoft Customer Support Services (http://support.microsoft.com), cite this blog entry, and we'll help figure this one out. I'll be out of the office (actually, out of the country!) all next week ... going onsite to debug a customer issue, but we have a very talented team in Unified Communications Support that shold be able to help nail this one.
Microsoft, Unified Communications Group
Okay...MOC 2007 R2 connecting to Exchange 2007 running on Server 2008 x64 (IIS7). All is well except for this "Exchange Connection" issue. I implemented your client side fix and voila! Problem Solved. I then reverted that back (cause who wants a client side solution?) and then implemented the server side fix and...fail. I still get the same behavior as before. I even did an iisreset just to be certain. Still no love. Any ideas?
Are you running straight IIS7, or do you also have IIS6 compatibility installed as well? I may have more testing to do w/straight IIS7 ...