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)