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

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

ad4

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

ad5

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

ad6

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

ad8

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.

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

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

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

Advertisements
ASA Local Authentication Using Active Directory

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={$_.name};Label=“Account Name”},`

@{Expression={$_.whencreated};Label=“Created”},`

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

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

@{Expression={$_.enabled};Label=“Enabled”}

 

#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 you@domain.com -Subject “AD Account Report” SmtpServer 192.168.1.1 -From server@domain.com -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

–>

Powershell: Find stale Users