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)

9 Replies

Recent Discussions

Issue on license renewal

Maximum throughput of f5 ltm

iRule cookie persistence and pool redirect

redirect not working

Access azure app service using f5 LTM

Related Content

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

Fingerprinting TLS Clients with JA4 on F5 BIG-IP

Enhance your Application Security using Client-side signals

iRule based RADIUS Client Stack

total-client-side-conns & total-server-side-conns