Manage Risk with Conditional Access Control

• Key concepts-conditional access control in AD FS

• Managing Risk with Conditional Access Control

The overall function of AD FS is to issue an access token that contains a set of claims. The decision regarding what claims AD FS accepts and then issues is governed by claim rules.

Access control in AD FS is implemented with issuance authorization claim rules that are used to issue a permit or deny claims that will determine whether a user or a group of users will be allowed to access AD FS-secured resources or not. Authorization rules can only be set on relying party trusts.

For more information about these rule options and logic, see When to Use an Authorization Claim Rule.

In AD FS in Windows Server 2012 R2, access control is enhanced with multiple factors, including user, device, location, and authentication data. This is made possible by a greater variety of claim types available for the authorization claim rules. In other words, in AD FS in Windows Server 2012 R2, you can enforce conditional access control based on user identity or group membership, network location, device (whether it is workplace joined, for more information, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications), and the authentication state (whether multifactor authentication (MFA) was performed ).

Conditional access control in AD FS in Windows Server 2012 R2, offers the following benefits:

• Flexible and expressive per-application authorization policies, whereby you can permit or deny access based on user, device, network location, and authentication state

• Creating issuance authorization rules for relying party applications

• Rich UI experience for the common conditional access control scenarios

• Rich claims language & Windows PowerShell support for advanced conditional access control scenarios

• Custom (per relying party application) 'Access Denied' messages. For more information, see Customizing the AD FS Sign-in Pages. By being able to customize these messages, you can explain why a user is being denied access and also facilitate self-service remediation where it is possible, for example, prompt users to workplace join their devices. For more information, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

The following table includes all the claim types available in AD FS in Windows Server 2012 R2 to be used for implementing conditional access control.

Using the available settings, there are many ways in which you can manage risk by implementing conditional access control.

For example, imagine a simple scenario of implementing conditional access control based on the user's group membership data for a particular application (relying party trust). In other words, you can set up an issuance authorization rule on your federation server to permit users that belong to a certain group in your AD domain access to a particular application that is secured by AD FS. The detailed step by step instructions (using the UI and Windows PowerShell) for implementing this scenario are covered in Walkthrough Guide: Manage Risk with Conditional Access Control. In order to complete the steps in this walkthrough, you must set up a lab environment and follow the steps in Set up the lab environment for AD FS in Windows Server 2012 R2.

Other examples of implementing conditional access control in AD FS in Windows Server 2012 R2 include the following:

• Permit access to an application secured by AD FS only if this user's identity was validated with MFA

  You can use the following code:

  @RuleTemplate = "Authorization"
  @RuleName = "PermitAccessWithMFA"
  c:[Type == "https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~ "^(?i)https://schemas\.microsoft\.com/claims/multipleauthn$"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");
  
  

• Permit access to an application secured by AD FS only if the access request is coming from a workplace joined device that is registered to the user

  You can use the following code:

  @RuleTemplate = "Authorization"
  @RuleName = "PermitAccessFromRegisteredWorkplaceJoinedDevice"
  c:[Type == "https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value =~ "^(?i)true$"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");
  
  

• Permit access to an application secured by AD FS only if the access request is coming from a workplace joined device that is registered to a user whose identity has been validated with MFA

  You can use the following code

  @RuleTemplate = "Authorization"
  @RuleName = "RequireMFAOnRegisteredWorkplaceJoinedDevice"
  c1:[Type == "https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~ "^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$"] &&
  c2:[Type == "https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value =~ "^(?i)true$"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");
  
  

• Permit extranet access to an application secured by AD FS only if the access request is coming from a user whose identity has been validated with MFA.

  You can use the following code:

  @RuleTemplate = "Authorization"
  @RuleName = "RequireMFAForExtranetAccess"
  c1:[Type == "https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~ "^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$"] &&
  c2:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value =~ "^(?i)false$"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");
  
  

Walkthrough Guide: Manage Risk with Conditional Access Control Set up the lab environment for AD FS in Windows Server 2012 R2