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

Question

Goal: Hybrid Setup with Office 365, no p/w in cloud. Status. Set up (w/Big IP APM) and works great except for thick clients. Does the most recent iApp for ADFS or iApp for office 365 allow thick clients to authenticate, or is the iApp for ADFS at the point where it can replace ADFS (and not just ADFS proxy) ? Or if must be done manually, is there guidance for what info the big ip needs from O365 and what O365 is looking for from Big IP (and where to enter this config info)?

lucas_thompson_ · Answer

Yes, this solution is fully supported using Office 365 thick client apps and APM as SAML IdP, so it's not necessary to transmit your AD user passwords to Microsoft.&nbsp;
This post has more information:&nbsp;
https://devcentral.f5.com/questions/office-365s-new-quotmodern-auth-quot&nbsp;

dkemper_258780 · Answer

cool- by which means? iApp for O365, iApp for ADFS, or manual configuration? &nbsp;
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? &nbsp;

michael_koyfma1 · Answer

Please see this article on Microsoft's website: https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/&nbsp;
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.&nbsp;
Please review and let us know what other questions you might have.  Thanks.&nbsp;

dkemper_258780 · Answer

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. &nbsp;
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.&nbsp;

terrence · Answer

dkemper,&nbsp;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.&nbsp;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.&nbsp;

Forum Discussion

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

Recent Discussions

Different SNAT for each member in the pool

Best practice to protect OWA

Unable to create F5 in AWS via CFT - no internet access

Cookie not RFC-compliant - Cookie has no value

How to lift the connection limit for a given IP address ？

Related Content

F5 Hybrid Security Architectures: One WAF Engine, Total Flexibility (Intro)

Fingerprinting TLS Clients with JA4 on F5 BIG-IP

HTTPS Routing based on Client Certificates values with F5 Distributed Cloud

iRule based RADIUS Client Stack

Enhance your Application Security using Client-side signals