We have a pair of ASA 5510s (8.4.3) on which we use LDAP authentication for VPN and SSH access. On all of our Catalyst switches, which use RADIUS, we're able to set the shell:priv-lvl to 15 in the RADIUS config (2008R2 NPS). However, the best I can find on the ASAs, including in all the Cisco docs, is to abuse some other field, such as title or company, by sticking "15" into it and mapping that to the Privilege-Level RADIUS attribute in the AAA config. What I really want to do is assign anyone in an AD group L15 privs on the ASAs without having to type in a shared password. Anyone know if there's a way to do this?
Ldap – Cisco ASA LDAP Group Privilege Level
aaaciscocisco-asaldapradius
Related Solutions
I understand your pain, research and practice are going to be your best friends. Here are some of my bookmarks for dealing with the Cisco devices:
- Demystifying the Cisco ASA:
http://episteme.arstechnica.com/eve/forums/a/tpc/f/469092836/m/447004091931 - 8 Basic commands for configuring your Cisco ASA:
http://blog.soundtraining.net/2008/04/eight-basic-commands-to-configure-cisco.html - Anatomy of an Access List:
http://i.cmpnet.com/nc/907/graphics/access.pdf - Cisco 'Hands-on Training' Podcasts: (Lot's of free video on Cisco CLI - Highly recommended!)
http://ciscohandsontraining.com/
Best of luck!
You're going to want to stick with creating/ordering Network Policies to do what you're trying to do. Just use the one default Connection Request Policy that is wide open, and then secure via the NPs.
You can "divide the two" as you say, by limiting each Network Policy you've created with sufficient conditions, such that in combination, multiple conditions together achieve your objectives. It looks like you've specified only one condition on each policy - network group membership. As you've discovered, this won't work. When your RADIUS-enabled device asks your RADIUS server to authenticate your user, the RADIUS server forwards the users' credentials to AD, which successfully matches the credentials (cause they're vague at this point), and returns a positive to the RADIUS server, which in turn tells the device to allow the authentication. I'm forgetting all the proper RADIUS lingo here - but basically that's what's happening.
So, stack another condition (or more) onto your policy to get what you want. Sounds like you want the switch policy to work with users in the Domain\NetworkGroup, and only on your switches (these requests should never come from your ASA's IP, or some printer or user workstation or whatever). Under conditions, look under the RADIUS client section - ClientFriendlyName, or ClientIPv4Address, for example. If the conditions include that the request is coming only from one of your predefined switch IPs or names, it won't "authenticate" requests coming from your ASA IP.
Do the same for your vpn policy too. You should be good from there. You may want to start with clean Network Policies though. I don't think you're going to be able to use the settings to update non-compliant clients without some more work (and whole other policy type too).
Also, you can look at your RADIUS logs if you want more info on what its actually doing. I believe they're under system32\logfiles. You may have to enable it on your NPS server, if its not already. You can google for tools to help you read the log files, as they're not really user friendly. In a pinch, MS has an article that lists all the fields, in order. Look for the tools though (IASlogviewer? or something like that?).
Best Answer
If you do not mind using LDAP you can do exactly what you need without changing anything on the server infrastructure.
The way that we do ASA LDAP integration is to us the memberOf LDAP attribute to trigger a match on the value we want to edit. For cli AAA you can configure the following attribute map:
This sets the service-type to 6 (admin) for any users that log in and match that group. Next define a new AAA Server Group to use just for device administration, you do not want to break your attribute-maps for vpn users.
Now create a server entry for your LDAP server, this can be to the same server that you use for VPN or other LDAP functions.
The last line
ldap-attribute-map NetworkAdministratorsis what associates the ldap-map to your authentication server.Finally lets bring all the work together and apply it to the ASA AAA section:
So to test you can no ssh to your ASA and user your LDAP user, you should then be able to get logged in without issue. Now when you enter
enablemode you will get prompted for a password. You will then use your unique LDAP password for authentication.Please test this completely on your equipment, because if improperly configured on your ASA could let any LDAP user admin privileges on your ASA.