There are often questions about the advantages of using Active Directory Federation Services for limiting access...
to Office 365 over other options like Password Synchronization. While I really like the Password Sync approach -- and it's a tad easier to implement -- there are some major benefits for using another option.
Of course, there are additional costs associated with using Active Directory Federation Services (ADFS). First, you must take into account that you will have to manage additional machines that run ADFS and possibly ADFS proxies. Second, ADFS becomes a critical part of your setup as soon as you enable it. If your ADFS server stops working or becomes otherwise unavailable, your users won't be able to authenticate to use Office 365 or access any of the services. As such, you should always make sure that you have a highly available setup; if it's possible, consider using a second data center or Azure Virtual Machines.
But one of the benefits of using ADFS is that you maintain full control of passwords and associated password policies. However, Password Sync offers a similar experience. Passwords in Office 365 won't expire for end users who synchronized their passwords. Because they will be forced to change their password on-premises after a certain amount of time (depending on the policy), the password will sync to Office 365 as soon as it's changed. This isn't a game changer, but Client Access Policies might be for some organization. By using custom claim rules or Client Access Policies, organizations can have granular control over who is allowed to authenticate through ADFS for access to Office 365. Compared to that functionality, Password Sync is more of an "all or nothing" approach.
The importance of Client Access Policies
Why would someone want to use Client Access Policies? For instance, you may need to limit which users can use specific Office 365 services based on where they're located or what group they belong to. And before getting started with these policies, it's important to understand how ADFS works with Office 365.
The reason why Client Access Policies are important is because the authentication flow dictates what claims you can and can't (or shouldn't) use. For instance, the Active Authentication flow is used when someone uses Outlook. This means that an inbound connection to ADFS is made from Office 365, not from the client's workstation. As such, it's not possible to use the client's IP address (at least not directly) to limit access through ADFS.
Several claims are passed along to the ADFS server, depending on how and from where a client connects to ADFS. If you use an ADFS Proxy server, you especially have the ability to easily identify whether a user is internal or external (Figure 1). This is based on whether there's a direct connection to the ADFS server (internal) or if the connection is made through an ADFS proxy server (external).
Next to a wealthy set of regular claims, which can be used to determine one's group membership, connections to ADFS can also use the following claims to control the authentication behavior:
- X-MS-Forwarded-Client-IP (the client's IP address)
- X-MS-Client-Application (the application being accessed, e.g. OWA)
- X-MS-Proxy (if coming through an ADFS Proxy server)
- X-MS-Endpoint-Absolute-Path (what type of authentication flow is used)
About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.
This is part one in a series on Office 365 access policies.
Stay tuned for part two, which covers creating custom claim rules to limit access to Office 365 by using Group Memberships, User Locations and application accessibility.