We have two connectivity methods that require user authentication, VPN and wireless. Specifically, regarding wireless, we have two main SSIDs, one for guests and one for network users. Guest Access only allows users connected to get to the Internet. Access lists on our routers prevent devices on the Guest VLAN from accessing our network resources. Anyone can connect to this SSID.
Network LAN access is made available by a second SSID. Our Cisco Wireless LAN Controller allows only authenticated users onto this WLAN. Currently, it is configured to use one of our old DCs as a RADIUS server for this purpose. User who connect have two requirements; 1)valid AD account, and 2)membership in a specific AD group. I am hoping to migrate this to our new domain very soon.
Our Cisco ASA5510 was also configured to use our old DC as a RADIUS server to authenticate VPN clients. Like wireless, users had to have a valid AD account and be a member of a ‘Valid VPN Users’ AD group to be granted access. Yesterday, we did some work to move VPN authentication to our new AD Domain. The biggest win, I think, was switching from RADIUS to LDAP as the mechanism for this. With LDAP, there is no need to make any changes, or install anything additional, on our DCs. This is big, as it helps keep my DCs clean and uncomplicated, minimizing the roles required to run on these machines.
I am going to try and share some screencaps of the config… we will see how much I need to ‘blur out’. Hopefully, they will still be helpful and informative.
The big change we made was in the AAA Server Groups area on the ASA5510.
- We created a new AAA Server Group, just calling it ‘LDAP’.
- Under ‘Servers’, I added one of our DCs. The config is as follows:
- Server Name or IP Address – Just the IP of my DC
- Base DN – The DN of the container for my user accounts
- The ‘Scope’ setting allows for more than one level beneath the Base DN, so if you need to search a larger section of AD, you easily can.
- Login DN and Login Password: Credentials for a domain account used for AD lookups. This account doesn’t need access to anything, just needs to be able to authenticate in AD.
- Group Base DN: This is the DN to the location of the group that users much be a member of to gain access.
With this set up, I then needed to modify the Connection Profile used for VPN, as well as the Group Policy. Group Policy first:
- I copied the existing Group Policy into a new one and changed the required settings.
- The only change I made was on the “Servers” menu item, changing the DNS Servers, WINS Servers, and Default Domain to all point to our new AD domain.
After the new Group Policy was created, I updated my Connection Profiles as needed:
- On the ‘Basic’ menu, I changed the AAA Server Group to my new LDAP server group.
- I changed the Group Policy to my new group policy.
The last step was getting the ‘group membership’ requirement activated. This is done under ‘Dynamic Access Policies’ (DAP). We originally only had one DAP, the default, named DfltAccessPolicy. This is a catch-all policy that is applied if no other policy matches the authenticating user.
- I created a new DAP:
- Selection Criteria
- AAA Attribute Type: LDAP
- Attribute ID: memberOf
- Value: = <name of AD group user must be a member of>
- There is a “Get AD Groups” button that should access your AD and pull a list of groups, if your AAA Server settings are correct.
- Under ‘Access/Authorization Policy Attributes’
- Action: Continue
- Changed the action on the ‘DfltAccessPolicy’ to “Terminate”
VOILA! Users authenticating, via LDAP, against my AD with group membership requirements. Obviously, things can get much more complicated and granular. But, for us, this is working perfectly.
* Got to give another shout-out to BriComp Computers for their help with this. He helped me with everything but the ‘group membership’ part of this. Gave me a huge head-start!
Now, on to figuring out the WLC…