Scott Oseychik

Microsoft | Embedded Escalation Engineer | Exchange People Groups Team

Why is Communicator prompting me for credentials?

Why is Communicator prompting me for credentials?

Rate This
  • Comments 42

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"

http://technet.microsoft.com/en-us/library/bb124251.aspx

 

(*2) “401.2 Denied by Server Configuration”

http://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO_Diagnose_IIS_401_Access_Denied.aspx

 

(*3) “Integrated Windows Authentication (IIS 6.0)”

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true

 

(*4) This is expected output as per http://support.microsoft.com/kb/215383

 

(*5) Big thanks to Jason Dozier for the IIS7 instructions 

 

Comments
  • 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.

    Thanks again!

  • 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?

  • 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 Oseychik

  • 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:

    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 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)

    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 Files\HttpReplay directory

    Open a cmd prompt, change to C:\Program Files\HttpReplay

    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 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

  • 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 Oseychik

  • Hi

    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 ^^ :)

  • 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:\Windows\System32\inetsrv>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.

    Christian

  • I'd try using Strace & HttpReplay to dig deeper into this:

    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 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)

    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 Files\HttpReplay directory

    - Open a cmd prompt, change to C:\Program Files\HttpReplay

    - 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

  • 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!

    Thanks

  • Hi Tony,

    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.

    Regards,

    Scott Oseychik

    Senior Escalation Engineer

    Microsoft, Unified Communications Group

  • 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,

    John

  • 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 Oseychik

Page 1 of 3 (42 items) 123
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post