Friday, September 13, 2013

ACS 5.x: Using Identity Groups to Simplify Authorization Policies

One of the things that I rarely see implemented in ACS 5.x are Identity Groups.  This is an incredibly powerful tool that can be implemented in almost every ACS installation.  It's one of those things that is really useful when dealing with failover, multiple identity stores, etc.

I was reminded how powerful this is when I received a call from a customer who's entire wireless and VPN environment was down due to issues with their ACS box.  The root cause?  All of the domain controllers were having issues.  Sadly, LDAP was still functioning, but they had never tested the LDAP integration and it didn't work.

For those that do implement multiple identity stores, what I usually see is a HUGE list of Authorization rules for each combination of Group and Store.  This gets really nasty when trying to troubleshoot why you are getting a particular undesired result.

Here I will be showing how to authenticate against multiple identity stores in order to deal with the failure of AD, LDAP and finally roll to internal users.


Let's start off by assuming you have joined ACS box to AD, and setup your LDAP configuration as well as selected some groups that you want to authenticate against.  For our Examples we'll use the AD Group Teachers and Students.





Let's also setup an Identity Group for Students and Teachers.  Since this is my lab, I have built it in my Education Examples parent.


And for good measure, we'll create a local account for both a student and teacher.  These have their local account set to the same password as the AD Account just for simplicity.  Notice that I have placed the local accounts in the Identity groups I just created.


The next part is setting up the Identity Store Sequence.  We'll start with AD1 > LDAP > Internal Users.



We have a service selection rule setup to go to a Wireless Network Access Policy.  This policy just says if you come from a wireless device and the protocol is RADIUS, you should use the Wireless Network Access policy.  You will need to check the allowed protocols and make sure Identity, Group Mapping and Authorization are selected.  For this example we will be using PEAP with EAP-GTC, since LDAP doesn't support the popular MSChapv2 for the PEAP inner method.


For the Identity we are selecting our Identity Store Sequence group.


Under Group mappings is where the magic happens.  Here we take our AD group memberships or LDAP group memberships get mapped to an Identity Group



We continue on for Students as well.  Notice we assign AD and LDAP members to the Identity Group. The final result for this example looks like this


Now we can write our Authorization Policy.  We just write a policy that checks if the IdentityGroup matches Students or Teachers.  Then we deliver them the appropriate Authorization Profile.


Since we did all of our mapping of AD/LDAP Groups to Identity Groups under the Group Mappings, our Authorization Policy is pretty short and sweet.  Now on to the testing!

In my lab I don't have a good way to fail AD without taking out LDAP, so I just move the order around in my store sequence.  As you can see, the student receives the appropriate Student-Access profile authenticated against each datastore.  For this example, I used the Intel Proset Supplicant as Windows 8 STILL doesn't support EAP-GTC which is required for the LDAP integration.




We run the same test for teachers and we get a very similar result.


As you can see, we could scale the number of groups and identities and maintain a mapping of a single Identity Group to a single entry in the Authorization Policy.  Now while this works for EAP-GTC, but it's really not practical for use in most wireless environments.  The same process applies to using TACACS+ to do network device administration and you don't have to worry about client supplicants.