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.


  • 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


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


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


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


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


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

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

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


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:


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.


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.


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


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


  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.


F5 Local Authentication using Active Directory or LDAP


The following instructions will cover how to deploy Active Directory or LDAP authentication with the primary goal of logging in to the F5 device with LDAP credentials..

F5 provides a few key articles that build the basis for this summary. Found here, here and here.

Key Information

Local users with the same name as an AD user cannot authenticate with local password once Remote AD authentication is enabled. However, local rights overrule ‘External Users’ configuration.

Example: I have user bsmith local and in AD. bsmith is an admin locally, but ‘External Users‘ is configured as operator only.

Once bsmith authenticates, he will be an administrator on the box.

The built-in ‘admin‘ account is the only local account that will be able to authenticate if AD is down. Make sure you have the password documented.


  • Name & IP address of LDAP/AD server(s)
  • Distinguished Name of domain
  • Service account for binding to LDAP to monitor servers
  • Optional: Two LDAP/AD servers for HA configuration


Before starting it’s important to test from the command-line of the F5 to validate network accessibility and the LDAP search string.

What is my distinguished name?

If you’re using Microsoft Active Directory, follow these steps (make sure Advanced Features is on):

1. Open Active Directory Users and Computers

2. Right click the domain name at the top of the tree and click Properties

3. Under attributes you will see ‘distinguishedName‘ the value is important for the rest of these instructions. Capture it.

Pick a test user

A user will be needed to validate during some of our testing. Pick whatever user you’d like, but take note of what OU the user is in. If you are using Microsoft AD it may be in the Users OU.

Build Search String

Merge the information from the DN and user OU to build search string for testing. Here is an example:


User OU: users

User: myuser

Execute Test

ldapsearch is the utility used by the F5 for testing. Follow these steps to validate layer-3/4 connectivity and LDAP functionality.

1. SSH to the BigIP

2. Use the following format to test a LDAP query using ldapsearch:

ldapsearch -xLLL -H 'ldap://' -b "cn=users,dc=mydomain,dc=com" 
-D mydomain\\domain-user -w 'userspassword' '(samaccountname=myuser)'

Use ‘ldapsearch –help‘ to get more information about the flags.

3. Using the previous query should return a bunch of information about your user. If not, something is wrong with the syntax. Try different variations until you get it working.

If content is returned, we know that the F5 can reach our LDAP server (if it cannot, check that a self-IP exists on the same subnet as the LDAP server or a route exists) and that our DN string is correct for future configuration.

Create LDAP Monitor

A monitor is needed to probe the pool that will be created in the next step. The string created earlier can be used here.

1. Log in to the F5 UI

2. Click Local Traffic > Monitors > Create…

3. Enter a name, i.e. ldap-monitor

4. Under type select LDAP

5. Create an interval that makes sense to you, the defaults are usually fine

6. Under ‘User Name‘ put the user you created in the prerequisites. Ideally it is a service account with no interactive rights, simply used to bind to LDAP.

Important!! If you use a prefix to log on to your domain, i.e. domain\user  you must enter either domain\\user WITH TWO SLASHES or myuser@domain. I’ve had the best luck with the domain\\user format.

7. In the Base field, enter the OU we want to check (bind to).

It can be anything you’d like, but basically we are making sure the LDAP server serves up a response to our LDAP request.

I simply used the cn=users,dc=mydomain,dc=com

8. Under Filter enter the object you want to check. I used cn=Domain Guests since it is a built-in object and it is not used (if I probed Domain Admins the listing could potentially be intercepted and used for nefarious purposes).

9. If your server supports SSL/TLS optionally select one under the Security field.

10. Click Finished

Create LDAP Virtual-Server

This can be done on the local BigIP or a remote device that is accessible by the device LDAP authentication is being implemented.

The purpose of this is so that if an LDAP server fails, the F5 can continue authentication. Without this configuration the F5 must rely on a single server for authentication.

1. Log in to the F5 UI

2. Click Local Traffic > Virtual Servers > Create…

3. Enter any name, IP address (ideally on the same subnet as LDAP servers), Service port is 389

4. Protocol is TCP, with TCP profile

5. Add a Default Pool as a resource with the two domain-controllers in your environment on port 389.

6. Assign the monitor created in the previous step to this pool.

7. Click Finished

8. Create a DNS record for this virtual-server local to your environment, i.e.

Configure LDAP Authentication


Important Tip: Make sure you have an SSH and browser session already open to your device in-case you get locked out. The default local admin user will always be a fallback in the case this happens, make sure you have those credentials handy.

1. Click System > Users > Authentication > Change

2. Under User Directory select “Remote – Active Directory” or “Remote – LDAP” (I have not experienced any functional difference between these in practice).

3. Host is the DNS record we created in step 8 above. If you skipped the HA portion, just enter the A record for your LDAP server.

4. Remote Directory Tree: This is the OU or starting point for your user container.

Above we used cn=users,dc=domain,dc=com. Also, dc=domain,dc=com could be used, but why return all that content when the Users are only in one or a few OU’s?

If yours are in an OU under that, use the format cn=F5users,cn=users,dc=domain,dc=com

Most cases will be cn=users,dc=domain,dc=com

5. Scope: This determines the level of your search.

Important Tip: I’ve never gotten Base or One to work, only Sub.

6. Bind: Even though this is blue, inferring that it is mandatory, it is not. If you created a service account (we did for our monitor) and you only want this user to be used to bind, then go ahead and enter that user here.

Important Tip: Remember how in the monitor configuration we had to use double slashes? I.e. domain\user. For some reason the same does not apply here. Use only ONE slash. i.e. domain\user

I left the Bind fields empty and used the User Template setting. If a user can’t bind to begin with, why search for that user?

7. Under User template will attempt to use the user authenticating to bind (the F5 inserts the username typed in the User field for the %s), if they can’t bind (non-existent user) they won’t be looked up.

8. I’m not really sure what ‘Check Member Attribute in Group‘ does functionally (doesn’t Remote Role Groups cover this?), F5’s documentation is lacking here. I leave it unchecked.

9. Under Login LDAP Attribute enter samaccountname

10. In the External Users section assign the Role you’d like for authenticated AD users. Remember that if a local user matches remote, local rights supersede this configuration. Operator is a good choice if this is designed for sys-admins to do what they need.

11. Click Finished

Test logging in from a different browser session!! If all went well, logging in will work. If not something is wrong/missing. Look over the steps above again and make sure nothing was missed.

If not, troubleshoot using tcpdump


tcpdump is your best friend for figuring out what’s going on. Luckily LDAP is clear-text so deciphering syntax issues is fairly simple. F5 also has an article covering how to troubleshoot LDAP issues

1. SSH to the F5 performing the LDAP queries.

2. Use the following syntax to run a simple capture

tcpdump -s0 -ni 0.0:nnn -w /shared/tmp/ldapdebug.pcap 'host or host'

Replace the 10.x addresses with the IP’s of your LDAP servers.

3. Attempt a login from a browser.

4. Once it fails, stop the capture with ctrl-c

5. SCP the capture off the F5 (will be in the /shared/tmp directory)

6. Examine with Wireshark.

Look for syntax errors after “searchRequest” or “bindRequest” queries. The “bindResponse”, “searchResEntry” or “searchResDone” response will be a good indicator of the problem.

Powershell: Find stale Users

old user

Having old, unused user accounts sitting in your domain can send red-flags flying by auditors. It’s easy to create an account and think it will be used for the foreseeable future, but often times this is not the case.

This script queries your domain for user accounts that have not logged in in the past 6 months. It creates an HTML report and emails you the results. The email can be reviewed and action can be taken based on your discretion. I have added an option for you to un-comment which will automatically disable accounts that fit this criteria. Powershell v3 with the new Active Directory module is required for this to work.

<# Workflow

Query AD for users who have not

logged in in over 6 months.



#Import AD module

Import-Module ActiveDirectory


# 6 months ago

$6months = Get-date

$6months = $6months.adddays(-180)


$Format = @{Expression={$_.SamAccountName};Label=“User Login Name”},`

@{Expression={$};Label=“Account Name”},`


@{Expression={$_.passwordneverexpires};Label=“Password Never Expires”},`

@{Expression={$_.lastlogondate};Label=“Last Logon”},`



#Filter for users who havent logged in for 6 months as the basis of the filter. Add some additional properties.

Get-ADUser -filter { (lastlogondate -le $6months) } -properties * | Sort-Object lastlogondate | ConvertTo-Html $Format -Title “AD User Report” > .\Documents\Users.htm


#Send the email

Send-MailMessage -to -Subject “AD Account Report” SmtpServer -From -Attachments .\Documents\Users.htm


#Un-comment this line to automatically disable the accounts rather than send a report 

#Get-ADUser -filter { (lastlogondate -le $6months) -and (enabled –eq “true”) } | Set-Aduser -enabled $false