Hopefully this will be the last topic about AAA authentication and Cisco, not because its either unimportant or irrelevant to the CCIE, just because I have spent ages delving into AAA with setting up AAA access to IPS modules on ASA, or catalyst switches, or Nexus switches, and finally I have worked out how to separate admin and read-only access to Cisco ASDM for ASA's via AAA using LDAP.
Continuing the general network security implementation my role centres around, I need to keep a distinct separation of duties as part of our PCI compliance, so when the ticket came in to set up read-only ASDM access to our ASA firewalls for our network operators, I thought, fine, no problem. We already had them authenticate via LDAP both for administration and for AnyConnect VPN access, so it should not be too hard, and as we already have radius set up for the IPS modules and for the Nexus and Catalyst switches, I have two potential methods of implementation available to get this working.
Well, actually it took me longer than I had expected. Through testing I used my own account, and a test account called testnps. My account is a member of sec-fw-admin, and the test account is a member of sec-fw-ro.
Radius as we have seen in previous posts offers the Cisco-AV-Pair which we have successfully used, but try as I might, no matter how successful with getting it to work as required on the CLI, ASDM would always drop the user straight into level 15 access (full rights), or sometimes, no access at all.
So I turned back to LDAP, as I want to avoid implementing TACACS+ for this sole purpose. LDAP has already been working successfully so far, but then its just looking at one security group, an the expected result is either permit or deny, based on whether the user is found in that group. Extending this should therefore not be too hard.
The issues arose from the fact that we have differing levels that need to be addressed, so lets have a look at these.
So at the moment I had, in my LDAP attribute map, the IEFT-Radius-Service-Type which was mapped to memberOf, and in turn this references either the sec-fw-admin group at level 7, or the sec-fw-ro at level 6.
TestASA# sh run ldap attribute-map test4
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "cn=sec-FW-Admin,OU=Security Groups,DC=802101,DC=local" 6
map-value memberOf "cn=sec-fw-ro,OU=Security Groups,DC=802101,DC=local" 5
But this still lets a member of sec-fw-ro in at level 15 on ASDM and the CLI. If you try to re-map memberOf to another value, which would have been the obvious and easy choice, then you quickly find that you can't map it twice to two different attributes.
TestASA# sh run ldap attribute-map test4
map-name comment Privilege-Level
map-value comment fw-ro 5
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "cn=sec-FW-Admin,OU=Security Groups,DC=802101,DC=local" 6
map-value memberOf "cn=sec-fw-ro,OU=Security Groups,DC=802101,DC=local" 5
Results in the testnps account being able to log into ASDM, at the correct level (5), but my own account is denied access:
TestASA# sh run ldap attribute-map test4
map-name comment Privilege-Level
map-value comment fw-ro 5
map-value comment fw-rw 15
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "cn=sec-FW-Admin,OU=Security Groups,DC=802101,DC=local" 6
map-value memberOf "cn=sec-fw-ro,OU=Security Groups,DC=802101,DC=local" 5
Well, actually it took me longer than I had expected. Through testing I used my own account, and a test account called testnps. My account is a member of sec-fw-admin, and the test account is a member of sec-fw-ro.
Radius as we have seen in previous posts offers the Cisco-AV-Pair which we have successfully used, but try as I might, no matter how successful with getting it to work as required on the CLI, ASDM would always drop the user straight into level 15 access (full rights), or sometimes, no access at all.
So I turned back to LDAP, as I want to avoid implementing TACACS+ for this sole purpose. LDAP has already been working successfully so far, but then its just looking at one security group, an the expected result is either permit or deny, based on whether the user is found in that group. Extending this should therefore not be too hard.
The issues arose from the fact that we have differing levels that need to be addressed, so lets have a look at these.
IETF-Radius-Service-Type
The IETF-Radius-Service-Type can be one of a three values, either 6 which is Administrative and allows full access, 7, which is NAS-Prompt, whereby the user cannot access privileged EXEC mode through the enable command, or 5 which is "Outbound" - meaning no administrative access at all. This page from Cisco's website gives some more information.ASDM defined user roles
These can be either be 15, offering full access, 5, which is read-only, and 3 which is Monitor Only and only allows access to the monitoring section. To set up the predefined roles from within ASDM click on the button labelled "Set ASDM Defined User Roles" under Configuration > Device Management > Users/AAA > AAA Access > Authorization.So at the moment I had, in my LDAP attribute map, the IEFT-Radius-Service-Type which was mapped to memberOf, and in turn this references either the sec-fw-admin group at level 7, or the sec-fw-ro at level 6.
TestASA# sh run ldap attribute-map test4
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "cn=sec-FW-Admin,OU=Security Groups,DC=802101,DC=local" 6
map-value memberOf "cn=sec-fw-ro,OU=Security Groups,DC=802101,DC=local" 5
But this still lets a member of sec-fw-ro in at level 15 on ASDM and the CLI. If you try to re-map memberOf to another value, which would have been the obvious and easy choice, then you quickly find that you can't map it twice to two different attributes.
Eventually I found this article on the Cisco website, which pointed me in the right direction. Now the solution in the article is this:
ciscoasa# sh run ldap attribute-map LDAPreadonly
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "CN=Account Operators,CN=Builtin,DC=MCS55,DC=com" 6
map-name sAMAccountName Privilege-Level
map-value sAMAccountName "ashishv" 5
ciscoasa#
There are two issues with this.
One: Members not explicitly stated will be denied access
Two: It does not scale well
So lets solve the second part first.
The method above would mean that for every user with admin access, or with monitor access a seperate entry needs to be explicitly set within the attribute map. This is fine if you only have maybe one, or two, of each and only one firewall, but when you organization scales this means that with every staff change (staff leaving, new staff starting etc) you have to change the attribute map, and potentially with a large number of firewalls this could take some time.
I found a list of AD attribute fields to use, and found one that would usually be unused, and therefore fit for purpose. Hidden away within AD is a comment field. We can find this under Attribute Editor after enabling Advanced view in ADUC.
I added the comment fw-ro for the testnps account.
There are two issues with this.
One: Members not explicitly stated will be denied access
Two: It does not scale well
So lets solve the second part first.
The method above would mean that for every user with admin access, or with monitor access a seperate entry needs to be explicitly set within the attribute map. This is fine if you only have maybe one, or two, of each and only one firewall, but when you organization scales this means that with every staff change (staff leaving, new staff starting etc) you have to change the attribute map, and potentially with a large number of firewalls this could take some time.
I found a list of AD attribute fields to use, and found one that would usually be unused, and therefore fit for purpose. Hidden away within AD is a comment field. We can find this under Attribute Editor after enabling Advanced view in ADUC.
I added the comment fw-ro for the testnps account.
So now we can, for the appropriate users add this comment in for use in the attribute map.
So implementing this with a slight change to:
map-name comment Privilege-Level
map-value comment fw-ro 5
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "cn=sec-FW-Admin,OU=Security Groups,DC=802101,DC=local" 6
map-value memberOf "cn=sec-fw-ro,OU=Security Groups,DC=802101,DC=local" 5
Results in the testnps account being able to log into ASDM, at the correct level (5), but my own account is denied access:
So this takes us back to the first issue, and we must therefore add a second attribute:
map-name comment Privilege-Level
map-value comment fw-ro 5
map-value comment fw-rw 15
map-name memberOf IETF-Radius-Service-Type
map-value memberOf "cn=sec-FW-Admin,OU=Security Groups,DC=802101,DC=local" 6
map-value memberOf "cn=sec-fw-ro,OU=Security Groups,DC=802101,DC=local" 5
I added the comment "fw-rw" to my account, and this works in the desired way, the testnps account has level 5 access and my own account has full admin access at level 15.
So now we have a method to separate admin and monitor only access to the firewall, and it is also scalable within the enterprise environment.