Wondering if you guys could help as I'm stuck!

I have configured ADFS for authentication for our Office 365 tenant in order to provide us with the ability to prevent access to all of Office 365 based on IP address so that staff can only connect to O365 if they are in the office or on the VPN. The exception to this is ActiveSync, which I have configured an exception on.

I have the following ADFS claim rule in place which should ensure that if a request comes in via the web application proxy (ie, external connection) and ActiveSync or Autodiscover aren't the applications used and their client IP is not one of our office IPs, issue a deny:

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.Autodiscover"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "ipregexhere"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

However, I've noticed that staff are able to connect to Outlook from outside of the network (ie at home/airports etc) without connecting to the VPN. This shouldn't be possible as ADFS has a rule in place.

Can anyone help me figure out why staff are able to connect from outside the network still? I have a feeling its related to our recent change from Office 2013 Standard MSI to Office 365 Pro Plus C2R which uses Modern Authentication but I’m banging my head against a wall!

  • I don't have an answer - can you run Fiddler and see what traffic an Outlook client is generating while off-network and see what it's sending to ADFS? – mfinni Feb 28 '18 at 23:42
  • @mfinni Using Fiddler I can't see any connections to ADFS. I've done some more reading and think it is due to using Outlook 2016 with Modern Authentication. Apparently, all ADAL-enabled clients will use the passive endpoint (/adfs/ls) and do not pass the x-ms-client-application claim. In my environment we have a mix of Office 2016 (ADAL enabled) and Office 2013 (Legacy/Non-ADAL) and so I believe my above rule works for Legacy but not Modern Auth. I'm unsure how to include this in my rules michev.info/Blog/Post/1289/… – Joe129 Mar 1 '18 at 20:01
  • Gave an answer I found below, can't vouch for the accuracy personally. Can I ask why you're trying to accomplish this though? – mfinni Mar 1 '18 at 20:55
  • @mfinni Azure AD Conditional Access is what I originally suggested to the decision makers, but due to ADFS not requiring a cost (other than licensing which is already covered in our datacentre hyper-v host) and Azure AD Conditional Access requiring AAD Premium licenses, we went with ADFS. The goal is to eliminate the risk of someone being able to install O365 Pro Plus via the portal and setup Outlook access on a non-controlled device which we can't ensure is safe. – Joe129 Mar 1 '18 at 21:11

This post indicates that the only way to do this is with Azure AD Conditional Access - which is what we're doing to allow access to ActiveSync only from clients that have Intune installed.


| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.