Trouble signing in to Skype for Business

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.
LVL 28
jhyieslaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vasil Michev (MVP)Commented:
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.
jhyieslaAuthor Commented:
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.
Vasil Michev (MVP)Commented:
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.
Starting with Angular 5

Learn the essential features and functions of the popular JavaScript framework for building mobile, desktop and web applications.

jhyieslaAuthor Commented:
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.
jhyieslaAuthor Commented:
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.
jhyieslaAuthor Commented:
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.
jhyieslaAuthor Commented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jhyieslaAuthor Commented:
Figured it out myself.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Office 365

From novice to tech pro — start learning today.