Users are being asked for credentials after applying KB3114351 or KB3114502


It’s ‘reverse engineering’ time, install/remove updates and work for MSFT for free… again.


So… after you applied the KB3114351 -security update for Lync 2013 (Skype for Business): December 8, 2015- or the KB3114502 – January 12, 2016, update for Lync 2013 (Skype for Business) some (if not all) of your users will start complaining that the SfB Client is asking for credentials at startup.

The main clue that something is wrong is when you see the username filled with SIP address (picture on the right) and you know that is not the correct user’s AD login and the user was never asked before for credentials because the client should use the Windows domain logon credentials.


KB3114351 and KB3114502 changed the Client Sign-in algorithm and some particular deployment scenarios were not tested (check ‘affected scenarios’ below).

By using an issue-free client connected on the internal LAN (this is important later), when the client starts six  new (there are more) registry key appear:
The bottom one WindowsAccountSipUri came quickly to my attention. “Goggle-fu” didn’t help too much (if MS is reading this: why KB only refers to issues fixed/new but rarely mentions changes on behavior? why a “security update” includes new features?), and after an overnight of tests here’s how the new updates changed the client logon process:
1. At startup if the registry key ServerSipUri has an address, the client will query the active directory for the user’s SIP address and write it on the WindowsAccountSipUri.
2. If both keys match, the client will use the Windows domain user credentials to sign-in (and no one complains about it anymore).
3. If both keys don’t match, it will popup the password prompt for the user. If the user sip address doesn’t match the Active Directory, doesn’t matter if the user put the wrong or right password. The client will fill the username with the SIP address (and also the ServerUsername key). At this point you are screwed up and you need to help.
4. If the user is a ‘techie’ he might know how to manually set the right username and password and will not call you, BUT if he didn’t check the ‘save password’ it will be prompted for credentials the next logon time, and again… and then it will call you 🙂

Before those updates the SfB Client would attempt to logon the sip username with the Windows credentials. Only if they failed it would popup for different credentials.


Based on the point 3: When both keys don’t match?
> When the client cannot get any SIP address of the user from AD. Then it doesn’t have a value for WindowsAccountSipUri (and to match with the ServerSipUri)

(Here’s where you can confirm if you are affected)
When the Client cannot get the SIP address from AD?:(A) When the client starts (after the patching) accessing remotely from the Internet
(B) When you have a Lync resource forest topology deployment and your user forest doesn’t contain any msRTCSIP-PrimaryUserAddress AD  field (or not have a value)
(C) isn’t the previous one also similar to Office365 with ADFS deployment?

SOLUTION (or workarounds)

(all) clear the registry key ServerUsername if doesn’t match the user’s UPN on AD. Or replace with the NTLM (domain\username), it might solve another additional issue reported that the SfB client prompting for Exchange credentials

(A) if the user can connect to office (go onsite or use a VPN),  and restart the client. As soon as the WindowsAccountSipUri has the SIP address, you will not see the issue (i hope!)

(B) manually configure the username, password and check ‘save password’ box (probably fixes temporarily) and wait for the official MSFT February update

(C) manually add the WindowsAccountSipUri with the sip address of the user if you are sure that it’s your scenario.


Although extensive I didn’t perform all imaginable scenarios. There might (and I saw) be some other conditions or the engine client that will not expose the issue. Here’s some discoveries:

The WindowsAccountSipUri value is not validated once it is created. On a simple Lync server deployment:
1. Login with a user.
2. Change the users SIP address on Lync server
3. If you try to sign-in on the same SfB client, you will not be able to login with the new sipaddress (even with the correct username/password) or will experience the issue. The workaround is to delete/fix that registry key (or delete the windows local user profile).

Another way to have the issue using scenario (B) above:
1. login with a user for on a workstation (the idea is have new userprofile)
2. start SfB, fill the sip username and single sign-on will  work (no username/credentials asked)
3. all next sign-ins SfB will prompt for credentials (except if you click on ‘save password’ option)

8 thoughts on “Users are being asked for credentials after applying KB3114351 or KB3114502

    • LuisR 05/02/2016 / 16:59

      Glad I could help.
      The issue only came to my awareness this week, since customers skipped Dec2015 and only deployed Jan2016 now.

      if the workaround suits you, I would advice to carefully deploy that “feb2016” update.
      Microsoft has been making some significant changes on the client on the last 4 months (I will post more about it) and this has not been the only issue I’ve found.

      Feel free to drop a visit to my blog 😉

  1. MrGenius 05/02/2016 / 14:05

    For me Solution C worked! Thanks a lot.

    • LuisR 05/02/2016 / 16:48

      Glad I could help.
      All feedback to my blog is welcome and confirm that it’s visible 😉

  2. Chris Krafcky 17/03/2016 / 22:12

    Hello. I’m very new to the SFB realm so forgive my ignorance. We are experiencing this problem in our environment, but I’m not sure where the 2 referenced updates would have been applied. Would the updates have been applied at the server level? If so, which one? Front End? Edge? I’ve looked on all of them, but I don’t see them there. Since the last reply in early February, has there been any changes that I should be aware of? Any help that you can supply would be greatly appreciated.

    – Chris

    • LuisR 17/03/2016 / 22:15

      All the updates mentioned are for the client.
      You can try to apply the Feb2016 release but it might not solve

  3. Mike H 12/04/2017 / 14:34

    Thanks for the registry info. I found that when you are prompted for the Windows Account, it is CASE SENSITIVE and needs to be entered exactly as the WindowsAccountSipUri is entered.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.