I had a heck of a time figuring out how to set this up. Cisco’s documentation related to LDAP authentication is all over the place and there isn’t one article that describes just this. If you want to use Microsoft Active Directory to authenticate users locally logging in to the ASA and give them privileged exec access based on a Group, here are the steps.
These steps assume you are using ASDM, but I have attached the CLI equivalents as well.
- Create an AD group that will be used to define access to the ASA. I.e. ASA Admins.
- Create a service account (password not expiring unless you want to change it in AD and your ASA every month) that will be used by the ASA to bind with AD.
1. Log in to the ASA with ASDM (CLI steps below)
2. Go to Device Management > Users/AAA > AAA Server Groups
3. Add a AAA Server Group by clicking Add on the top-right
- Enter a name for the Server Group
- Pick LDAP as the protocol
- Enter 1 for the Realm-id
- Change any other settings as you see fit. The defaults will work.
4. Left-click the Server Group you just created.
5. Click Add on the window half way down.
- Pick the Interface that the ASA will be able to reach your DC’s through
- Type in the IP address of your domain controller
- Pick Microsoft as the Server Type
- The Base DN is your domain suffix, enter that in the format below
- Depending on the hierarchy of your domain, the scope can be one level or all levels beneath the base DN is required. If you’re not sure, all levels beneath base DN will work, it will just be slower in large domains.
- The Naming Attribute should be samaccountname
- The Login DN is the LDAP value of the service account the ASA will use to bind to LDAP.
- For now the LDAP attribute map drop-box is empty. We will create that in the next step.
6. Expand LDAP Attribute Map and click Add. This is where the magic happens.
- Name the LDAP Attribute Map
- Set the LDAP Attribute Name to memberOf
- Pick IETF-Radius-Service-Type as the Attribute Name
- Click Add >>
7. Click the Mapping of Attribute Value tab
- Enter the “Folder” in your LDAP directory that contains the users that will be authenticated against the ASA. Typically it will be in the format below (CN=Users, DC=Mydomain,DC=com).
- Set the Cisco Attribute Value to 6
- Click Add >>
The entry should look like this at the end. Notice the =6 appended to the end.
Note on the Attribute Value:
The Cisco Attribute Value is a Radius association that we will use to map a User Group to a privilege level on the ASA. I opened a ticket with Cisco to try to decipher what these correlate to in terms of privilege values (1-15) and wasn’t able to get anything clear back.
It appears it is something unique to Radius policies that can generically be applied to LDAP/Local policies to expand the functionality of the ASA.
Cisco doesn’t have documentation that makes it clear. i.e. IETF-Radius-Service-Type 6 = ASA Privilege 15. The image below is the best I could find from Cisco. I have only tested 5 and 6, but test different values if you have varying requirements–your results may vary.
At this point you have an LDAP attribute map. Only one can be applied to a server group at a time. So if you have multiple groups to check, enter them as additional lines in the Attribute Value Mapping section.
8. Highlight the Server group with the IP of the domain controller, and click Edit
9. For the LDAP Attribute Map, pick the Mapping you just created (Group-Check)
10. Click Apply in ASDM
ldap attribute-map Group-Check map-name memberOf IETF-Radius-Service-Type map-value memberOf "CN=ASA Admins,CN=Users,DC=MyDomain,DC=Com" 6 aaa-server LDAP (MGMT) host 192.168.10.3 ldap-base-dn DC=MyDomain,DC=Com ldap-login-dn CN=BindAcct,OU=Users,DC=MyDomain,DC=Com ldap-login-password ********** ldap-naming-attribute samaccountname server-type microsoft ldap-attribute-map Group-Check exit
What we have done was simply to create a Server Group and a LDAP Mapping. We need to assign it to a connection type to actually use it.
1. Go to Device Management > Users/AAA > AAA Access
What we need to do is assign this group to a connection type. I would advise to test one type (i.e. SSH) using LDAP while retaining another (i.e. ASDM) as Local to make sure you have the LDAP properties correct and don’t lose access.
Since we are using ASDM, first enable SSH authentication with LDAP. Enabling this way will simply give every user in the domain access to the ASA, which we obviously don’t want, but just use this as an initial test. This is how that looks:
2. Click Apply
aaa authentication http console LOCAL no aaa authentication ssh console LOCAL aaa authentication ssh console LDAP LOCAL
If you’re able to log-in with AD credentials, now we want to only give members of the IETF-Radius group mapping access to privileged mode. If not, check the LDAP strings, something is most likely wrong.
- Check the Enable box under Require authentication... and pick LDAP from the drop-down.
Note on LOCAL when group fails:
The ASA won’t warn you from the login-prompt if AD is not working (use local when group fails)—be aware that if you know the DC is down and your AD account is the same as local, enter local ASA password. It would be a good idea to have an ‘admin’ account unique to the ASA that will work when the DC’s are down.
2. Secondly you have to click the Enable box under the Authorization tab for ‘Perform authorization for exec shell access‘. Optionally pick the ‘Allow privileged users to enter into EXEC mode on login‘ to be dropped into privileged exec mode on login if you have access.
aaa authentication enable console LDAP LOCAL aaa authentication http console LOCAL no aaa authentication ssh console LOCAL aaa authentication ssh console LDAP LOCAL aaa authorization exec authentication-server
If you are able to login and run privileged commands ASDM connections can be applied to the LDAP authentication type.
- Go back to the Authentication tab and change HTTP/ASDM to LDAP.
- If you want to protect the serial terminal you can optionally do that
Validate everything works by logging in to SSH/ASDM with a user that is in the ‘ASA Admins‘ group and one that is not.