Office 365 access: Enforcing VPN with ADFS

Recently, I was asked for possible solutions to enforce VPN connection to access Office 365. This seems odd at first, for this is against one of the tenets of Office 365, accessing service from anywhere and on any device. But then there is always a certain use case that needs to be addressed. In this case, the customer had deployed Office 365 and federated using ADFS, a textbook deployment with 2 ADFS server farm, and 2 WAPs in the DMZ.

Within the Microsoft 365 world, Intune and Conditional access would enable for enforcing policies. However, that will also require the customer to acquire additional licenses beyond O365 E3, which my customer did not want to do.

I compiled some of the possibilities with ADFS to enforce VPN connectivity. Although I do not recommend anyone to bypass the features, I want to share this out to get some feedback from the community, to see if this is such a common scenario, or if anyone implemented any of these or other cost-effective solutions.

Possibilities using ADFS:

There are options available through ADFS configuration to disable access to Office 365 from a domain joined, but non-domain connected device. The following will focus only on the ADFS possibilities to disable non-VPN users from accessing Office 365 services. Implementing any of this may affect services other than Office 365, which may be using ADFS for identity federation.

Note: Imposing VPN connectivity will put a load on the VPN environment with possible use of Office 365 services such as EoL, SharePoint, Office ProPlus, ODFB, Teams, SKFB etc.

 Options:

1.       Turn off WAP servers:

In Microsoft and ADFS world, WAP servers sit in the DMZ and provide for proxy termination of all requests coming from the internet. The user is challenged to authenticate themselves with their User ID and Password. Turning off the WAP servers would mean there is no end point for the internet traffic to authenticate to. So, this should force only the network connected devices to authenticate through ADFS and access Office 365 services. Turning off the WAP server would mean:

a.       All access from non-domain connected devices will be disabled

b.       Will affect all applications/services- beyond Office 365- that are using ADFS as the identity provider

c.       Users connecting from domain connected devices will not be affected, as they will be directed to ADFS servers

d.       To test:

                                       i.      Critical: External users- Modern apps (Office 2016), classic apps, web apps, Clients apps (Outlook, Skype)

                                     ii.      Good to test: Internal users as well.

2.       Differentiate access policies for intranet and Extranet access -

a.       Typically, access policies are different for intranet and Extranet users. Access with forms authentication is turned on for Extranet users, while intranet users will experience Web SSO with IWA

b.       Disabling forms authentication for external users could stop those users not connected to the company network

c.       This will affect Office 365 and any other applications/services that is using ADFS as the identity provider

d.       Users from domain connected devices should not be affected

e.       To test:

                                       i.      Critical: External users- Modern apps (Office 2016), classic apps, web apps, Clients apps  (Outlook, Skype)

                                     ii.      Good to test: Internal users as well.

3.       Edit claims rules / Access Control Policy:

a.       Modify "Issuance Authorization Rules" (Server 2012), "Access Control Policy" (Server 2016)

b.       This can be done at the Relying party trust level, and hence will not affect global ADFS environment like the previous two options

c.       Access Control Policy (Server 2016)

                                       i.      For the "Office 365" Relying Party Trust, modify the "Access Control Policy" as needed

d.       Claims rule - "Issuance Authorization Rules" (Server 2012)

                                       i.      Edit "Issuance Authorization Rules" claims rule for the "Office 365" Relying Party Trust

                                     ii.      Permit or Deny based on "Inside Corporate Network" claim

e.       This is a little more complex than the previous 2 options but opens the possibilities

f.        Beware that the claims rule changes could have inadvertent effect on domain-connected users as 

        well

g.       To test:

                                       i.      Critical: Both Internal and External users - Modern apps (Office 2016), classic apps, web     

                                  apps, Clients apps (Outlook, Skype)

Those are the possibilities with ADFS that I came up with. Let me know if you have come across this requirement and what your solution was.

In a follow up blog, I will discuss other ways to secure the service/content using MFA, Conditional Access, AIP/ DLP etc. Till then, enjoy whatever you are doing.