When federating a domain within Office 365, and thereby choosing to authenticate using Active Directory Federation Services (or a 3rd party solution), client authentication requests are sent to the on-premises solution deployed. A common misconception is that once federation is decided upon, all authentication requests will actually come from the clients themselves – this is not accurate.
There are 3 types of client endpoints that can connect to a federated account in Office 365:
1. Active Federation (MEX or WS-Metadata Exchange)
- Applies to rich clients supporting ADFS
- Used by Lync and Office ProPlus subscription-based clients
- Clients will negotiate authentication directly with on-premises ADFS farm
2. Passive Federation (Passive Profile)
- Applies to web browsers and documents opened via SharePoint Online
- Used by the Microsoft Online Portal, OWA and SharePoint Portal
- Web clients (browsers) will authenticate directly with on-premises ADFS farm
3. Basic Authentication (Active Profile)
- Applies to clients authenticating with Basic Authentication
- Used by ActiveSync, Outlook 2007+ (non-subscription based), IMAP, POP, SMTP and Exchange Web Services
- Clients send Basic Authentication credentials to Exchange Online via SSL, Exchange Online proxies the request to the on-premises ADFS farm on behalf of the client
“Why does any of this matter?”
I’ve worked with multiple organizations looking to customize their ADFS solution restrict access in a variety of ways, such as “internal users only”, restricting authentication to approved-only devices by using a Client Certificate ADFS deployment, or using the new Workplace Joined Devices option in ADFS 3.0. While these solutions are viable for Active Federation and Passive Federation client endpoints, Basic Authentication (or Active Profile) client endpoints’ requests actually come from the Microsoft Federation Gateway – this means that a public certificate is required, as well as external accessibility, to support these clients. As it follows, any solution using internal PKI certificates or restricting external access to the ADFS farm will fail for these clients.
“What are my options?”
Typically, when restricting device access comes up in conversations, it’s because there is a worry about access to cached data on unmanaged devices. The (incorrect) thought process is that if the device access to ADFS is restricted, then cached data will only end up on approved devices. While it is conceivable that managed devices could be strictly controlled in a way that would completely prevent data leakage, it is unrealistic in most organizations to trust that data can’t end up on unmanaged storage format, such as a flash drive, DropBox or even a swapped out laptop hard drive. So, rather than expend effort chasing after every potential endpoint, it may make more sense to protect the data itself. The answer here is Rights Management Services. By encrypting the data itself, the medium on which the data is held becomes irrelevant, as long as the account is managed; once the account loses access to the decryption keys, the user loses access to the document. This is not the right answer for every organization, though, so make sure you formally define business and technical requirements in design sessions before deciding on a solution.
Alternative, “soft” solutions may involved corporate policies with some combination of managed devices, log audits, prescribed device wipes and 3rd party solutions to put forth a best effort to secure data. As always, also be sure to consider whether the cloud is the right solution for the scenario being reviewed; hybrid options exist for this reason.
Thank you to Microsoft Consultancy Services UK for the image and supporting information!
