As more and more businesses realize the value of offloading key messaging technologies to Microsoft Office 365 cloud services, the complexity in cloud migration deployments tends to increase as well. I wanted to share an interesting scenario with those of you who are currently looking to move to Office 365 but are unsure of the options regarding Multi-Factor Authentication (MFA). In this scenario one of our clients posed a question during our Exchange Online Assessments which included some thought-provoking requirements.
“How can we integrate our Multi-Factor authentication server with Office 365 to align with our corporate security practices?
– We only allow external OWA access if protected by Multi-Factor Authentication
– External Outlook clients are not allowed to access email”
A few internet searches for MFA location based integration will lead you to many great articles discussing multiple solutions within Office 365 and Azure to meet most client requirements. A couple of good examples are:
- Using native Office 365 Multi-Factor authentication
- Securing Access to cloud services – Information for Administrators (Requires AD Premium license)
- Tabled feature comparison for Office 365 and Azure Multi-Factor Authentication
- Getting Started with Azure Multi-Factor Authentication
- Limiting Access to Office 365 Services Based on the Location of the Client
While these links help fellow IT engineers figure out the availability of MFA solutions, we very often see that these pages fail to paint the whole picture on how it all comes together with their on-premise MFA server and the requirements for the solution. Most importantly, they fail to properly express the current requirements for subscription based Outlook clients’ (like Office Pro Plus) authentication requests for mailboxes in Office 365 from within the network. This requirement stems from a difference in authentication operations on non-subscription based clients such as a retail or EA install.We will expand on this difference later in this post. If you have any questions about these scenarios, contact us and a member of the New Signature team will be happy to explain some of the items within this post in more detail and relevant to your unique scenario.
Our client’s requirement is to allow all internal connections to Office 365 (OWA and Outlook) without an MFA requirement and the only external access to email is through OWA subject to MFA. MFA is governed by their on-premise solution (RSA, PhoneFactor/Azure MFA Server). This requirement seems to be easily met by either white-listing internal corporate IPs within Office 365 and/or Azure Multi-Factor Authentication (using an AD Premium License) or by using location awareness provided by Active Directory Federation Services (AD FS). But let us not forget the client’s desire to make use of their current MFA solution. Integration with our client’s on-premise MFA server will require the use of AD FS. AD FS allows for the creation of custom claim rules that not only provide white-listing but also to a certain degree, differentiate between the types of authentication requests. This capability is key in fulfilling our client’s location based and on-premise integration with their MFA server.
Subscription based rich clients such as Office Pro Plus Outlook, use Active Federation (MEX or WS-Metadata Exchange) to authenticate directly with the AD FS server which would allow for location based restrictions for MFA. However, the lifeline of all Exchange connectivity – Autodiscover service – utilizes a Basic Authentication mechanism that sends the credentials to Exchange OnlineLync Online first, and then the request is proxied to the ADFS proxy server on behalf of the client. To AD FS, it sees the request as external and will either subject it to MFA unless configured to do otherwise. More information on the difference in authentication can be found here.
At this point an app password would be needed for internal rich clients whom are supposed to be exempt from MFA requirements. Not all MFA on-premise solutions support app passwords and the user experience would be negatively affected by introducing this new requirement internally. Microsoft is currently deploying an authentication solution called ADAL that allows subscription based rich clients to support SAML and remove the app password requirement. However, until this solution is fully available, how do we get around the issue of internal clients Autodiscover lookups being subjected to MFA?
Custom Claim Rules
ADFS Custom Claim Rules allow us to customize the authentication experience with Office 365. In order to achieve our goals we will need to make two types of custom claims rules: Custom MFA claim rule and an Issuance Authorization Rule.
An Issuance Authorization Rule can be applied to the Office 365 Relying Party trust that has been configured for on-premise authentication of AD synchronized accounts into Office 365. Issuance Authorization Rules allow you to take an incoming claim type and then apply an action that will determine whether a user will be permitted or denied access based on the value that you specify. In this case, we want to use an Issuance Authorization rule to deny any external requests from rich clients.
The Custom MFA claim rule can also be applied to a specific Relying Party trust like the one created for Office 365 authentication or globally for all authentication requests that utilize AD FS. We would also configure the custom MFA claim rule to only require MFA if the request is external and if the claim comes from a Web based client (such as a browser accessing OWA).
It is important to familiarize yourself with the authentication workflow of AD FS. You can see a clear outline of this workflow here. The main takeaway is that Custom MFA claim rules occur before an Issuance Authorization Rule. This workflow allows us to implement both of these rules simultaneously to meet our client’s needs.
An example of the custom claim rules needed to achieve this can be found below.
Issuance Authorization Rule
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-forwarded-client-ip”, Value =~ “bXXX.XXX.XXX.XXXb “])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);
Custom MFA Claim Rule
c:[Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”] &&
c1:[Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”,
Value =~ “(/adfs/ls)|(/adfs/oauth2)”]
=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”,
Value = “http://schemas.microsoft.com/claims/multipleauthn”);
Note that you will need to be familiar with the development of custom IP Regex (bXXX.XXX.XXX.XXXb) values in order to properly execute these claims. The IP Regex values will be all possible client PAT IP’s. Information on how to create these can be found here.”
Please note that the relevancy of this article is tied to the implementation of ADAL. Rich client and general authentication improvements provided by ADAL will facilitate location based Multi-Factor Authentication (MFA) making many of these custom claim requirements obsolete. ADAL functionality may be limited to Office Pro Plus clients and other functional limitations.