Home > Security Appliances > Group Policies and Blacklisting > Integrating Active Directory with Group Policies

Integrating Active Directory with Group Policies

Active Directory based Group Policy provides administrators the ability to apply Group Policy to client devices based on a user's group membership in Active Directory. This article explains how the feature works and provides a step-by-step implementation guide.

MX Security Appliance Group Policy Defined

Group Policy in Dashboard is a set of bandwidth limits, traffic shaping and firewall rules, security filtering, and content filtering settings that can be applied on a per client basis. 

Note: Cisco Meraki Active Directory Based Group Policy on the MX should not be confused with Microsoft Active Directory Group Policy as they are in no way related. 

How does Active Directory based Group Policy work?

The MX utilizes Microsoft's Windows Management Instrumentation (WMI) service to pull a continuous stream of Logon Security Events from specified Domain Controllers in the Active Directory domain. These security events have critical information that tell the MX which user accounts are logged into which computers. Specifically, the events contain the IP address of the computer and the Windows username of the logged on user.

The MX will run through the following steps to identify AD group members and apply associated group policies:

  1. MX securely contacts the specified Domain Controllers for the AD domain, using TLS.
  2. MX reads WMI logon events from the DC's security events, to determine which users are logged into which devices.
  3. MX binds to DCs using LDAP/TLS to gather each user's AD group membership.
  4. Group membership is added to a database on the MX.
  5. If a domain user's group membership matches an AD group policy mapping in Dashboard, the MX can apply the associated group policy to the user's computer.

Because the MX is continuously gathering this information from the domain controllers, it is able to accurately apply policy in real-time whenever a new user logs in.

Note: At this time, the MX does not support mapping group policies via Active Directory for users connecting through the Client VPN.

What is the benefit to this approach?

By using Microsoft WMI and standards based LDAP to interact with the Active Directory network infrastructure, the MX can do real-time Active Directory based Group Policy assignment without the need to install or maintain any agent software on local Active Directory Domain Controllers. 

Configuration Overview

The following steps outline the required configuration (both in Dashboard and Active Directory) to allow for AD-based group policy application. Please be sure to follow each step as accurately as possible, errors can be difficult to diagnose and resolve.

  1. Create an Active Directory site for the MX so users authenticate against the correct Domain Controllers.
  2. Enable security auditing on Active Directory Domain Controllers so the MX can obtain all relevant logon events.
  3. Enable the Global Catalog role on each Domain Controller because the MX uses LDAP/TLS over TCP port 3268.
  4. Install a digital certificate on each Domain Controller for LDAP/TLS.
  5. Certificate Requirements for TLS
  6. Create groups in Active Directory which will be mapped to Group Policies in Dashboard.
  7. Add users to groups in Active Directory. 
  8. Configure Group Policies in Dashboard.
  9. Configure Active Directory Authentication in Dashboard.
  10. Create LDAP group to Group Policy mappings in Dashboard.

Create an Active Directory Site

In Active Directory, Domain Controllers are placed into sites. Sites are assigned IP subnets. Domain users and computers authenticate with Domain Controllers located in the site (IP subnet) for which they reside. Each authentication generates a logon entry within the Domain Controllers Security Event Log. Because the MX uses these Security Events to determine which users are logged onto which computers, all of the Domain Controllers that service logons in an Active Directory site whose IP subnets also correspond to the subnets configured on the MX must be added to Dashboard.    


In the example below, the MX has the following IP subnets and configured under Addressing and VLANs. Active Directory sites need to be applied to both subnets.


Both IP subnets on the MX, are members of the Active Directory site named "Default-First-Site-Name" (shown below). Therefore, the IP addresses of servers DC1, DC1-UK, DC2, SE-Test, and WIN-K7346GNLZ29 located in this site must be added to Dashboard on the Active Directory page in Dashboard. 

Enable Security Auditing on Active Directory Domain Controllers


When Active Directory Group Policy is enabled, the MX pulls a continuous stream of Security Events from Windows Active Directory Domain Controllers. Using Logon Events (540 and 4624) and Account Logon Events (672 and 4768) specifically, the MX can determine which domain users are logged into which domain computers and what the IP address of those computers are. This information is then coupled with the users Group Membership retrieved from an LDAP/TLS lookup and the IP address or MAC address of the computer learned via Cisco / Meraki client detection. By combining these pieces of information, the appropriate filtering policy can be applied transparently in real-time to each computer based on the currently logged on user. If Domain Controllers specified in Dashboard do not have Security Auditing enabled, the MX will not be able to associate users to computers transparently. To ensure that a Domain Controller is configured to audit successful Logon and Account Logon Events, enable this logging using the Default Domain Controller Policy or Local Computer Policy for Domain Controllers in your domain.


  1. On the Domain Controller, open the Local Computer Policy using gpedit.msc.
  2. Navigate to Computer Configuration>Windows Settings>Security Settings>Local Policies>Audit Policy.
  3. Confirm that 'Audit Account Logon Events' and 'Audit Logon Events' is set to 'Success' as shown in this image: 


Note: If these auditing entries are not set to log Success events and the option to edit it is greyed out, then this setting is defined by Domain Group Policy, and you will need to modify this at the Domain level instead.  This setting can be found by opening the applicable Group Policy in the server's Group Policy Management Editor and navigating to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy. If further issues are encountered, please refer to Microsoft's documentation for assistance:

Enable the Global Catalog Role on Each Domain Controller

In order for a Domain Controller to maintain the logon events used by the MX for user/group identification, it must be running the Global Catalog Role. As such, a required configuration step is to enable the Global Catalog Role for each Domain Controller that the MX will be polling.

Please refer to official Microsoft documentation for specific configuration steps.

Install a Digital Certificate on Each Domain Controller

In order to communicate with a Domain Controller, the MX security appliance will need to establish Transport-Layer Security (TLS) so all communication between the MX and Active Directory will be encrypted. As a prerequisite to TLS, the MX will need to verify the identity of the Domain Controller. This is done with certificate validation.

An existing certificate can be used on the Domain Controller (so long as it meets the requisite requirements for TLS), or a self-signed certificate can be created on the server. For more information, please refer to our step-by-step instructions for creating a self-signed certificate on Windows Server.

Create Groups in Active Directory

Since the MX will be mapping Active Directory groups to its own group policies, the appropriate groups will have to be created in Active Directory.

Please refer to official Microsoft documentation for specific configuration steps.

Add Users to Groups in Active Directory

When a user logs on to a domain, the logon event will include both user information and group membership. Since this group membership defines which Dashboard group policy will be applied, it is important to ensure that users are added to the appropriate groups in Active Directory.

Please refer to official Microsoft documentation for specific configuration steps.

Configure Group Policies in Dashboard

A group policy in Dashboard will determine the custom network rules and regulations that will apply to users with that policy. This can include custom bandwidth limits, more or less restrictive content filtering rules, custom access to subnets, etc.

Please refer to our documentation for more information about configuring Dashboard group policies.

Configure Active Directory Authentication in Dashboard

The following instructions explain how to add Active Directory servers to Dashboard, and enable AD authentication for network clients.

  1. Log into Dashboard and navigate to Security Appliance > Configure > Active Directory.
  2. From the Active Directory drop down, select Authenticate users with Active Directory.
  3. For Per-VLAN settings choose Require logon via splash or Default to network-wide settings (Use global settings). Enabling logon via splash will prompt network users with a splash page where they will log in with their domain credentials, but is not a prerequisite to group policy integration.
    In our example below, we are requiring splash logon for the data VLAN and network defaults for the server VLAN.
    Note: The MX AD splash page authorization expires after 2 days or if AD detects a new logon event on the client. The clear authorization button on the client list does not clear the AD splash page authorization on the MX.
  4. For Active Directory Servers, click Add an Active Directory domain server. Remember to add all Domain Controllers that are responsible for the sites/subnets that the MX handles. In our example below, we added all 5 Domain Controllers located in our Active Directory site.
  5. To add an Active Directory server, enter the Pre-Windows 2000 domain name (NetBIOS name) for Short domain (Our domain is ikarem.local with a NetBIOS name of IKAREM, can be found by running the set command in Windows and referencing the USERDOMAIN field)the IP address of the Domain Controller for Domain server, and the username and password of a user that is part of the Domain Admins group in Active Directory.
  6. Click the Save changes button.

Create LDAP Group to Group Policy Mappings in Dashboard

Once Active Directory has been successfully integrated on the MX, the following steps outline how to map Dashboard group policies to groups in AD:

  1. In Dashboard, navigate to Security appliance > Configure > Active Directory > LDAP policies.
  2. Click the Refresh LDAP Groups button to pull LDAP groups from the configured Active Directory servers.
  3. Under Groups, select the LDAP group, and under Policy select the appropriate group policy for that LDAP group.
  4. Click Save Changes at the bottom of the page.

If a user is part of more than one group specified in a Group Policy mapping the first group in the list is applied, they will not receive a combination of both policies. For example, in the screen shot below, if a user was part of both staff and executives they would be mapped to staff and only receive the policy configured as the staff policy:

Note: Policy mappings in Dashboard are done based on the FQDN of the group policy object in Active Directory. If the OU of any object in the FQDN path changes, the group policy mapping will need to be re-added in Dashboard.

Note: Active Directory group policy does not support group nesting or policy overlapping. If a domain user is a member of an AD group (e.g. staff), and that group is contained within another group that has a Group Policy mapping (e.g. executives), the mapped policy (executives) will not be applied to the user.

The best practice for deploying Active Directory based group policy is add users to a single AD group which is mapped to a single group policy. In the example below, a company has different security levels for its executives and staff. A user Bob is a staff member and Billy is an executive. In this case the company creates two AD groups, staff and executives. Bob is added to the staff group and Billy the executives group. Therefore Bob receives the policy applied by staff and Billy the policy from executives:


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, the Status column next to the server in Dashboard will show a red X. Hovering over the X will display a tooltip with more detailed error information:

For detailed error descriptions and troubleshooting recommendations, please refer to our documentation regarding Troubleshooting Active Directory with Group Policies.

Additional Resources

For more information on the subject of AD-based group policy mappings, please refer to the following articles:

Last modified



This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 1422

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community