Why is Communicator prompting me for credentials?
Summary:
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:
Details:
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:
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
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.
Client-side fix:
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:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Name: EnableNegotiate
Type: REG_DWORD
Data: 0 (Disabled, unchecked in the UI) or 1 (Enabled, checked in the UI); default is Enabled
Server-side fix:
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"
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
NTAuthenticationProviders : (STRING) "NTLM,Negotiate"
c. Verifying the output:
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.
NTAuthenticationProviders : (STRING) "NTLM,Negotiate"
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 configuration
appcmd list config /section:windowsAuthentication
Removes Negotiate
Appcmd.exe set config /section:windowsAuthentication /-providers.[value='Negotiate']
Adds Negotiate
appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+"providers.[value='Negotiate']" /commit:apphost
Lists configuration
appcmd list config /section:windowsAuthentication
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.
References:
(*1) "Overview of the Autodiscover Service"
https://technet.microsoft.com/en-us/library/bb124251.aspx
(*2) “401.2 Denied by Server Configuration”
https://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO\_Diagnose\_IIS\_401\_Access\_Denied.aspx
(*3) “Integrated Windows Authentication (IIS 6.0)”
(*4) This is expected output as per https://support.microsoft.com/kb/215383
(*5) Big thanks to Jason Dozier for the IIS7 instructions
Comments
Anonymous
October 16, 2008
PingBack from http://blog.a-foton.ru/index.php/2008/10/16/why-is-communicator-prompting-me-for-credentials/Anonymous
February 04, 2009
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. Thanks again!Anonymous
February 17, 2009
The comment has been removedAnonymous
February 18, 2009
Hi Tom, 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. Scott OseychikAnonymous
March 11, 2009
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 advanceAnonymous
March 12, 2009
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: Strace: http://www.microsoft.com/downloads/details.aspx?familyid=f5ec767f-27f2-4fb3-90a5-4bf0d5f4810a&displaylang=en Once you install it, open a cmd prompt, change to "C:Program FilesSTRACE" and issue the following command: withdll /d:STRACE.dll_IE7 "C:program filesmicrosoft office communicatorcommunicator.exe" (or whichever .exe you're trying to trace; but in this case, communicator.exe) HttpReplay: http://www.microsoft.com/downloads/details.aspx?familyid=d25ba362-c17b-4d80-a677-1faff862e629&displaylang=en Take the logfile generated by Strace (default: it goes on the Desktop) Move it to the C:Program FilesHttpReplay directory Open a cmd prompt, change to C:Program FilesHttpReplay Issue the following command: Httpreplay <yourfilenamehere.log> Presto! You should have a nice pretty webpage with all the relevant info. :-) -- Scott Oseychik Senior Escalation Engineer Microsoft, Unified Communications TeamAnonymous
March 12, 2009
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 advanceAnonymous
March 13, 2009
Hi Henry, 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. :-) Regards, Scott OseychikAnonymous
March 23, 2009
The comment has been removedAnonymous
May 19, 2009
Hi, 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: <windowsAuthentication enabled="false"> in your example <windowsAuthentication enabled="true" useKernelMode="false"> Rest of my config C:WindowsSystem32inetsrv>appcmd list config /section:windowsAuthentication <system.webServer> <security> <authentication> <windowsAuthentication enabled="false"> <providers> <add value="NTLM" /> <add value="Negotiate" /> </providers> </windowsAuthentication> </authentication> </security> </system.webServer> How can I change it ? Everything else is working perfectly. But I still get the Outlook Integration login. Can it be the windowsAuthentication config. ChristianAnonymous
May 20, 2009
I'd try using Strace & HttpReplay to dig deeper into this: Strace:
- Once you install it, open a cmd prompt, change to "C:Program FilesSTRACE" and issue the following command: withdll /d:STRACE.dll_IE7 "C:program filesmicrosoft office communicatorcommunicator.exe" (or whichever executable you're going to trace) HttpReplay:
- Take the logfile generated by Strace (default: it goes on the Desktop)
- Move it to the C:Program FilesHttpReplay directory
- Open a cmd prompt, change to C:Program FilesHttpReplay
- Issue the following command: Httpreplay <yourfilenamehere.log> Presto! You should have a nice pretty webpage with all the relevant info. :-) Hope this helps, Scott Oseychik
Anonymous
May 21, 2009
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! ThanksAnonymous
May 22, 2009
The comment has been removedAnonymous
July 01, 2009
Scott, 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? Thanks, JohnAnonymous
July 01, 2009
Hi John, 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 ... Thanks, Scott OseychikAnonymous
July 07, 2009
The comment has been removedAnonymous
July 07, 2009
joho0: Great work!! Please contact me via http://blogs.msdn.com/scottos/contact.aspx ... I'd like to discuss further. Thanks, Scott OseychikAnonymous
July 07, 2009
Sure thing Scott. I just wanted to point out one huge error with my previous post. Everywhere I mention NTLM, just go ahead and substitute Kerberos. I know this is contrary to what you stated in your post, but my experience has been that NTLM is failing for unknown reasons and that only by fixing Kerberos (with the SPN entries in AD) was I able to resolve this issue. I know this to be true, and it took a few minutes to dawn on me, because Kerberos uses SPNs and NTLM doesn't, and that's the only thing I changed. That would explain why forcing NTLM by switching off negotiate on the server side offered no help. Not sure why turning off negotiate on the client side caused NTLM to work all of a sudden. This may be a clue, as there are still some unknowns at work here, but I've verified this solution on some other domain pcs, so I'm not going to worry much about the NTLM issue.Anonymous
February 12, 2010
We were having the same problems in our environment. We had tried the client side fix and it solved the issue. The server side fix did not solve the problem. John0's comment got me to looking at our SPN configurations. We have NLB on for our CAS servers and an alias (webmail) pointing to the CAS NLB address. I looked for the SPN entries for each host that participates in the NLB and found that only one (cashub01) had an entry for the HTTP/ SPN. I added HTTP/webmail.mydomain.com for the second server (cashub02) and the problem was fixed. Thanks to everyone contributing on this thread.Anonymous
February 18, 2010
We attempted the client side fix, however all intranet and SSO pages now failed to load. Haven't attempted the server side fix yet, will report back when we do.Anonymous
April 06, 2010
The comment has been removedAnonymous
April 06, 2010
The comment has been removedAnonymous
April 23, 2010
Scott, I have a similar, but possibly different problem. I have a non-domain joined computer accessing Exchange with Outlook 2007 and Communicator 2007 using my username. I get constant prompts for credentials when signed into Communicator, tried the client-side fix you suggested and it did not work. The popup says "Connect to webmail.[domain].com" in the header and "Connecting to autodiscover.[domain].com" and provides my username and blank password. Entering my password does not login and I have to cancel the prompt.Anonymous
April 23, 2010
The comment has been removedAnonymous
May 03, 2010
Mike, you can do pre-auth with ISA through KCD with a few more hotfixes and changes. See my post from last year for more details: http://www.confusedamused.com/notebook/office-communicator-outlook-integration-error-problems-when-using-isa-2006-and-exchange-kerberos-constrained-delegation/Anonymous
May 03, 2010
Awesome to see the community experts helping each other! Thanks for the tip, Tom! Regards, Scott OseychikAnonymous
June 04, 2010
We are using OCs 2007r2 and ISA for external AB. The setspn command from joho0 fixed our problem company wide. ThanksAnonymous
June 24, 2010
- Windows Auth is intended to work only in INTRANET environment and it is not designed for internet
- Secondly "NTLM,Negotiate" id not valid entry Possible value are: "Negotiate,NTLM" OR none (default) "NTLM"
Anonymous
August 02, 2010
Hi Scott, Thanks for the article. as previosuly mentioned this doesnt solve the issue when isa is deployed as reverse proxy. However theres another perfect artcle that describes how to overcome that issue. www.confusedamused.com/.../office-communicator-outlook-integration-error-problems-when-using-isa-2006-and-exchange-kerberos-constrained-delegation My question is if the resolution applies for TMG aswell or how can i find out about it.Anonymous
August 02, 2010
The comment has been removedAnonymous
August 09, 2010
The comment has been removedAnonymous
October 12, 2010
I'd like to add my two cents on this issue. I did the recommendation you posted but my issue was not resolved. The difference is that I'm utilizing 2 CAS servers behind an F5 load balancer. The comments in this post can be misleading for people in my shoes so I hope people read to the end and find my warnings :) So people recommend using setspn to add a service principal name for the cas server to help fix the autodiscover prompting. Do NOT do this in a load balanced situation as you can only have one spn per account in AD otherwise duplicates defeat the purpose of having the spn (to uniquely locate a service in AD for kerberos authentication). If you do want kerberos you need to setup a shared service account to use via this complicated procedure: technet.microsoft.com/.../ff808312.aspx To fix this in a cas array where you are not implementing kerberos for autodiscover and web services MAKE SURE TO DELETE ALL HTTP SPNs. If an HTTP spn is showing when you run setspn -L <servername> then just go ahead and remove it, (setspn -D http/autodiscover.contoso.com casservername). Yup remove them all. Then things will start to use NTLM authentication instead of trying Kerberos and giving annoying autodiscover prompts. Hope this helps someone as I never ran across this in any deployment documentation from either F5 or Microsoft or anyone else. Zach http://the-little-things.net/Anonymous
October 12, 2010
@Zach, Thank you VERY MUCH for your detailed post here! I'm sure it'll help others out ... much appreciated! Regards, Scott OseychikAnonymous
May 18, 2011
Interested to know if this case is also valid when using Lync (srv+client)+e2010? Anyone seen this when using Lync. I'm but can it be the same case. -Timo-Anonymous
May 20, 2011
Greetings. I applied the settings above to no avial. I followed this article: blogs.technet.com/.../default-authentication-settings-exchange-2007-2010-iis-application-virtual-directories.aspx And found I had digest authentication enabled on EWS, and not just windows authentication. Once I cleared it and reset IIS my lync clients are no longer prompting for authentication. Hope that helps someone!Anonymous
May 20, 2011
Thanks for the feedback, Gerhard! Hope others find your findings helpful, also! Regards Scott OseychikAnonymous
August 19, 2011
I'm still facing the issue with the credentials for calendar retrival. I have done the changes on the server. We are running with Exchange 2010 and Lync 2010 as well OCS2007 r2..can some one share your thoughtsAnonymous
August 22, 2011
Hi Saamee, If all the obvious things have been tried already (including some of the valuable additions that others have left here in the comments), my recommendation would be to formally engage Microsoft Customer Support Services so we may resolve this issue with you. Regards, Scott OseychikAnonymous
December 14, 2011
Scott i just changed the EWS providers to NTLM and now i'm not getting prompted for the "Retriving data from Calendar" ....Hipp Hipp hooorreyyy...Good article regards SaameeAnonymous
December 15, 2011
Glad the workaround resolved your issue, Saamee! Regards, Scott OseychikAnonymous
December 18, 2011
I'm getting the prompt however changing the setting within ie isn't helping. HTTPreplay is telling me i'm getting 401 on the EWS address. I'm using TMG to publish EWS/Exchange and ISA in another site which is doing the traffic routing to OCS. If I use a hosts file to point the EWS address (same cname as exchange proxy server addr) from the TMG publishing rule to the 2010 CAS I get no integration errors. Any ideas? -chrisAnonymous
January 15, 2012
The comment has been removed