We're wrapping up a large enterprise network project and are deploying Cisco Secure Client VPN for employees who work offsite. The plan is for users to authenticate with their Active Directory accounts, and the Meraki appliance is on the same subnet as the domain controller, so using Active Directory authentication seemed like the obvious choice.
However, I need to limit VPN access to approved users rather than allowing everyone with a valid domain account to connect. I expected to be able to use an Active Directory security group, but I can't find an option in the Meraki dashboard to restrict access that way. I'm now considering alternatives such as deploying RADIUS, organizing users into separate OUs or domains, or using another identity provider.
What is the cleanest way to authenticate against AD while allowing only members of a specific group to use the VPN?
3 Answers
If you have Microsoft 365 or Entra ID available, SAML is usually the cleanest approach. You can assign VPN access to a specific group and add conditional access policies, including MFA. It avoids building and maintaining a separate RADIUS service.
SAML can work well if the identity platform is available, but it generally isn’t a replacement for the traditional pre-domain-login workflow. If the goal is to let a user establish VPN connectivity before signing into a domain-joined computer, check the Cisco Secure Client and Meraki support for the required login and authentication flow. For an on-premises deployment today, AD-backed RADIUS with an access group is the most straightforward design.
MFA should be part of the decision as well. Whether you use SAML or RADIUS, avoid exposing a VPN that relies only on an AD username and password if you have a reasonable way to add another factor.
For a traditional on-premises AD setup, RADIUS is probably the practical solution. Put the approved users in an AD security group, have the RADIUS server authenticate against AD, and configure a network policy that permits only that group. Then point the Meraki VPN authentication at RADIUS. This gives you group-based access without having to split users across OUs or domains.
We do have AD groups intended for Cisco VPN access, although they may currently be used through another system that provides the authorization layer. The important part is verifying that the RADIUS policy checks group membership rather than merely validating the password.
We don’t currently have Entra configured, and the Microsoft 365 users don’t line up with the people who need VPN access. One of our upcoming projects is expanding Active Directory, though, so SAML may become a better long-term option.