I seem to be working on a lot of ASA’s and Sourcefire lately and I always end up connecting to AD for authentication of some sort. I thought I should document what I do and why.
- If I want to authenticate VPN users, I create a AAA group specifically for that.
- If I want to authenticate administrative sessions, I create a specific group for that as well. Why? Read on.
Let’s start out easy and progress from there. First let’s create the AAA group and add a couple of servers. I’m a CLI guy, but ASDM is easier for some of this so you’re going to get some of that today.
Let’s break down the more confusing parts. First is Scope. You should almost always set it to All levels beneath Base DN. This will allow the ASA to search the entire tree. Next is the Login DN. Here is where it can get confusing for some people. This is the full DN of the user that will be binding to AD for lookups. This account needs nothing special and I usually ask my customers to make is a read-only account. You can (and should) get the full DN from the User Account in AD. If you’re LDAP savvy, you can also use an LDAP browser.
If you look close you’ll see that part of the DistinguishedName is the displayName. Not the username, the displayName. This accounts username is actually sfr-svc, but that is not part of the DN. Always try and copy-n-paste the LDAP attributes and paths! We enter the password for the account and Apply. Use the test button to verify it’s working. If it is not, check all the syntax and “debug ldap 255” on the ASA. We can authenticate everyone, yah good…..wait, everyone…that’s bad. Yep, but we’ll start “locking it down”.
First lets tackle Administrative sessions (SSH/ASDM). Since we don’t want everyone to be able to access the ASA, lets set who can login and at what privilege level. I have Mark M. who gets level 15 and Mike R. who only gets level 3. Level 3 will be a read-only level in the future. What wee need to do is create a mapping of an LDAP attribute to something the ASA can understand, an LDAP Attribute Map. Here’s a map that sets the privilege based on who they are in AD.
ldap attribute-map Admin-Mappings map-name sAMAccountName Privilege-Level map-value sAMAccountName mm 15 map-value sAMAccountName mr 3
This maps the SAMAccountName of mm (Mark M.) to level 15 and the SAMAccountName of mr (Mike R.) to level 3. If we debug ldap on the ASA and test a login we’ll see it mapping.
From the CLI we can also verify
PP-FIREWALL> show curpriv Username : mm Current privilege level : 1 Current Mode/s : P_UNPR PP-FIREWALL> en Password: **** PP-FIREWALL# show curpriv Username : mm Current privilege level : 15 Current Mode/s : P_PRIV PP-FIREWALL# exit
And if we check Mike R.
PP-FIREWALL> show curpriv Username : mr Current privilege level : 1 Current Mode/s : P_UNPR PP-FIREWALL> en Password: **** PP-FIREWALL# sh crupr PP-FIREWALL# show curpriv Username : mr Current privilege level : 3 Current Mode/s : P_PRIV
Excellent that part is working. Finally we apply this LDAP Attribute Map to our AAA Server Group. Go back into your Servers under your AAA LDAP Group and add the Attribute Map.
OK. We’re now setup to properly authenticate and set the privilege level for our Admins. Don’t forget to set this group as your SSH/Enable/HTTP preferred authentication method. One thing to note (and this should be an Aha! moment), we can only have one LDAP Attribute Map per server (per AAA group really). So if we want to authenticate VPN users using LDAP, this group will not work! Easy fix though, create another AAA group. We can use the same servers in multiple groups. Create a new AAA group and call it VPN-AUTH. Add your servers and credentials just like the first group we created. This group will now authenticate VPN users. However we need to make sure it will only authenticate VPN users, not all users. We have a couple of options. We could map AD groups to a Group Policy on the ASA or we can configure Dynamic Access Policies (DAP).