There are a few steps you should follow before you configure it on the dashboard.
Integrating with Client VPN
The Cisco Meraki MX Security Appliance supports Active Directory authentication with Client VPN, so a client will be required to provide domain credentials in order to connect via VPN.
Traffic Flow
When a user attempts to connect to Client VPN, the following process occurs:
- The user's device attempts to establish a VPN tunnel using L2TP over IP.
- The user provides their valid domain credentials.
- The MX, from its LAN IP, queries the Global Catalog over TCP port 3268 (encrypted using TLS) to the AD server configured in Dashboard.
- If the user's credentials are valid, the AD server will send its response to the MX, completing authentication.
- The MX offers the client an IP configuration on the Client VPN subnet, and the client can start communicating on the network.
Note: At this time, the MX does not support mapping group policies via Active Directory for users connecting through the Client VPN.
Configuration Overview
In order to configure Active Directory authentication for Client VPN, configuration steps must be completed on both Dashboard and Active Directory, outlined below:
Active Directory Configuration
The following requirements must be configured on each AD server being used for authentication:
- Every AD server specified in Dashboard must hold the Global Catalog role.
- Since communication between the MX and AD server will be encrypted using TLS, a valid certificate with the appropriate parameters must be configured on the server.
- If no certificate is present, it will be necessary to install a Self-Signed certificate.
- If a certificate already exists, please ensure that it has been configured with the necessary parameters for TLS.
- The MX will communicate from its LAN IP with each AD server over TCP port 3268, ensure that no firewalls or ACLs on the network or server will block that communication.
When Active Directory authentication is configured, the MX queries the Global Catalog over TCP port 3268. Therefore the Active Directory server (Domain Controller) specified in Dashboard must also hold the Global Catalog role.
Dashboard Configuration
Once the AD servers have been primed with the configuration requirements outlined above, the following steps outline how to set up AD authentication for Client VPN:
- In Dashboard, navigate to Security & SD-WAN > Configure > Client VPN
- If Client VPN has not yet been enabled, please refer to our Client VPN documentation for info on initial configuration.
Note: In order for Client VPN users to be able to resolve internal DNS entries, the Custom nameservers option should be configured with an internal DNS server. The server's firewall may need to be adjusted to allow queries from the Client VPN subnet, and best practices dictate that a public DNS server should be listed as a secondary option.
- Set Authentication to Active Directory.
- Under Active Directory server, provide the short domain name and server IP, as well as the credentials for an AD domain admin.
Note: If the credentials provided do not have domain admin permissions, the MX will be unable to query the AD server.
- Click Save Changes.
Client Configuration
Clients can use their native VPN client to connect to Client VPN, with or without Active Directory.
Please refer to our Client VPN documentation for OS-specific configuration steps.
(Optional) Client Scoping
Due to the nature of Active Directory authentication for Client VPN, all domain users will be able to authenticate and connect to Client VPN. There is no Dashboard-native way to limit which users can authenticate, however, there is a workaround in Active Directory that allows the scope of users to be limited by specifying a domain administrator with limited group visibility.
The following article outlines how to configure this workaround for wireless networks, but the same principles can be applied to Client VPN: Scoping Active Directory per SSID
Note: This configuration is entirely reliant on Active Directory. Depending on how domain groups are managed, this may not work some environments - please refer to Microsoft documentation and support for assistance with Active Directory configuration.
User permissions for AD integration
While the AD integration account does not have to be a domain admin, it is usually the easiest way to implement this feature. If using a domain admin account is not possible or not preferable, ensure that the account has the necessary permissions to perform the following actions:
- Query the user database via LDAP
- Query group membership via LDAP
- Query the domain controller via WMI
Testing
Once the configuration above has been completed, the Meraki device should be able to communicate with the Active Directory server using TLS. If this fails, Microsoft offers the Ldp.exe tool to ensure that the LDAP service is running and compatible with the current certificate.
Please reference Microsoft documentation for error code details and troubleshooting assistance.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.
Please, if this post was useful, leave your kudos and mark it as solved.
