F5 in front of ADFS - only Android does not work

  • 84 Views
  • Last Post 21 March 2017
Parzival posted this 16 March 2017

Hi everyone, 


I hope someone can help me with some problem I have at a customer.. basically the customer has ADFS (2012R2) behind F5… they need that to support SSO to ALL their apps (including SAP, etc etc..)..[and yes we know its unsupported]

 

The problem is.. that the config works for iPhone and computer browsers and Windows Phone.. but it does not for Android.. we did a capture and found that there is a difference on the URL’s accessed..

 

IPhone/others uses always

                /adfs/ls/?login_hint=t717979%40ti

 

Android goes into:

/adfs/ls/wia?client-request-id=c

 

Now.. we are wondering why it would go to adfs/ls/wia?  


and hope you can tell me …. So we might be able to figure out a way to make it work.. 


any hints/tips?

Order By: Standard | Newest | Votes
bdesmond posted this 16 March 2017

Is the Android sending a user agent that AD FS thinks supports WIA?



 



Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132



 

show

joe posted this 16 March 2017

Yes, so it sounds like you are using the feature in ADFS to steer different browsers to WIA based on user agent. Our org uses that but in a very special way that is tightly controlled. If you have it configured such that it matches something that the Android browser is sending, you'll get an inappropriate login behavior for that browser.
The way we use this is that we only steer domain-joined Windows machines to WIA and only if they are using IE or Chrome (we don't yet support Edge). To make this happen in IE, we use GPO to push our a special user agent string value via IE settings. For Chrome, we have a custom extension we developed (also pushed out via GPO) that does the same thing for hosts matching our service URL. This way, we only get the WIA behavior for a fairly narrow set of possible browsers (although it makes up most of our traffic since most of our users use that narrow set of browsers).
If this F5 VIP is public facing, you might also want to be careful about using WIA on the public internet as you might not get the behavior you want with Kerberos for clients coming in from the outside.
Maybe show us how you have that policy configured in ADFS and also show us what the user agent value for the Android client is from your traces.
Joe K.


show

Parzival posted this 17 March 2017

Hi, 




Thanks so much for all the help already.. 




we are using a default install of ADFS, when we publish directly (ssl tunnel) everything works, but as soon as we put pre-auth on on the F5, things break.. 




Looking at the headers we see: 






Received User-Agent header: Mozilla%2f5.0%20(Linux%3b%20Android%206.0.1%3b%20SM-A710F%20Build%2fMMB29K%3b%20wv)%20AppleWebKit%2f537.36%20(KHTML%2c%20like%20Gecko)%20Version%2f4.0%20Chrome%2f56.0.2924.87%20Mobile%20Safari%2f537.36%20PKeyAuth%2f1.0.

 

versus: 

Received User-Agent header: Mozilla%2f5.0%20(iPhone%3b%20CPU%20iPhone%20OS%201021%20like%20Mac%20OS%20X)%20AppleWebKit%2f602.4.6%20(KHTML%2c%20like%20Gecko)%20Mobile%2f14D27.




The PKeyAuth in the Android seems to force it to use PKAP instead of SSL/TLS.. .. but not sure why ADFS direct would not have a problem with it.. while using F5 pre-auth does... 




Roelf






show

argofgarcia posted this 17 March 2017

https://blogs.technet.microsoft.com/enterprisemobility/2016/12/07/introducing-azuread-pass-through-authentication-and-seamless-single-sign-on/
On Mar 17, 2017 01:07, "Roelf Zomerman" <rzomerman@xxxxxxxxxxxxxxxx> wrote:














Hi, 




Thanks so much for all the help already.. 




we are using a default install of ADFS, when we publish directly (ssl tunnel) everything works, but as soon as we put pre-auth on on the F5, things break.. 




Looking at the headers we see: 






Received User-Agent header: Mozilla%2f5.0%20(Linux%3b%20Android%206.0.1%3b%20SM-A710F%20Build%2fMMB29K%3b%20wv)%20AppleWebKit%2f537.36%20(KHTML%2c%20like%20Gecko)%20Version%2f4.0%20Chrome%2f56.0.2924.87%20Mobile%20Safari%2f537.36%20PKeyAuth%2f1.0.

 

versus: 

Received User-Agent header: Mozilla%2f5.0%20(iPhone%3b%20CPU%20iPhone%20OS%201021%20like%20Mac%20OS%20X)%20AppleWebKit%2f602.4.6%20(KHTML%2c%20like%20Gecko)%20Mobile%2f14D27.




The PKeyAuth in the Android seems to force it to use PKAP instead of SSL/TLS.. .. but not sure why ADFS direct would not have a problem with it.. while using F5 pre-auth does... 




Roelf






show

Parzival posted this 21 March 2017

Hi everyone,




a small update..




@Ray, thanks for the passthrough hint, but that does not really help in my SSO scenario where external users need to be able to login to the F5 and use the same session for internal applications as well as Office 365 resources.






It seems its harder than it looks to get F5 to work in front of ADFS in general.. and the iApp they published does not support the MSADFSPIP protocol (although they say it does.. it actually doesn't.. it just injects HTTP Headers).






So we managed to get it working half-half.. regular browsers will use F5's capability to perform NTLM authentications towards the ADFS server itself, while phone apps will use a special iApp that performs a forms-based login to the ADFS form (as they are

treated as external devices by ADFS itself). In some cases we need to inject the HTTP headers anyway (so F5 is sort of seen as the proxy), in other cases we need to remove headers to make it work for Android.. anyways.. still work in progress and testing..

more to follow..




To be fair; MS does not support any non-ADFSPIP supported proxy in front of ADFS.









show

Close