01-17-2017 07:44 PM
01-17-2017 07:44 PM
01-18-2017 08:00 AM
It seems to be failing for anybody that has upgraded to the latest version on Mac. I did some more research into this today and we have ADFS rules that permit login only from within the network. If I am connected to the internal network I get a blank pop-up from Skype (looks like it's attempting to load a page) and it will spin forever. I decided to pop off the internal network and get on an external and that blank page then refreshes and loads the external ADFS authentication page. It would seem that there's some issue resolving it internally. I may need to check into our DNS.
01-18-2017 08:50 AM
Adding more to this...
I noticed that Safari is asking for a certificate for our internal ADFS. This may be a byproduct of the way we have our stuff set up as FireFox isn't prompting for the same. My presumption is that Skype is using Safari to do the load out and when it's getting the transition of ADFS prompting for a certificate that it's just not painting the page and discarding the prompts. That's likely why the page isn't loading and the client isn't able to log in properly.
I'll have to do some more digging as even changing the default browser on the OS won't get past it. I'm thinking it may be calling it by default. Or I could be chasing ghosts.
01-24-2017 07:39 AM
So I managed to dig deeper on this - I'm not a massive traffic analyzer but I was able to see where things seem to be failing. That same page that loads out as spinning or blank on the internal network paints as the ADFS external login page when off the network. So I set up a trace to watch Skype as it's attempting to log in on the internal network and it's the ADFS response to the internal auth request.
I updated all the way to the latest fast insider build of Office/Skype this morning and it's the same thing. Something within Skype isn't handling that ADFS response in the last few builds. My guess at this point is that I have to open a premier ticket - anyone else seeing this issue at all?
04-25-2017 01:31 AM
We had an issue with S4B on Max OS not signing in. The user experience was a white login box appearing and then nothing else. No errors.
Tried updating Office and installing the March 2017 update for Skype.
Environment is ADFS on Server 2016 with IWA and Forms Based Authentication enabled.
Modern Authentication enabled in both Exchange Online and Skype for Business and no users have MFA enabled.
I think what broke it was adding the User Agent String 'Mozilla/5.0' to my ADFS WIASupportedUserAgents property
The value wasn't detailed enough to cope with non Windows clients and was therefore expecting IWA from the Macs.
Amending the value to 'Mozilla/5.0 (Windows NT)' maintains IWA for Windows platform and FBA for non Windows which resolved the issue.
There are plenty of other variables which could be at play with this issue but this sorted it for me.
The clincher was this excellent article on ADFS, IWA and FBA found here
04-25-2017 07:58 AM
Thanks for your reply!
Around the same time we got response from Microsoft support with a few possible solutions.
We followed the 2nd option as you also did.
Below is teh response we got from Microsoft support:
1. Please enable the password authentication for the intranet will fix this issue.
You can access this by editing the primary authentication policy from the AD FS snapin (under Authentication Policies).
2. Remove Mozilla 5.0 from the supported user agents under ADFS properties
On the primary ADFS server
$WIA = Get-AdfsProperties
Most probably the list of agents will look like this:
Windows Rights Management Client
You can remove the Mozilla 5.0 from the list of supported user agents by running this command on the ADFS server, and not including the Mozzile/5.0:
Set-ADFSProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client")
You can also check this link here:
3. Workaround if you want to keep Mozilla/5.0 between the user agents
If removing the "Mozilla/5.0" does not seem to be a viable solution as you may need it for all users running Firefox or any other browser/software using that agent and that should benefit from WIA and its advantages.
What we've found on our side is more related to the ability of the Mac to get a valid Kerberos ticket in the AD domain prior to open Skype for the first time.
Indeed, we successfully reproduced (and solved) the issue by using a mac not connected to the network at first, then opening a session, get network, then launch Skype => You have the issue as no ticket is listed in the klist (or if you use an account in the MacOS session that is not linked to AD, even if you sign in to Skype with an AD account).
If you open a session on the Mac with network and with a valid AD account, you get a valid ticket and the Skype opens naturally after you provided email+password
06-09-2017 04:17 AM
Microsoft has acknowledged the issue.
Skype for Business on Mac fails to sign-in
(Skype for Business Server Online, Exchange Server Online, Identity managed on-premises with ADFS 3.0 and WIA authentication enabled for wiasupporteduseragents-Mozilla/5.0)