Get started Bring yourself up to speed with our introductory content.

Configure claim rules for greater Office 365 access control

Customized claim rules can be an important way to help your organization handle and enforce its Office 365 access policies.

Active Directory Federation Services offers a number of benefits for controlling access to Office 365. Perhaps...

the biggest benefit is that organizations can control passwords and policies associated with them. Client Access Policies are a good choice for organizations that want granular control over authenticating users through Active Directory Federation Services to access Office 365. This type of control may even be a game-changer for some organizations.

Once you're familiar with what Active Directory Federation Services (AD FS) Client Access Policies are and how to use them, you can explore how to put those policies to use.

After you've configured AD FS for Office 365, a default claim rule called Permit Access to All Users will exist. This rule generates a token for all successfully authenticated users.

To view the claim rule, open the AD FS management console and navigate to Relying Party Trusts. Right-click on Microsoft Office 365 Identity Platform and then select Edit Claim Rules. In the new window, click the Issuance Authorization Rules tab (Figure 1).

Issuance Authorization Rules in AD FS console
Use the AD FS management console to view the claim rule.

As you can see from the screenshot, we've already created a new claim rule. This claim rule, which we'll dissect, takes a user's group membership to determine whether a token was generated. In this case, if the user account is a member of a group called NoADFSAccess, it won't generate a token and the user won't be authenticated for Office 365 services.

However, it's important to understand how claim rules are processed. When a user authenticates, the AD FS server will process rules in order of priority. When a match is found, a token is either created (if the action is set to "Permit") or access is denied (if the action is set to "Deny"). No further processing occurs when a match is found. In this particular example, it's important that the custom claim rule be processed first. Otherwise, a token would be generated for every user regardless of their NOADFSAccess group membership status.

Use group membership to limit Office 365 access

Custom claims can be generated in two ways. You either use the GUI-based wizard, which will construct the appropriate claim rule language for you, or you write your own claim rule.

Personally, I prefer to use the wizard when possible because it reduces the room for error and is easier. Unfortunately, the wizard doesn't support the creation of certain advanced claim rules. In this example, we will use a Windows Server 2012 R2-based AS FS server.

From the Edit Claim Rules window, click add claim and follow these steps.

1. Make sure to select Permit or Deny Users Based on an Incoming Claim and click Next (Figure 2).

Permit or Deny Users Based on an Incoming Claim

2. Type in a descriptive name for the rule. Use something that immediately depicts what the rule is used for.

3. Select Group SID from the Incoming Claim type drop-down box and then use Browse to select the appropriate group from Active Directory.

4. Make sure to select Deny access to users with this incoming claim and then click Finish (Figure 3).

Deny access to users with the incoming claim
This is what you should see after editing the claim rule.

After the rule is created, you can use the arrow to rearrange the priorities.

Deconstruct the claim rule

Now, let's look at the claim rule language. Click Edit Rule and then View Rule Language to edit the claim rule. For this rule, the following language was created:

C:([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i)S-1-5-21-<group-id>"])

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

When you take a closer look at the claim rule language, you'll see it's fairly readable. The first part refers to the group membership. The language states that if the Group SID equals a specific value (the Group SID from the group we selected), access should be denied:

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

Create more complex claim rules

Once you've established how claim rules are constructed, you can dig into more complex examples. Out of the box, Microsoft supports a number of claims that can be used to alter AD FS's behavior. However, you can add claims to create new claim rules. For example, you can use the X-MS-Proxy claim rule to determine whether traffic went through an AD FS proxy server. This is often used to determine whether an authentication request originated from inside (the claim isn't present) or outside (the claim is present) the corporate network. You can find more information about adding claims to your AD FS configuration on Microsoft's TechNet site.

You can also use a claim rule to limit access to Office 365 to users who are members of a specific group and located inside the corporate network. Let's use an example to clarify. This example will use a group called Office365access to determine who has access to Office 365. Here's the logic behind the claim rule:

1. Anyone who is not a member of the group is denied access.

2. Anyone who is a member of the group but is trying to access services from outside the corporate network is denied access.

For this example, we'll also assume that you've already added the X-MS-Proxy claim as outlined in the process from the TechNet article we mentioned earlier.

For the following claim rule to work, it's important that external traffic always flows through an AD FS proxy server or the Windows Web Application Proxy. This will ensure that the X-MS-Proxy header is present. If not, AD FS has no way to determine if traffic is internal or external.

First, we'll use a claim that's similar to the one in the previous example to determine if a user is member of a specific group:

exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i)S-1-5-21-<group-id>"])

Then we'll add some code to specify that a user must be internal:

&& not exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])

Finally, if both conditions are true, a claim that grants access to Office 365 should be created:

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

If we bring it all together, we get the following code:

exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i)S-1-5-21-<group-id>"])

&& not exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

This code translates into the following logic:

1. If a specific group ID is present (=member of a specific group) and

2. There is no x-ms-proxy claim (traffic didn't go through the AD FS proxy and is therefore deemed internal), then

3. Issue a token.

Even though we now have the correct claim, we still need to make one last change. The default rule will accept all authenticated users. As a result, we need to modify the rule to deny access to all users and then make sure it has a lower priority than the new custom claim rule.

There are many other scenarios in which custom claim rules can come in handy. For instance, you can allow or deny access to specific workloads, such as Exchange ActiveSync. You could use the source IP address of the user to determine whether access should be granted.

As a general rule, don't go overboard with them. Adding your own claim rules can make supporting authentication considerably more difficult. If you can do without them, I recommend that. If you need to use them, use the wizard as much as possible and avoid creating your own claim rules. If there's no other option, take a look at the examples available here and in that TechNet article. In most cases, they'll help you solve the problem.

About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.

Next Steps

This is part two in a series on Office 365 access policies. Click here for part one, which explores the importance of Client Access Policies in controlling who has access to an organization's Office 365.

This was last published in November 2014

Dig Deeper on MS Office 365

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Unless something has changed between ADFS 2.0 and ADFS 2012 R2, this technet article states that /all/ claim rules are processed whereas your article states processing stops on the first match.

"It is important to note that the rule processing system always processes all rules. It is NOT a first match system. Because of this, the first rule is most always an “allow everything” rule followed by additional rules that block some access." http://blogs.technet.com/b/askds/archive/2012/06/26/an-adfs-claims-rules-adventure.aspx
Cancel
Hello, great article. We have this working as your instructions. However we have introduced Outlook 2016 and although internal, they still get denied the claims rule. Not sure if this is down to the new client? Do you happen to know?
Thanks
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close