Forum Discussion

oschistad_69492's avatar
oschistad_69492
Icon for Nimbostratus rankNimbostratus
Aug 03, 2015

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_111's avatar
    mikeshimkus_111
    Historic 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"?

     

  • 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" 
              }
            }
       }