Office 365 Hybrid "thick" clients, totally replace ADFS (not just ADFS Proxy)

cool- by which means? iApp for O365, iApp for ADFS, or manual configuration?

btw, if O365 already configured for 'normal' office apps, e.g. word and web, but not with 'thick apps' like SFB, then are there perhaps only a few settings to adjust/add?

Please see this article on Microsoft's website: https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/

The gist is - if you are using a version of Microsoft application that supports Modern Authentication, as outlined in that article, then you can use F5 to completely replace ADFS.

Please review and let us know what other questions you might have. Thanks.

Right, cool. I got the gist. I've learned in the interim that neither the adfs iApp nor the O365 iApp will get me all the way there (no "Easy-Button"), BUT that a manually coded policy will be able to do that once I figure it out. We already have one that works for all office, it's now a matter of technique-- and terms. e.g. Microsoft refers to a mexurl and I think they really mean metadata url. It's also not perfectly clear where I get the appropriate mexurl from and where I need to input that data.

I'm thinking that I might be able only to modify the existing policy that lets all other office apps and IE work with O365, but not sure where to start.

dkemper,

I am not sure at what point you are in your deployment, but I am in a similar situation. We are in the midst of deploying APM to work as WAP for adfs. Any apps which use "Modern Authentication" prompt the end user for credentials twice(1 for apm, and 1 for adfs). I attempted to work around this with an irule/client initiated form based SSO.

when ACCESS_ACL_ALLOWED {
   /**More Code**/
    if { ([string tolower [URI::query [HTTP::uri] wauth]] contains "microsoft")  } {
           log local0. "wauth: [HTTP::header Content-Length] [HTTP::method] [HTTP::uri]"
           WEBSSO::select [set foo /Common/adfs_form_based_sso]
    }
}

From my investigation, only form authentication is permitted when the uri contains wauth=. This is a very crude rule. My only remaining issue is the Client initiated SSO isnt working.

As it happens, the magic that my teammates had built into the F5 APM module for Office 365 SAML SSO worked just fine for Word, Excel, etc. to log into the Office 365 tenant with SSO, but Skype for Business was still a holdout. Two checks:

1. Is the "Enhanced Client or Proxy Profile" checked? Required for Modern Authorization. Yes. All good.
2. Is modern authorization turned on in the Office 365 cloud? [It was assumed, but in fact, it had not been turned on.

Fixing item 2 brought our SFB clients that are homed in cloud to life. Still some cleanup, that was our basic gist.

Will check with team to see what to post/not post about the config that was already in place.

No ADFS at all.

I would really love to see the magic sauce that you are currently using, as any app that is using ADAL is not working for us, due to the multiple login screens.

Terry, I think we may be mixing up two topics here. The original topic of this thread was about replacing ADFS with APM - and that part works great for ADAL-enabled applications(as well as ActiveSync traffic). You are trying to deploy APM as a WAP/ADFS proxy, which is a bit of a different setup.

Please open an a ticket with F5 support on it, and let me know the number via private message, and I will ensure it gets handled/routed properly. Currently, the deployment guide only covers SSO into ADFS using NTLM. Do you have a need to specifically support forms-based authentication method to ADFS. Our deployment guide exposes forms on the front-end and does NTLM SSO between APM and ADFS.

I'm also in te proces of setting up an BIG-IP to fully replace an ADFS server. And it seems to work fine (SSO). But we have an issue with the Office365 thick client. It prompts every time for 'license activation'. Then the user has to enter his e-mail address and the activation is completed. But since this is a VDI environment, the shared license information is not persistent.

We tried to validate our configuration using the office365 SSO connectivity tester (https://testconnectivity.microsoft.com/) , but I don't know how reliable this test is. It fails with the following message:

 The Metadata Exchange URL in the domain registration isn't valid. URL:

It is set within Azure (metadataExchangeUri) and points to the BIG-IP, but it seems the MEXURL isn't send by Azure. It shows .

So any hints on this one? What can you tell me about the connectivity checker?