ASA Local Authentication Using Active Directory

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.

Prep

  • Create a group in Active Directory 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.

Do it

1. Log in to the ASA with ASDM (CLI steps below)

2. Go to Device Management > Users/AAA > AAA Server Groups

ad1

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.

ad2

4. Left-click the Server Group you just created.

ad3

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 works in most cases, it will just be slower in large domains.
  • The Naming Attribute should be samaccountname
  • The Login DN is the full LDAP attribute value of the service account the ASA will use to bind to LDAP.
    • Where CN is the users account name and OU/CN is the folder the account resides, i.e.: CN=BindAcct,OU=Users,DC=MyDomain,DC=Com
    • NOTE: For Microsoft, the default Users folder is designated by CN=Users, not OU=Users. If you have a separate folder where your service account is stored, it will be likely be designated by OU=Folder. Take a look at the troubleshooting info at the bottom of the article to find out for sure. .

For now the LDAP attribute map drop-box is empty. We will create that in the next step.

asaredo2

6. Expand LDAP Attribute Map and click Add. This is where the magic happens. We will designate the group we want to be admins on the ASA in this section.

  • Name the LDAP Attribute Map
  • Set the LDAP Attribute Name to memberOf
  • Pick IETF-Radius-Service-Type as the Attribute Name
  • Click Add >>

ad5

7. Click the Mapping of Attribute Value tab

  • Enter the “Group” in your LDAP directory that contains the users that you want to have administrative rights to the ASA. Typically it will be in the format below (CN=ASA Admins,CN=Users, DC=Mydomain,DC=com).
  • Set the Cisco Attribute Value to 6
  • Click Add >>

asaredo3

The entry should look like this at the end. Notice the =6 appended to the end.

asaredo4

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 has generically been 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 had success with 1 (=1) and 6 (=15), but test different values if you have varying requirements–your results may vary.

ad7

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.

ad9

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)

ad10

10. Click Apply in ASDM

CLI Equivalent

  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

Make it Work

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

ad11

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 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:

ad12

2. Click Apply

CLI Equivalent

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 (troubleshooting section on the bottom of this article), something is most likely wrong.

  1. Check the Enable box under Require authentication... and pick LDAP from the drop-down.

ad13

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.

ad14

CLI Equivalent:

  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.

  1. Go back to the Authentication tab and change HTTP/ASDM to LDAP.
  2. If you want to protect the serial terminal you can optionally do that

ad15

Validate everything works by logging in to SSH/ASDM with a user that is in the ‘ASA Admins‘ group and one that is not.

Troubleshooting

  1. Open Active Directory Users and Computers
  2. Click View > Advanced Features to enable it
  3. Right-click any object (user, folder, OU) and click properties.
  4. Click Attribute Editor
  5. Look at the Attribute distinguishedName

This attribute is the format the ASA needs in the fields we covered above. Sometimes it will give you a hint as to something you typed wrong or wasn’t what you thought it was.

One thought on “ASA Local Authentication Using Active Directory”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s