In the previous blog, we saw how we can create and use custom attributes. Those attributes were local, which means they are stored in the ACS database, are managed and backed up through the ACS means.
We could, of course, utilize remote attributes. What are those? We have already learned how to connect our ACS server to the Active Direcory.Well, the Active Directory or AD, is also a database that stores user attributes. We could use attributes from there to create our conditions and policies.
Here is the scenario: we want the attribute ANYCONNECT from the previous blog to be stored somewhere in the AD. We also want the IP_ADDRESS attribute to be stored there as well. If the ANYCONNECT equals to YES, we will allow the Anyconnect access. If the IP_ADDRESS is given, we will assign it, otherwise the user will receive the address from a pool.
The scenario is pretty much the same as previous one, with the difference on where we will be picking the attributes from.
First, let’s verify our connection to the AD. Under Users and Identity Stores->External Identity Stores->Active Directory, the ACS status should be Joined and Connected:
If everything is ok, we will have external identity store called AD1, which represents our Active Directory. We can use this identity store to authenticate users against AD and to pull some attributes for users from the AD.
Now here is a catch. If we pull built-in or external attributes, then we need to use an Identity Store. But sometimes we need to pull the attributes from both the local identity store and from an external identity store, such as AD or LDAP. If this is the case, we need to create something called the Identiry Store Sequence. So in our scenario, we will check the ANYCONNECT and IP_ADDRESS attributes from the AD, but before we do that, we may need to collect some local attributes first.
So, let’s create the Identity Store Sequence called LOCAL_AD. Under Users and Identity Stores->Identity Store Sequences->Create we fill in the form:
One more catch. If we need to mix the attributes, then we need to create a local user with the same name as remote user, but instead of specifying a password, we will point the ACS to ask external database for credentials. So, let’s create two users on the ACS.
Now let’s go to the AD and select user’s field we want to use for placing our attributes. For the IP address we will use the Description field:
And for allowing/disallowing VPN access we will use the Notes field:
One thing has more sense to me, but I was not able to pull it off. That thing is that the more logical place to store the IP address in and checking if the user is allowed to do a VPN connection is under the Dial-in tab, Network Access Permission and Assign Static IP Addresses options:
But for some reason ACS would not properly handle the first field and convert the second field from some integer number to an IP address. So this stays for the home work 🙂
Now we need to acquire or map attributes from AD. Under Users and Identity Stores->External Identity Stores->Active Directory->Directory Attributes in the Name of example Subject to Select Attributes field we type in any user name from the AD and click Select. Then we pick our two attributes:
Then we click OK:
Here we can see than the type of description field is String, but we need it to be IP Address. So we need to convert it. We select that field, click Edit, change the type and optionally Policy Condition Name. Then we click Replace. For the info field we don’t need to change the type, but we can change the Policy Condition Name:
The only thing left is adjusting Authorization Profile and Access Service. First the ANYCONNECT authorization profile:
Here we can see that we are using or returning to the AAA client three local and one external or remote attribute. This is why we need to use an Identity Store Sequence.
As for the ANYCONNECT Access Policy, we need to specify our identity store:
And Authorization result:
Here we can see that we are matching external attribute. If we match, then result is the ANYCONNECT Authorization Profile shown above.
Now let’s try for user sasa:
We can see that we fetched two attributes we need. For the user slavisa:
For this user we retrieved only one attribute, because this user has no static IP address configured and dynamic one was provided.
Of course, we could use the method described in this blog post to, for example, place a user into certain privilege level when they try to log on to a network device. Or perhaps something else. We should be creative.
I think that we could pull the attributes from LDAP and RADIUS external stores, but I don’t think we could do that with the RSA user store.
I guess we can wrap up this blog post now.
Thanks for reading!