We help IT Professionals succeed at work.

Trouble signing in to Skype for Business

jhyiesla asked
We are converting from Exchange and Office on-premise to Office 365.

We're in a pilot testing mode at the moment. We are having an issue with Skype for Business. It started showing up on our virtual desktops (VMware view NP desktops), but we've also seen it on regular computer desktops as well.

For the VDI, I went to my master and logged in as an administrator and then signed on to the Office 365 portal as an E1 user.  E1 is a license category that has no access to locally installed copies of Office, except for SfB. I downloaded and installed Skype.  Then I built a test pool of virtual desktops.  

If I log onto the desktop as a non-converted user (the same administrator I used for configuring the desktop), when SfB starts up I enter in the user name of a valid E1 user and I am prompted for his password and he gains full access to SfB. However, if I log in as an already converted user, SfB will make an attempt to automatically log in using the email address of the E1 or E3 user, and I am never prompted for password, and the login fails with an error about some DNS setting.  Obviously the DNS error message is not valid as if there was a true DNS issue, I'd see it on all users.

I've discovered this as well on my computer.  I am an E3 user who is allowed to have Office on my computer.  If I log on as me, I am automatically logged into SfB, it doesn't ask for my password and the login is successful. However, if I switch users and log on as another test E1 user, I get the same thing that happens with the VDI desktops.

I do not see any place within SfB that I can force it to prompt for credentials. We are currently a hybrid Exchange environment and have an ADFS server, ADConnect server and WAP server on premise.

I am assuming that there is some permissions setting or authentication setting somewhere in the environment that might address this without screwing up something else, but I can't find it. I have looked at this article: https://support.office.com/en-us/article/Using-Office-365-modern-authentication-with-Office-clients-776c0036-66fd-41cb-8928-5495c0f9168a, but I'm not sure that's the answer.  

Any guidance is appreciated.
Watch Question

Most Valuable Expert 2015
Distinguished Expert 2019

What do you mean by "converted user", one migrted to O365? If so, what type of migration did you perform? Did you license the users for SfB Online as well? Did you have Lync/SfB on-prem prior to that?

The SfB client will use the SIP address to populate the initial logon window, if the SIP doesnt match the UPN, you will have to manually change it.
Yes, by converted user, I mean one that we've migrated to O365. All E1 and E3 user are licensed for SfB and I have set the appropriate license within the O365 portal.

We did not have any sync or Skype on premise.
Most Valuable Expert 2015
Distinguished Expert 2019

So start by checking if their SIP addresses match the UPN. If they didnt have SIP addresses previously, they're most likely provisioned based on the value of the "mail" attribute, and might not match the UPN.
All of the VDI desktops will have the same user as the installer since I'll be creating the masters.  
Regardless of SIP or email name as UPN, I'd think there would be an option to force it to ask for password.

For example, on the master, I logged into that machine as the administrator who is NOT an O365 user. When I log into a virtual desktop as that guy, I can log into SfB as several E1 or E3 users and it always prompts me for password and it always works.

So it seems more like some authentication issue and If I could get it to always prompt for password it seems it should work.
Some additional info.

I opened a VDI desktop in the vSphere client so that I could log off and on as different users without losing the desktop.  I logged in as a cloud user and installed SfB.  After doing that I tried logging into SfB as that user and it worked just fine. I was not prompted for a PW so it looks like SSO is working for Skype.  Then I logged out of the desktop and in as another cloud user.  I then tried logging into SfB and it failed with the DNS message that I'm used to seeing... which from my perspective is fake since if DNS was truly an issue the first guy would not have been able to connect.

So it appears that there is a correlation between the user who installed SfB and the one logging in...to a point. If I log in as a non-cloud user, it's like SfB attempts to use the SSO, but can't so it defaults to asking for a PW... entering the PW works. However, if I'm logged in as a cloud user, but NOT the one who installed SfB, the SSO thing dies because it can't rectify the installer and the one signing on, but since SSO ought to work it just dies.

Our preferred solution would be for SSO to work and let whoever is signing onto the computer, regardless of whether they set it up or not, be able to sign into SfB without being prompted for PW.  A workable, but less friendly solution would be for SfB to always prompt for PW if the SSO fails instead of just crapping out with the DNS error message.
I ended up putting in the DNS entires that the KB article suggested, both in my internal DNS as well as the external DNS.  Now the message I get is that the server can't be contacted.  However, that's not really true because it works as long as I am logged in as the user who installed SfB on that desktop.
Turns out that the solution was the web filtering appliance we are using. I did some further testing and discovered that if I authenticated thru the appliance before attempting to connect to SfB it works just fine.  Also discovered that to get this to work really well, I actually need to exit the SfB app and restart it and then login works.
Figured it out myself.