Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2016 > January

This is a continuation of the Setting up an access policy for users on or off the corporate network with RSA Via Access blog post. In that post we saw how we can create a policy to match on IP ranges. Now let's get a little creative with our rule sets.

Creating a Rule Set to Match Multiple Users

Let's say we were trying to create a policy to allow access to an application for multiple users. In Active Directory (AD) their usernames (Or sAMAccountName Attributes) were as follows:

  • jason
  • karim
  • lenore

With this information we can create a rule per username to be:

  • sAMAccountName EQUAL jason
  • sAMAccountName EQUAL karim
  • sAMAccountName EQUAL lenore

In the Access Console our matching criteria would looks like this:



Notice our Match directive is set to Any, this is the same thing as a logical OR, meaning the above Rule Set is translated to this:


Rather than creating policies with multiple users in them, I would recommend creating a Group in AD and then creating a policy based on that AD Group. But just to illustrate a point let's pretend that we can't create groups within AD.

Combining Multiple Rules into a Single Rule with Usernames


Now instead of creating three different rules we can create one. There is an operator called Set Contains Any:




and it actually works on single valued attributes (like sAMAccountName). So when creating our rule it would look like this:


And in the end our Matching Criteria looks like this:


I have the Match directive set to Any but since there is only one rule it doesn't really matter. The Set Contains Any Operator is it self another logical OR operator. So the Rule Set would be translated to:

IF [ SAMACCOUNTNAME SET_CONTAINS_ANY (  jason OR karim OR lenore ) ]

Combining Multiple Rules into a Single Rule with IP Addresses


In the first blog post we saw multiple rules created to match multiple IP Ranges. Currently in the Access Console the IP Address attribute is treated as a string therefore operator like Starts_With and Ends_With are applicable. Another operator which can be used with strings is the matches operator. The matches operators allows you to match strings using regular expressions. I am not going to dig deep into what regular expressions are, but they basically allow you to do really advanced pattern patching with strings.So let's say our network engineer told us that the following CIDR (Classless Inter-Domain Routing) Blocks represent our internal network:




If we convert the CIDR Blocks to IP ranges we get the following:


$ ipcalc
Address:           00001010.00001010.0000101 0.00000000
Netmask: = 23   11111111.11111111.1111111 0.00000000
Wildcard:            00000000.00000000.0000000 1.11111111
Network:        00001010.00001010.0000101 0.00000000
HostMin:           00001010.00001010.0000101 0.00000001
HostMax:         00001010.00001010.0000101 1.11111110
Broadcast:         00001010.00001010.0000101 1.11111111
Hosts/Net: 510                   Class A, Private Internet


We just need to check out the HostMin and HostMax values, so our range is - We can see that with basic string matching we could create two rules:

  • IP_Address Starts_With 10.10.10
  • IP_Address Starts_With 10.10.11

Doing the same thing for the other CIDR Block, we get the following:


$ ipcalc
Address:         11000000.10101000.00001010. 00000000
Netmask: = 24   11111111.11111111.11111111. 00000000
Wildcard:            00000000.00000000.00000000. 11111111
Network:      11000000.10101000.00001010. 00000000
HostMin:         11000000.10101000.00001010. 00000001
HostMax:       11000000.10101000.00001010. 11111110
Broadcast:       11000000.10101000.00001010. 11111111
Hosts/Net: 254                   Class C, Private Internet


Again looking over the HostMin and HostMax our IP Range is It looks like the third octet doesn't change so we can cover this in one rule:


  • IP_Address Starts_With 192.168.10


With three rules we can cover the specified network ranges. Now let's get creative and combine our three rules into one. Using the matches operator we can create a rule like this:


  • IP_Address Matches (^10\.10\.10\.|^10\.10\.11\.|^192\.168\.10\.)


The carrot (^) translates to Starts_With, the pipe (|) translates to an OR, and the backward slash (\) is to escape the special character period (.) which means any character. (This is a very simple regular expression and other more detailed examples exist... ie RegEx Magic IPv4 Patterns). Here is how it looks like when entering the rule in the Access Console:


And in the end here is the Matching Criteria:


The above rule would translate to:

IF [ IP_ADDRESS MATCHES ( (STARTS_WITH 10.10.10) OR (STARTS_WITH 10.10.11) OR (START_WITH 192.168.10) ) ]

If the CIDR Mask is less than 24 then the regular expressions will get more creative.

Creating Complex Rule Sets with Combined Rules

Now why did we do all this hard work to combine our rules? Here is where it will pay off. Let's say we wanted to create a rule that says:


  • Match For Specific User And if on Internal Network


So we could just create this in the Access Console:


  • sAMAccountName EQUALS jason OR karim OR lenore (AND)
  • IP_Address STARTS_WITH 10.10.10 OR 10.10.11 OR 192.168.10

Here is how the Matching Criteria will look like in the Access Console:


This time around I set the Match directive to be All and this is the same thing as a logical AND, meaning the above Rule Set is translated to this:

IF [ SAMACCOUNTNAME SET_CONTAINS_ANY (  jason OR karim OR lenore ) ] AND [ IP_ADDRESS MATCHES ( (STARTS_WITH 10.10.10) OR (STARTS_WITH 10.10.11) OR (START_WITH 192.168.10) ) ]

And that should cover it

Filter Blog

By date: By tag: