Using Microsoft Active Directory as the Authentication server for an SSL VPN on a Cisco ASA.


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
 kerberos-realm TEAMB.DOMAIN
 aaa-server TEAMB_AD (outside_interface) host
 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
 tunnel-group TEAMB_GROUP webvpn-attributes
 group-alias teamb enable
group-policy TEAMB_POLICY internal
 group-policy TEAMB_POLICY attributes
 dns-server value
 vpn-tunnel-protocol ssl-client
 password-storage enable
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value TEAMB_SPLIT_TUNNEL
 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.

Posted in Cisco Networks, VPN | Tagged | Comments Off on Using Microsoft Active Directory as the Authentication server for an SSL VPN on a Cisco ASA.

Comments are closed.