Active Directory VPN Authentication with a Cisco ASA 5510 Series Appliance
For months I stared blankly at the new ASA 5510 I had purchase and installed, and decided to take a step into the Cisco world of Firewall and VPN management....The biggest hurdle I had faced, was the one that justifed the money I had just spent on the device, that being Secured, Controlled, Flexible, Manageable VPN Access....
So, as any Active Directory Nut would do, I decided to backend this onto AD...Which sounds nice and easy in theory, but despite the amount of documentation out there, i found it surprising that none showed a simple easy to follow example....so with persistence, and trial and error and many attempts, I finally have my VPN setup working nice and smoothly. I played with SSL and IPSEC tunnels to meet my companies requirements, and the ASA is a very powerful and flexible tool when you get into the nitty gritty, for this example I will focus purely on the IPSEC side of things....
Here is how to setup Active Directory User Based Authentication with Secured Network ACL's to control traffic based on Group membership in AD....
Part 1 AAA Server Groups
Configuration -> Remote Access VPN -> AAA/Local Users -> AAA Server Groups
Create a new AAA Server Group for LDAP Authentication
Add your LDAP Server/Domain Controller as a server in the AAA Group you just created
Fill out the details of your domain controller and an account allowed to query
NB: your Naming Attribute must be sAMAccountName (This is case sensitive)
NB: Despite many articles saying you need LDAP Attribute MAPS configured, you do not for this process, you can leave the attribute Map as Blank
You can test authentication back to Active Directory by using the test option under your Servers Box
This result confirms that your ASA is talking to the Domain Controller and Authenticating based on the their logon Account name in AD (sAMAccountName)
Part 2 Connection Profiles
Configuration -> Network (Client) Access -> IPSec Connection Profiles
We must now create a profile for our Remote Access Connection
I am working on the assumption that you have already enabled your “outside” interface for IPSec Access.
Select Add to create a new profile
è Name: Enter a Name for your Profile
è IKE Peer Auth: Enter details if you require (not used in this example)
è User Authentication: Here we add the LDAP Server group you created in step one
è Client Address Assignment: here you select your VPN IP Pool (assumed created)
è Default Group Policy: For basic functionality, we are configuring using the default, we can edit and create more for advanced VPN configuration if required – for this example, leave as default. Enabled your required options (IPSEC) and (L2TP)
è Say OK
You have now setup the ASA to authenticate VPN users based on Active Directory Username and password
Part 3 Dynamic Access Policies
Dynamic Access policies at their most basic allow us to configure attributes, group policies, book marks, ACL’s etc into a single policy applied to a user when they logon. This allows for granular control on each user that authenticates or on a group of users
Configuration -> Network (Client) Access -> Dynamic Access Policies
By default, you will find a single Dynamic Access Policy (DAP) named DfltAccessPolicy, if you look at the properties of this policy, you will notice the default action is “continue”
This means, that all users that match the default criteria, will be allowed to authenticate and connect to the VPN.
Firstly, we need to change the default action to Terminate, which means by default, no one can connect.
Now we move onto configuring access.
Select “Add” to create a new policy
Assign a policy name and description
Next, we specify the attributes that we want a user to match before being allowed to logon. In this case, we are going to specify a group in Active Directory, Called “VPN Users”, So any users who are a member of this group, can authenticate and logon.
We do this by selecting “user has all of the following attributes”
This means that unless the user meets all the specified attributes, they cannot logon. In our example, we are using a simple single value of group membership
Select the “add” button
In the “AAA Attribute Type” Dropdown, select LDAP
The “Attribute ID” will auto fill the “memberOf” Attribute which is an established LDAP Attribute
You can select the “Get AD Groups” button, which will query AD for all groups (As specified in your AAA Server group in step 1)
Select your VPN Users group and say ok
Say OK Again
You will now see that your DAP has a configured LDAP attribute
We are going to ignore the endpoint attributes at this stage as this is more advanced configuration for later.
Note under the “Access /Authorization Policy Attributes” our default action is set to “allow”
When a user tries to authenticate, it will first check this policy, check the users group membership in Active Directory and if the user is confirmed as a member of the “VPN Users Group” the policy will allow a authorise a connection and the ASA will establish the tunnel
If the user is not a member of the “VPN Users Group” in Active Directory, the policy will be ignored, and the “dfltAccessPolicy” will apply, terminating the connection attempt.
At this point, you now have the ASA setup to
a) Perform LDAP Lookups to Active Directory to check the user exists
b) Perform a group membership lookup to determine the users membership
c) Allow or disallow connection based on the Membership returned from the lookup
Now, this is the foundation for your Active Directory Group Membership based VPN Authentication, what you need to do now, is apply some basic attributes to the DAP to further restrict your users.
Note that these DAP’s apply to both IPSEC and SSL tunnels respectively, so not all tabs are used for both, eg, the “Web-Type ACL Filters” and “Bookmarks” are only applied to SSL Connections. The DAPs also allow us to allow or prevent different types of connections...
Part 4 Network ACL-Filters
As a final part of this basic guide, we will apply a network ACL filter. This will ensure that once our tunnels are authenticated and established, traffic is controlled to only specific resources.
These ACL’s are configured separately from our normal firewall ACL List, and only apply where specified in a DAP, meaning that we can apply a specific ACL to a user when dialled in via VPN, and we don’t affect any other firewall ACL settings
Under our Network ACL-Filters TAB in our Attributes portion of our new DAP, we can assign and manage our ACL’s
In the example above, we are assigning our VPN-Support-IT-Test ACL which does the following
1) Allows the entire IP stack from the VPN Subnet (which your user will of course be a part of when they dial in) through to your designated subnet – this allows all traffic
2) Allows only the RDP protocol through to Subnet number 2 (this depends on your subnets)
These ACL’s can be managed from configuration -> Firewall -> Advanced -> ACL Manager also
It is important to note, that the DAP’s can only contain ALLOW or BLOCK entries, they cannot contain both
It is also worth noting that in the above example, this is the ONLY traffic allowed through, all else is blocked, so you must allow all traffic that you want through
Once we have built our policy we simply assign it to our DAP and we are done
Obviously we will want multiple policies to cater for our different group needs, we simply change our “memberOf” Attribute in each policy to match our AD groups and out Network ACL-Filters for the different access....
Sooo, what have we achieved?
a) Perform LDAP Lookups to Active Directory to check the user exists
b) Perform a group membership lookup to determine the users membership
c) Allow or disallow connection based on the Membership returned from the lookup
d) Apply a Network ACL to the connection to control resource access
Easy!