Access Control Policies and Issuance Authorization Rules in ADFS 4.0 – Part 2

In post “Access Control Policies and Issuance Authorization Rules in ADFS 4.0 – Part 1” we took a quick look on Access Control Policies in ADFS 4.0. We learnt that those can be a very helpful tool to grant permissions for using a Relying Party Trust.
However, in case of our request example, using Claim Rule Language together with Issuance Authorization Rules will meet the request straightforward while we would see difficulties when relying on Access Control Policies.
Here is the definition of our example:
Use Case Example:
All users who are member of any security group starting with CLOUD_ should get access to the Relying Party Trust (and get authorization for the Cloud application). If they are also member of any group starting with DE_, they should get a denial for that Relying Party Trust. Additionally, access is limited only to users who connect from inside the corporate network

Using Control Access Policies to create special access conditions where group membership based on a filter is the key to allow or deny access turns out to be difficult. In the Control Access Policy template, you can only choose specific groups from an Active Directory object picker, which is too static in our case where new security groups might be created and deleted again.

Only specific objects can be selected


Therefore, we use the advantage that ADFS 4.0 supports both, Access Control Policies and Issue Authorization Rules in the same farm.

How to get into the Issue Authorization Rules configuration item

When you create a new Relying Party Trust (RPT), you will noticed, that the wizard sets the “Permit everyone” Access Control Policy for your trust, but offers also to select from the list of templates and existing ones. A checkbox at the bottom gives you the option to skip the configuration of an Access Control Policy at the time of trust creation.

No Access Control Policy is set when creating the RPT


Right-clicking the Relying Party Trust after creation without setting an Access Control Policy still brings us to the well-known Access Control Policy selection.

Access Control Policies and Templates


In order to switch from Access Control Policy to the Issuance Authorization Rules menu we need to use the related Powershell Commandlet.

  1. We set a dummy policy as Access Control Policy (which does not do any harm because conditions are never met for access).
  2. We remove this Access Control Policy by setting $null.
Removing the existing Access Control Policy


Going back to the menu and right-clicking on the trust and selecting “Edit Access Control Policy …” will bring us a menu where we can define Issuance Authorization Rules, as we know from ADFS 3.0. Please note, that the Access Control Policy, which was cleared by our Powershell command No.2, has become a second life as Issuance Authorization Rule!

Issuance Authroization Rules visible in GUI again


The same is visible when retrieving the related attributes by using the Get-AdfsRelyingPartyTrust commandlet.

Get-ADFSRelyingPartyTrust shows Issuance Authorization Rules or the Access Control Policy


You will always have to use the Powershell Commandlet Set-AdfsRelyingPartyTrust if you want to clear an existing Access Control Policy from a Relying Party Trust. The GUI will only allow replacing policies.

Creating and placing the appropriate Issuance Authorization Rules

Once we know that we can place the rules as we know from ADFS 3.0, we can start to configure the conditions. Since we have to deal with the condition to be member of one or multiple groups that start with prefix “CLOUD_” and to be not a member of at least one group starting with prefix “DE_” at the same time, we will have to build two rules – one with an “add” statement and one with an “issue” statement.

The first rule will retrieve all the group names where the user is member and passes this information further to the second rule. This step is necessary because by default only the groups’ SIDs are part of the claim.

Rule with “add” statement to collect all token groups (group SIDs)


The second rule will then check for the permit group conditions (“name starts with CLOUD_”) and the deny group condition (“name starts with DE_”). Additionally, the rule checks for the presence of the “insidecorporatenetwork” claim, which exists whenever the user does not connect through public interfaces and works as incoming claim.
If there is no membership in a deny group, but membership in a permit group, and the user connects from the internal network, thus the rule will issue an authentication token (claim) finally.

Rules with “issue” statement to make conditions, filter and issue claims


Testing the Rule

When writing custom Issuance Authorization Rules, testing is key. If you plan to protect your production Relying Party Trust by complex access rules, you cannot go live with those without proper testing. There are several test applications around which make the outgoing claims visible and therefore easy to check.
Just assign the rules to the Relying Party Trust of the application and see if a test user can access or not (which implies a permit or deny of authentication though).
As you can see, from the screenshot below, our test user is member of two groups, that starts with “CLOUD_” in their names and he is obviously not member of a “DE_” group. We can also see that the “insidecorporatenetwork” claim is set to true which was another condition.

ADFS claim test application for installation in internal network

The fact that we can see the test application web site at all is the evidence that the user was authorized to use the Relying Party Trust and connect to the application. Mission accomplished without using Access Control Policies.

Microsoft has published a web based ADFS test application, which is called Claims X-Ray and works perfectly by mirroring the incoming claims.
You can find it here and external devices can access it, which makes it a very valuable troubleshooting tool.

Access Control Policies and Issuance Authorization Rules in ADFS 4.0 – Part 1

Windows Server 2016 ships with version 4.0 of Active Directory Federation Services (ADFS), which turns out to play a bigger and bigger role in providing SSO capabilities for companies using the Azure Cloud Services. Watch the Ignite 2017 session of Principal Group Program Manager Sam Devasahayam from the Microsoft Identity Divison for more information about new ADFS extensions like “Hello for Business” or the Azure Stack support for ADFS.

One of the most important changes when comparing ADFS version 3.0 of Windows 2012 R2 with ADFS 4.0 of Windows 2016 are the Access Control Policies, which act now as the standard method of granting access, while we no longer see the Issuance Authorization Rules of ADFS 3.0 in the AD FS GUI by default.

However, ADFS 4.0 still supports Issuance Authorization Rules. This post will show how they can be used with ADFS 4.0 and why it makes sense.

Let’s first have a quick look on the modern easy way of granting access by using Access Control Policies:

ADFS 4.0 Access Control Policies

Access Control Policies in ADFS 4.0 allow to configure access to a Relying Party Trust via ADFS authentication based on several criteria.
You can either create Access Control Policies directly adding a new Access Control Policy in the Access Control Policy Container of the AD FS Management GUI (like stand-alone without connecting it to Relying Party Trust) or you can create it when creating the Relying Party Trust. The same functionality can be achieved via Powershell by using the appropriate ADFS commandlets.

Rule Editor of Access Control Policies

You can only assign one single Access Control Policy to one Relying Party Trust, but the Access Control Policy itself can consist of several rules, which are all “Permit” rules. Inside the rule, you can select multiple conditions, which are connected by, AND operators and multiple “except conditions that are connected by OR conditions.
Example for a Policy statement:
Permit users who access ADFS from a specific network AND who are member of a specific group, but even if those conditions are met, deny (Except) access when users are member of a deny group OR when users connect from devices with wrong trust level.

No matter how many rules are defined in an Access Control Policy – as long as the requesting user and device meet the conditions of one of these rules, the policy is valid and ADFS will grant access. If no condition is met, users are not allowed to use the Relying Party Trust and therefore are “denied”.

Multiple Rules in Access Control Policy

Some of the rules allow us to use parameters instead of defined values when creating an Access Control Policy. By doing this, we create rather an Access Control Policy template than a finalized Access Control Policy. Templates give us the advantage, that we can assign the same Access Control Policy to multiple Relying Party Trusts and still use different settings.
In the list view of the Access Control Policy container, you can see in the third column which Access Control Policies are parameterized and which are not. One of the pre-defined templates is based on group membership. The name of the group cannot be set in the template itself, but when it is assigned to a Relying Party Trust.

Access Control Policy with parameters in rule

Assigning the Control Access Policy to a Relying Party Trust allows replacing parameters by selecting groups from Active Directory.

Replacing the parameter placeholder by selecting groups

Another special type of rule in an ADFS Access Control Policy is to permit users (or devices) “with specific claims in the request”.
Based on an incoming claim you can decide by various operators including regex matching, who will get access by this rule.

Permit Rule for filtering on specific claims

You can only use claim types that are defined by your incoming claims. For example, if you want to filter by e-mail address suffix, you have to be sure that claim type E-Mail Address is part of the incoming claim. Therefore, this special rule depends heavily on the resource’s (cloud application) behavior in sending incoming claims.

Assigning and Removing Access Control Policies

You can create a Relying Party Trust with the AD FS Management GUI without assigning an Access Control Policy at all, but you cannot remove an existing one from a Relying Party Trust completely by using the GUI. You only can edit and replace by another one. However, the ADFS Powershell commandlets provide a way to achieve that and we described it in part 2 of this blog post.

Be aware, as long as you do not assign an Access Control Policy to a new Relying Party Trust, access to the Relying Party Trust is denied for all users automatically.

Access Control Policies vs. Issuance Authorization Policies

Overall, Access Control Policies are a very handy and administrator-friendly way of configuring complex access structures for securing Relying Party Trusts.
However, the rule editor does not allow you to make extended filters based on group names other than selecting specific group names one by one, which is too static for many Cloud scenarios.
We often see the case where all users should have access to a SAML Cloud Application whenever they are member of special Cloud security groups that start or end with a special syntax.
To fulfill such a request, using the Claim Rule Language with Issuance Authorization Rules is pretty much straightforward and very flexible when adding multiple conditions. We will show the advantages of Issuance Authorization Rules by playing the following use case:

Use Case Example:

All users who are member of any security group starting with CLOUD_ should get access to the Relying Party Trust (and get authorization for the Cloud application). If they are also member of any group starting with DE_, they should get a denial for that Relying Party Trust. Additionally, access is limited only to users who connect from inside the corporate network

By default, for Relying Party Trusts created in ADFS 4.0 / Windows 2016 the Issuance Authorization Rule interface is not available in the GUI. Nevertheless, there is a way to switch over and we will explain that in post “Access Control Policies and Issuance Authorization Rules in ADFS 4.0 – Part 2”.

Work Folders Part 1: Overview and Requirements

Overview und Benefits

Work Folders – one of the most exciting new feature in Windows Server 2012 R2 that creates a lot of new possibilities for Bring Your Own Devices (BYOD) to provide controlled access to data stored on the corporate network. It provides the following benefits:

  • Users can access only their own Work Folders from their personal computers (or various devices) anywhere from centrally managed file servers on the corporate network
  • Enables users to access work files while offline and sync with the central file server (devices also keep a local copy of the users’ subfolders in a sync share, which is a user work folder)
  • Work Folders can co-exist with existing deployments of Folder Redirection, Offline Files, and home folders
  • Security policies can be configured to instruct PCs and devices to encrypt Work Folders and use a lock screen Password
  • Failover Clustering issupported to provide a high availability solution
  • Work Folders can be published to the Internet using the Web Application Proxy functionality (also new to Server 2012 R2), enabling users to synchronize their data whenever they have an Internet connection, without the need of a VPN or Remote Desktop


Work Folders Server – a server running Windows Server 2012 R2 for hosting sync shares with user files:

  • Install the File and Storage Services role
  • Work folders is managed through Server Manager for a centralizing view of sync activity
  • Multiple sync shares can be created on a single Work Folders Server
  • You can grant sync access to groups (by default, administrators don’t have access to files on the sync share)
  • Possibility to define a device policies per sync share
Work Folders in Server Manager


User devices – best functionality is given with Windows 10, Windows RT 8.1, or Windows 8.1 operating systems; Windows 7, iPad, and iPhone clients are also supported

  • Files remain in sync across all user devices
  • Users work with their Work Folders like with any other folder. The only difference is that when right-click the Work Folders icon, they got the option to force synchronization with the server, and then to other devices
  • Users can access and use Work Folders from different devices, irrespective of their domain Membership

Written by B. Rajic.

Active Directory Federation Services 3.x Technology Basics

Active Directory Federation Services (AD FS) provides Web single-sign-on to authenticate a user to related external hosted Web applications. AD FS performs this by securely sharing digital identity and entitlement rights or claims across security and enterprise boundaries.

AD FS supports distributed authentication and authorization over the Internet to provide access to resources that are offered by trusted partners.

Another aspect of ADFS technology can be found in providing external access from Internet connections to internal resources. In that case the ADFS server can provide an additional layer of security by offering various pre-authentication methods, while the second part of the ADFS technology, the Web Application Proxy server (WAP) acts as a Reverse Proxy by terminating the incoming SSL connections.

In version 3.0 of the ADFS technology, the WAP server cannot be run without ADFS server in the backend, which stores the configuration of the WAP servers. The WAP servers themselves are “stateless” and therefore easy to scale up behind a Layer 4 Load Balancer.

ADFS Server Farms

The Active Directory Federation Services technology can be scaled out by deploying multiple ADFS servers in a farm model. The servers share the same configuration information which is stored in a database on each server (Windows Internal Database (WID) model) or in a central SQL store. In most of the implementations, the WID model is used.
For using the WID model, the configuration can only be modified on the Primary ADFS server and is then replicated to all other ADFS servers of the same farm.
To find the Primary Server use the command “get-adfssyncproperties” on one of the ADFS servers:

Web Application Proxy server

The Web Application Proxy Server is typically the Internet facing component of the Active Directory Federation Services technology. Located in the DMZ, the Web Application Proxy (WAP) servers act as reverse proxy server and terminate the incoming SSL connects from the Internet to the published applications.
Web Application Proxy servers are N to 1 connected to a specific ADFS server (farm). Multiple WAP servers can be easily configured for Layer 4 Loadbalancing.
Since WAP servers are “stateless”, they do not store any persistent configuration information, but load the information from the Primary ADFS server. Therefore a WAP server cannot exist without underlying ADFS server and needs to be installed after the ADFS farm has been deployed.

When acting as reverse proxy for client access using IWA (Integrated Windows Authentication) or when serving non claims aware application access based on Kerberos, the WAP servers must be able to perform Kerberos Constrained Delegation. The WAP server presents a Kerberos token on behalf of the accessing client or user, which in consequence requires the WAP server to be a member of an Active Directory domain. Unfortunately the domain membership of the WAP server means to open a lot more ports from the DMZ to the internal network, which is a disadvantage from network security perspective.

For that reason, applications that do not require Kerberos Constrained Delegation should always be published on non domain based WAP servers, where the exception is to publish applications on domain based WAP servers.

Example for ADFS Farm structure: