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

Posted on by rkmigblog

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 https://adfshelp.microsoft.com/Tools/ShowToolsInternal and external devices can access it, which makes it a very valuable troubleshooting tool.

Tool Factory: Release of PS-REPADMIN 1.9

Posted on by rkmigblog

PS-REPADMIN 1.9 is available now. PS-REPADMIN helps to view object metadata and attribute values in a simple table view.
We made several improvements in 1.9, especially for comparing groups with their metadata between trusted Active Directory domains. The tool also provides now an easier look on Proxy Addresses and Linked Attribute values.

PS-REPADMIN 1.9 was tested with Windows 10, Windows Server 2012 R2 and Windows Server 2016. Usage is on own risk. All rights reserved by Silverstar Consulting GmbH.
Download here to test the trial version for free.
(Note: After download, unzip the file and after that rename the .zip extension to .exe)

Full table view on attributes and their last change including group member values. The parallel listing makes it easy to compare values of objects from different domains.

Linked attributes are displayed in a separate view for easier comparison.

Download here to test the trial version for free.
(Note: After download, unzip the file and after that rename the .zip extension to .exe)

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

Posted on by rkmigblog

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.

https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK3020

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”.

Web Application Proxy Event 13007

Posted on by rkmigblog
Written by Robert Kettel

When you start to use Web Application Proxy Server (WAP) as a replacement for ISA, TMG or UAG and publish Active Sync through it, you might face a lot of Event 13007 warnings in the Microsoft-Windows-Web Application Proxy/Admin event log (I mean, really “a lot”). These are paired with various Event IDs 13006 (“Connection to the backend server failed. Error: (0x80072efe)”).

On the other hand, you don’t get any complaints from the user community. There does not seem to be an impact at all.

Where do these warnings come from? Do they impact our service and can we prevent them from showing up over and over again?

The main cause for the warning 13007 and 13006 is how devices with Exchange Active Sync (EAS) and Direct Push technology connect to Exchange.

Following this Microsoft TechNet article, “a mobile device that’s configured to synchronize with an Exchange 2013 server issues an HTTPS request to the server. This request is known as a PING. The request tells the server to notify the device if any items change in the next 15 minutes in any folder that’s configured to synchronize. Otherwise, the server should return an HTTP 200 OK message. The mobile device then stands by. The 15-minute time span is known as a heartbeat interval.”

With other words, there is a steady HTTPS session for 15 minutes between the EAS device and the Exchange backend which must be supported by all components taking part in the HTTPS session build, usually firewalls, load balancers and (in our case) the WAP servers which proxy the HTTPS session coming from the LBs to the Exchange backend. The long lasting session request is finally terminated by the Exchange server by posting an HTTP 200 message.

Now, looking at the default settings of our WAP servers we find a parameter which can have an influence on that behavior.
The default value for the InactiveTransactionTimeoutSec parameter is 300 (= 5 minutes). That means that if the accessing party does retrieve new responses from the backend service defined in the application settings for more than 5 minutes, the connection is identified as “timed out” and dropped by the WAP server.

From that perspective a connection to the Exchange Backend Service is timed out for the Web Application Proxy (causing a warning event 13007), when
a) the heartbeat interval of Direct Push is longer than the InactiveTransactionTimeoutSec
AND
b) the session was not renewed by the device
AND
c) there was nothing to synchronize in the first 300 seconds of the connection

However, if the device’s HTTPS session is dropped by the WAP server, it will automatically re-initiate a new session (the same what the device would do when getting an HTTP 200 OK message from the backend Exchange server). Therefore this is not a critical behavior at all.

The difference can be found how the device reacts on the dropped connection in comparison with how it handles the HTTP 200 OK post.
In the latter case, the device starts a new HTTPS session with the same heartbeat interval again.
In the first case, the device “assumes” that 15-minute HTTPS requests are blocked and re-initiates a new session with only 8 minutes (480 seconds) – which is still beyond the 300 second default setting of the WAP servers.

To avoid the Event 13007, the InactiveTransactionTimeOutSec parameter needs to be set to a value greater than the defined Active Sync max period. By default, the Active Sync device starts with a 15-minute interval, which would fit into a value of 910 for the InactiveTransactionTimeoutSec.

Since the parameter can be set for each published application individually, you luckily do not need to touch other published applications than Exchange Active Sync.

Example command:

Get-WebApplicationProxyApplication ExchangeActiveSync | Set-WebApplicationProxyApplication –InactiveTransactionsTimeoutSec

Note:

A support engineer with Microsoft Premier stated that there is currently no way to suppress the Event 13007 from appearing in the log files completely.

ADFS – How to enable Trace Debugging and advanced access logging

Posted on by rkmigblog

Dieser Beitrag wurde am 18.11.2015 um 22:38:18 in Cloudy Migration Life veröffentlicht

ADFS – How to enable Trace Debugging and advanced access logging
Debugging an Active Directory Federation Services 3.0 farm together with the Web Application Proxy servers in front can be a very complex task when you think of all the different constellations that can be served by this technology. Especially when it comes to access from mobile devices and Microsoft Online as relying Party.
In principle, trace debugging can have 3 target scopes:

  • Trace debugging on the backend – on WAP servers and ADFS servers to see how the authentication request is terminated
  • Trace debugging on the accessing device – to see how the authentication request is initiated
  • Network trace to see the authentication flow travels from device to the ADFS farm and back. Actually you need to terminate the SSL connection with a special tool like Fiddler to inspect the content.

For many professionals the Fiddler trace will be the most complex way to start debugging, especially when you are acting in secured and controlled enterprise network. Many apps on mobile devices (e.g. the Office Apps for Android) also show poor logging and tracing capabilities to show what the app is actually doing in terms of federated authentication.

Therefore, we should utilize the complete debugging capabilities of ADFS as preferred option. As long as there is a communication between device and WAP/ADFS servers, we fortunately receive a lot of information from the Trace logs of the backend servers.

STEP 1: Set Trace level and enable ADFS Tracing log:
Please enable the debugging logging on the ADFS 3.0 Server:
Open an elevated CMD window and type the following command: C:Windowssystem32>wevtutil sl “AD FS Tracing/Debug” /L:5

In Event Viewer highlight “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”

In Event Viewer highlight “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Navigate to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging immediately.

 


Navigate to AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
It is difficult to scroll and search in the events page by page in the Debug Log. Therefore save all Debug events into an *.evtx file first.


Open the saved log again. Now you can scroll and search a lot smoother through the events.

STEP 2: Enable Object access auditing to see access data in security logs:
If we want to see exhausting data about access activities on the ADFS servers we have to tun on object access auditing (not account logon auditing). You have to enable auditing in 2 locations on the ADFS server.

  1. Turn on auditing in the ADFS GUI. On the primary ADFS server right-click on Service and activate “Success audits” and “Failure audits”. This setting is valid for all ADFS servers in the farm.
  2. To make this setting actually work, you have to do a second step on the ADFS server in the Local Security Policy (unless there is a similar Group Policy setting coming from the Active Directory structure).
    Open the GPO Editor, navigate Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy and configure “Audit Object Access” with “Success” and “Failure”. This setting has to be made in the Local Security Policy on each ADFS server (or a GPO is set on OU or different level in Active Directory).
  3. Looking at the security event logs of the ADFS servers, you will notice a much higher amount of events coming in which provide a much higher level of insights.

It is a good starting point to exactly note the time when running e.g. an access attempt and then look up the timestamps (+ offset for runtime) in both event logs, ADFS Trace Debugging and Security.