Exchange needs your credentials RRS feed

  • Question

  • We have a problem with Skype for Business 2016 client. It is asking for Exchange credentials. We see the message on a domain joined machines running externally (outside of the office) when the VPN is NOT used. When the domain user is on a VPN connection (at home) everything is OK and there is NO exchange credentials prompt. After OS reboot, when the domain user logs into his laptop OS (domain joined, with cached credentials) at home and he is NOT using VPN, Exchange needs your credentials message appears in the Skype client.

    Environment (static data :))
    Client side is Windows 10 (and Win7 SP1), Outlook 2016, Skype for Business 2016, computer is domain joined.
    Another important thing is that there are NO credentials in a Windows OS (Control Panel) Credential Manager under Generic Credentials
    In Skype client configuration information, Exchange URLs are OK. EWS Information is EWS Status OK. But UCS Connectivity State is Exchange connection DOWN.
    We see this when we HAVE Exchange credentials message.

    Server side is Exchange 2013 and Skype for Business Server 2015 with configured integration between them. Only Unified Contact Store feature is used. We are NOT using Exchange Unified Messaging and Outlook Web App feature. SMTP and SIP domains are the same.

    Troubleshooting details (moving parts :))
    After weeks of troubleshooting, reading dozens of articles (with comments!), level 400 client sign-in deep dives and checking again configuration of Exchange, Skype server and Windows client and trying different settings, issue is narrowed down to NTLM over HTTPS authentication from the client side. What I see now in a Fiddler trace on a client side is that the Skype client is requesting from EWS (https://mail.domain.com/ews/exchange.asmx) a lot of things like GetUnifiedGroupsSettings (remember that one), ConvertId, FindFolder, GetImItemList, GetFolder, FindItem, SyncFolderItems and Subscribe in a dozens of XML messages. Most of them are rejected by EWS with result 401 anonymous request disallowed. Some of them are answered with 200 OK. One of them (GetUnifiedGroupsSettings) results with 500 Internal Server Error (XML RequestServerVersion Version = ”Exchange2015”, XML response ErrorInvalidServerVersion). Now, when I look for the Authentication part in each message (not in 200 results) I DO SEE NTLM challenge/response with the correct domain user and pass, but ONLY for the first request GetUnifiedGroupsSettings answered with 500 result. In all the other 401 results Skype client is not even trying to send NTLM Authorization Header with Negotiation type.

    Is it possible that the Skype client does NOT know a logged on user and pass (cached)?

    If I just open Exchange credentials prompt and hit cancel Skype client WILL authenticate to https://mail.domain.com/rpc/rpcproxy.dll?... with correct user, but the Outlook integration ERROR still remains.
    If I type in the user and pass in Exchange credentials prompt (for retrieving calendar data from Outlook) and do NOT hit save everything will be OK. The data will start flowing.
    If I type in the user and pass in Exchange credentials prompt and hit Save my password everything will also be OK and those credentials will be saved in Credential Manager under Generic Credentials. That operation will create another problem in the future, because, when the domain password is changed Generic Credentials will NOT be updated with new password and Skype client will use that saved (cred man) outdated password for Exchange authentication (EWS will start responding with 401 unauthorized and Exchange Security log will show Failed log on with bad password reason).

    I somehow believe that Skype client have enough data in order to authenticate to EWS so users do not experience Exchange credential prompt. For GetUnifiedGroupsSettings request Skype was able to authenticate with correct user and pass. Another argument is the Outlook client. Outlook is able to authenticate without prompts. Maybe he is keeping user and pass in the local Outlook profile. Why is Skype client not using existing credentials (from security hive or LSASS) for subsequent authentication to EWS? (just the first request) I know he is using TLS-DSK with Web Ticket Service for Skype server. Can we use TLS-DSK on Exchange server?

    • Edited by kleutd Friday, June 24, 2016 8:48 AM
    Thursday, June 23, 2016 11:17 AM

All replies

  • If this promp only appear without vpn, which External Connection do you use to Access the Exchange Server?

    Maybe some problems with the Communication from External to youe Exchange Services.

    Have you try to start outlook before you start SFB from External?

    regards Holger Technical Specialist UC

    Thursday, June 23, 2016 10:25 PM
  • Not sure if I understand the question. Windows clients (when they are at home and not using vpn) are accessing Exchange server through regular public access. Outlook and Skype client are establishing HTTPS connection with Autodiscover and EWS sites.

    Yes, I tried to start Outlook before SfB. No change. Same problem (Exchange needs your credentials).

    Keep in mind that everything is working, even externally (no vpn), if I type in credentials in the SfB client Exchange credentials prompt. I just think SfB client should not ask me (end user) to do that. Outlook is not asking anything. End user experience must be better in SfB client. And if the end user types in the user and pass he will definitely have more issues in the future and probably a help desk call also. Not to mention that same SfB client was crashing number of times during the testing. Deleting SfB end user local profile solves that problem.

    • Edited by kleutd Monday, June 27, 2016 10:32 AM
    Friday, June 24, 2016 8:47 AM
  • Hello kleutd,


    Sorry to hear your current experience with SFB but I am sure everything will run smoothly after the issue is fixed.


    According to the symptom, it looks like the auth request is not able to send to the server to due to Network issues. I’d like to ask:


    1. Whether  the problematic clients have run any hard coded route entries.
    2. Is there any proxy settings or programs running on the client.
    3. When the issue occurs, does Outlook run properly without credential windows and Free/busy information can be display without problem?
    4. Does it work on a non-domain joined machine?


    In most cases, we can first take a try of the following solution:




    Simon Wu
    TechNet Community Support

    • Marked as answer by Niko.Cheng Monday, July 11, 2016 4:46 AM
    • Unmarked as answer by kleutd Friday, July 22, 2016 12:04 PM
    Thursday, June 30, 2016 11:42 AM
  • Thank you for your reply

    1. No. They do not have hard coded route entries.

    2. No. There are no proxy settings. We are not using any kind of proxy service

    3. Yes! :) That is the point! Outlook can authenticate to EWS but SfB client can NOT!

    4. On a non domain joined machines it is working. Those machines ARE using CredMan to store password.

    I see the KB article. It is not solving the problem. Mainly because we don't have a problem with CredMan. If we select to save the Exchange user and pass in SfB client, credentials will be saved. But, we don't want to go that way in the first place. It will generate more problems in the future (explained above, help desk support calls because of outdated password saved in CredMan).

    We want SfB client to authenticate to EWS seamlessly with domain user credentials given during Windows OS log on.

    Friday, July 22, 2016 12:55 PM
  • I'm running in similar issue. did you got the solution for your issue. Could you please share some details?
    Tuesday, October 11, 2016 3:51 AM
  • Are you using a F5 APM for your external webmail?  

    In your fiddler trace did what response did you get for the 401 WWW-Authenticate = basic?  

    Thursday, October 13, 2016 5:09 AM
  • We are having this issue too, and we are behind an F5.

    We're getting this response from the server:

    WWW-Authenticate: Basic realm="autodiscover.ourdomain.com"
    WWW-Authenticate: NTLM
    WWW-Authenticate: Negotiate

    Then communication stops, unless we provide a password. This is a domain joined computer. When we type in our credentials, the following request is sent:

    Authorization: Negotiate <Base-64 string>

    This results in a 200 response, and it works again.

    Thursday, October 13, 2016 7:48 AM
  • Hi Tommy,

    It appears that the deployment guide has been updated and you will require a irule. It was working for us but the behavior must have changed after a Lync/Exchange patching.  

    See pg 76 subheading: Lync clients cannot connect or receive authentication prompts when accessing Microsoft Exchange Autodiscover and EWS through F5 APM


    The irule fixed our issue.

    • Edited by Josh Bines Wednesday, October 19, 2016 12:49 AM
    • Proposed as answer by Josh Bines Wednesday, October 19, 2016 12:52 AM
    Wednesday, October 19, 2016 12:48 AM