Forum Discussion
APM as IdP for Office 365, with IP filtering
We are investigating our options in how to best secure an Office 365 tenant against unlimited access to mailboxes etc from unsecured devices.
Since the device management extensions are not available in the legacy outlook protocols, we probably need to use IP filtering and restrict access to these interfaces to our corporate IP ranges.
And since IP filtering is not a part of the service, we need to use the "ADFS hack" that seems to be the common practice.
However, if possible we would like to avoid the actual product ADFS and instead use the builtin IdP in F5 APM to do the necessary checking. This builds no extra infrastructure and reduces solution complexity.
But this is only possible if F5 APM is able to see, and inspect, the X-MS headers supplied by Microsofts service. Specifically we need to check the x-ms-forwarded-client-ip and x-ms-client-application claims.
Is this possible using only F5 APM? And are there any customer examples of companies doing something similar?
3 Replies
- mikeshimkus_111Historic F5 Account
Hi, if you simply want to drop traffic based on those header values, I think you should be able to use an iRule to do this. Can you post a link to the "ADFS hack"?
- oschistad_69492
Nimbostratus
This is a fairly thorough walkthrough of how to do it using ADFS:
http://blogs.technet.com/b/askds/archive/2012/06/26/an-adfs-claims-rules-adventure.aspx
A full more official Microsoft description of how ADFS works to create these access policies are here:
https://technet.microsoft.com/en-us/library/Hh526961%28v=WS.10%29.aspx
In that article, the values of various headers that Microsoft sends are described towards the end.
Keep in mind that your APM(or ADFS, the underlying technology does not matter here) needs to be externally reachable for the ActiveSync/OutlookAnywhere clients to get the assertion. There are probably a number of ways to tackle this issue with APM - but can definitely be done to suite your needs.
One way is to write an iRule that will check client IP's origin to see if it comes from internal network - if not, check the required headers. It would look something like this(not tested) - assumes that all internal space you have is 10.0.0.0/8, all else is external, and 222.222.222.222 is the external IP address of your firewall that Office 365 will see when people try to get to it from behind corporate firewall:
when HTTP_REQUEST { if { not [IP::addr [IP::client_addr]/8 equals 10.0.0.0] } { if { [HTTP::header exists X-MS-Client-Application] and [HTTP::header exists X-MS-Forwarded-Client] } { if { not [IP::addr [HTTP::header X-MS-Forwarded-Client] equals 222.222.222.222 } { HTTP::respond 401 content "Not Authorized" } } }
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com