Background
We wanted to be able to run an SSL VPN for a second team (Team B) on one of our ASA pairs. It was important to give each team a different VPN pool for security reasons. The first team (Team A) ran their own tacacs+ server for authentication. We had leveraged that as the VPN authentication system with no issues. Team B already had a Active Directory (AD) deployment so the challenge was to get this working with the ASA and their new SSL VPN Pool.
ASA config
We needed two pieces of information from Team B.
1. The IPs of their AD Domain Controllers (DCs).
2. The AD realm
With this data we could create the following config.
aaa-server TEAMB_AD protocol kerberos aaa-server TEAMB_AD (outside_interface) host 192.0.2.1 kerberos-realm TEAMB.DOMAIN aaa-server TEAMB_AD (outside_interface) host 192.0.2.2 kerberos-realm TEAMB.DOMAIN tunnel-group TEAMB_GROUP type remote-access tunnel-group TEAMB_GROUP general-attributes address-pool TEAMB_VPN_POOL authentication-server-group TEAMB_AD default-group-policy TEAMB_POLICY no strip-realm strip-group tunnel-group TEAMB_GROUP webvpn-attributes group-alias teamb enable group-policy TEAMB_POLICY internal group-policy TEAMB_POLICY attributes dns-server value 8.8.8.8 vpn-tunnel-protocol ssl-client password-storage enable split-tunnel-policy tunnelspecified split-tunnel-network-list value TEAMB_SPLIT_TUNNEL webvpn anyconnect keep-installer installed always-on-vpn profile-setting
Since Team B have a group alias of ‘teamb’ at login which won’t be understood by AD, we strip that out. We don’t want to strip the realm though as that is needed by the AD server.
The VPN exists to allow Team B to manage some of their equipment, so the TEAMB_SPLIT_TUNNEL ACL simply defines the networks to which we wish to encapsulate traffic. NTP was also enabled and running on the ASA, which is a prerequisite of working Kerberized services. Finally we asked Team B to open up UDP port 88 inbound from our ASAs to their AS DCs. We asked Team B users to login with username@TEAMB.DOMAIN.
The second part of this post is going to be written by Jemima Spare, the Windows Administrator of Team B.
AD Settings
No real changes needed to be made on the domain. The Cisco documentation mentions the following settings to be made on the :
• Using Active Directory to Force the User to Change Password at Next Logon.
• Using Active Directory to Specify Maximum Password Age.
• Using Active Directory to Override an Account Disabled AAA Indicator
• Using Active Directory to Enforce Password Complexity.
These all seem there to mirror settings that you might want to make on the ASA, for example, if you want to make sure that the AD settings are not more or less restrictive than the ASA settings.
As password complexity and maximum password age settings were adequate, no changes were made.
The Team A requested IP addresses of the AD servers and the AD realm. IP addresses were straighforward and the AD realm could be checked by running set USERDNSDOMAIN on the command line on a domain controller. In this case, it was the same as the Fully Qualified Domain Name (FQDN).
The firewalls in front of the domain controllers had to be opened up to allow UDP 88.
Having done all of the above, we tried to connect and failed. Part of the troubleshooting involved checking the logs on the domain controllers’ firewall, and this was where we were able to see that the ASA was using TCP port 88 and not UDP port 88. The change was made to the firewall and voila! the vpn connected.