This week a short post about blocking non-modern authentication protocols. I’ve already provided many examples throughout the blog post I’ve posted regarding conditional access, but the release of Windows Server 2016 triggered me again. The main reason for that are the the additions to Active Directory Federation Services (ADFS) in Windows Server 2016. The main addition to ADFS, for this cause, is the addition of Access Control Policies. During this blog post I want to slightly touch that subject, as it’s getting a pretty easy and common addition to the default conditional access policies of Microsoft Intune and Azure AD.
The funny thing is that I’m not even speaking about the ability to block legacy authentication protocols directly on SharePoint Online, which is of course easier compared to using ADFS. However, it’s not a complete solution, at this moment, as it’s not available for Exchange Online. As long as it’s not a complete solution for blocking non-modern authentication, ADFS will stay really important for completely closing conditional access.
Active and passive authentication
Before I’m going to look at Access Control Policies, I think it would be smart to mention something about active versus passive authentication. I’ve been mentioning it a lot, but I’ve never even tried to explain the differences. When I’m mentioning modern authentication, I’m actually referring to passive authentication protocols and when I’m mentioning non-modern authentication, I’m actually referring to active authentication protocols. The main difference between these two are, in a very simplistic way, the following.
- Passive authentication: Passive authentication uses the browser to do redirects to the identity provider to request a token. The protocol that is used is WS-Federation;
- Active authentication: Active authentication uses direct connection to request a token and login. In this case the protocol that is used is WS-Trust.
Access Control Policies
ADFS now supports the use of Access Control Policy templates. By using Access Control Policy templates, an administrator can enforce policy settings by assigning the policy template to a relying party or a group of relying parties. The administrator can make updates to the policy template and the changes will be applied automatically to the relying parties.
Access Control Policy templates replace the old model where administrators had to configure issuance authorization rules using claims language. The old PowerShell cmdlets of issuance authorization rules still apply but it is mutually exclusive of the new model. Administrators can choose to either use the new model or use the old model. The new model allows administrators to easily control when to grant access, including enforcing multi-factor authentication.
Access Control Policy templates use a permit model. This means that by default no one has access and that access must be explicitly granted. However, this is not just an all or nothing permit. Administrators can add exceptions to the permit rule. Within a rule, of an Access Control Policy, if an administrator selects multiple conditions, they are of an AND relationship. Actions are mutually exclusive and for one policy rule an administrator can only choose one action. If the administrator selects multiple exceptions, they are of an OR relationship.
With all this information it’s time to look at some policy rule examples. Let’s say that I want to permit everything on the intranet and block legacy apps on the Internet. That can be configured in a pretty easier manner, without really getting in to the claims language. There are two different methods to achieve the same result. Both methods start with a rule Permit users from intranet network. Let’s look at the second rule for both of them.
- Permit everything except active authentication: In this approach I use a second rule Permit users from Internet network except with Endpoint Path equals /adfs/services/trust/2005/usernamemixed in the request. This can be achieved by selecting from specific network and with specific claims in the request in the rule editor.
- Permit only passive authentication: In this approach I use a second rule Permit users from Internet network and with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This can be achieved by selecting from specific network and with specific claims in the request in the rule editor.
|Except active authentication
|Permit passive authentication
Fore more information about Active Directory Federation Services and active versus and passive authentication, please refer to:
- Understanding WS-Federation: https://msdn.microsoft.com/en-us/library/bb498017.aspx
- Active Directory Federation Services: https://technet.microsoft.com/en-us/windows-server-docs/identity/active-directory-federation-services
- Access Control Policies in AD FS: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/operations/access-control-policies-in-ad-fs
- Conditional access support for applications: https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-supported-apps/