Meraki active directory authentication

Meraki active directory authentication DEFAULT

Environment:

VMWare ESXi 6.0 Virtual Servers
1 x Windows Server 2012 R2 DC running AD, DNS, DHCP, IIS, File/Storage Services and Remote Access (10.1.0.49)
1 x Windows Server 2008 Standard SP2 (32bit) running AD, DNS, File Services, Network Policy and Access, IIS (10.1.0.3)

Dilemma:

In Meraki dashboard, under Security Appliance -> Client VPN, our  Authentication is set to Active Directory and the information (short domain, server IP, domain admin and password) is set.

When the Server IP is set to 10.1.0.3 (2008 AD Machine), the VPN connection is made with the following entries into the Meraki Event Log:

BASH

Mar 2908:09:52 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport 69.61.185.246[4500]->174.233.140.126[4500]spi=2645625892(0x9db10c24) Mar 2908:09:52 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport 69.61.185.246[4500]->174.233.140.126[4500]spi=207213937(0xc59d571) Mar 2908:09:52 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA established 69.61.185.246[4500]-174.233.140.126[4500] spi:402bd3f6b8d43160:45ea9ce1a622f347 Mar 2908:09:51 Non-Meraki / Client VPN negotiation msg: invalid DH group 19. Mar 2908:09:51 Non-Meraki / Client VPN negotiation msg: invalid DH group 20.

When the Server IP is set to 10.1.0.49 (2012 AD Machine), the VPN connection fails with the following entries into the Meraki Event Log:

BASH

Mar 2908:13:08 Non-Meraki / Client VPN negotiation msg: failed to begin ipsec sa negotiation. Mar 2908:13:08 Non-Meraki / Client VPN negotiation msg: no configuration found for174.233.140.126. Mar 2908:15:44 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport 69.61.185.246[4500]->6.1.0.0[4500]spi=183719556(0xaf35684) Mar 2908:15:44 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport 69.61.185.246[4500]->6.1.0.0[4500]spi=169726232(0xa1dd118) Mar 2908:15:44 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA established 69.61.185.246[4500]-6.1.0.0[4500] spi:3c3f5d5e31bf3a96:979ca4f5ed84160c Mar 2908:15:44 Non-Meraki / Client VPN negotiation msg: invalid DH group 19. Mar 2908:15:44 Non-Meraki / Client VPN negotiation msg: invalid DH group 20. Mar 2908:15:47         Non-Meraki / Client VPN negotiation     msg: failed to begin ipsec sa negotiation. Mar 2908:15:47         Non-Meraki / Client VPN negotiation     msg: no configuration found for6.1.0.0.

I don't believe this is a Meraki issue. This seems to be an issue with the Primary Domain Controller (10.1.0.49) and I'm trying to narrow down the cause.

Background Information:

The 2008 machine has been a DC for many years. In 2016, we added the 2012 R2 machine and promoted it to Primary DC keeping the 2008 machine as a secondary DC. The promotion was successful and to my knowledge it does act as the Primary DC.

Any ideas as to what could be causing the Primary DC (10.1.0.49) to not accept the VPN connection via AD Authentication?


Best Answer

Brendan5133

Chipotle

OP

Ok one reason that can come up is a missing certificate for TLS

Another is the user is not authorized for VPN- assuming this was checked already as it connects to the other server, those are for the same client correct?

Another is mismatched preshared secrets between the MX and RADIUS server- for this one change the pre shared secret in dashboard to something simple, verify the new Preshared secret on both the mx and radius client

View this "Best Answer" in the replies below »

8 Replies

· · ·

Brendan5133

Chipotle

OP

Have you checked the  "IKE and AuthIP IPsec Keying Modules" service and made sure it was on autostart?

Can you get the client event viewer on the errors as well? that will help in diagnosing.

0

· · ·

ClaytonDaniels

Jalapeno

OP

IKE and AuthIP IPsec Keying Modules is Running (set to Automatic (Trigger Start)

Event Viewer from client PC:

Successful Connection events:

BASH

CoId={22B87763-DEF5-477E-AD3A-41B723A4FDC3}: The user DOMAIN\user.name has started dialing a VPN connection using a per-user connection profile named CONNECTION. The connection settings are: Dial-in User= DOMAIN\user.name VpnStrategy= L2TP DataEncryption= Requested PrerequisiteEntry=AutoLogon= No UseRasCredentials= Yes Authentication Type= PAP Ipv4DefaultGateway= Yes Ipv4AddressAssignment= By Server Ipv4DNSServerAssignment= By Server Ipv6DefaultGateway= Yes Ipv6AddressAssignment= By Server Ipv6DNSServerAssignment= By Server IpDnsFlags=IpNBTEnabled= Yes UseFlags= Private Connection ConnectOnWinlogon= No IPsec authentication forL2TP= Pre-shared key. CoId={22B87763-DEF5-477E-AD3A-41B723A4FDC3}: The user DOMAIN\user.name is trying to establish a link to the Remote Access Server for the connection named CONNECTION using the following device: Server address/Phone Number=69.61.185.246 Device= WAN Miniport (L2TP)Port= VPN3-1 MediaType= VPN. CoId={22B87763-DEF5-477E-AD3A-41B723A4FDC3}: The user DOMAIN\user.name has successfully established a link to the Remote Access Server using the following device: Server address/Phone Number=69.61.185.246 Device= WAN Miniport (L2TP)Port= VPN3-1 MediaType= VPN. CoId={22B87763-DEF5-477E-AD3A-41B723A4FDC3}: The link to the Remote Access Server has been established by user DOMAIN\user.name. CoId={22B87763-DEF5-477E-AD3A-41B723A4FDC3}: The user DOMAIN\user.name has dialed a connection named CONNECTION to the Remote Access Server which has successfully connected. The connection parameters are: TunnelIpAddress=10.1.100.254 TunnelIpv6Address= fe80:: Dial-in User= DOMAIN\user.name. CoId={22B87763-DEF5-477E-AD3A-41B723A4FDC3}: The user DOMAIN\user.name dialed a connection named CONNECTION which has terminated. The reason code returned on termination is 631.

Failed Attempts:

BASH

CoId={2106E575-14C0-4FF1-98FB-47AA078AF6E6}: The user DOMAIN\user.name has started dialing a VPN connection using a per-user connection profile named CONNECTION. The connection settings are: Dial-in User= DOMAIN\user.name VpnStrategy= L2TP DataEncryption= Requested PrerequisiteEntry=AutoLogon= No UseRasCredentials= Yes Authentication Type= PAP Ipv4DefaultGateway= Yes Ipv4AddressAssignment= By Server Ipv4DNSServerAssignment= By Server Ipv6DefaultGateway= Yes Ipv6AddressAssignment= By Server Ipv6DNSServerAssignment= By Server IpDnsFlags=IpNBTEnabled= Yes UseFlags= Private Connection ConnectOnWinlogon= No IPsec authentication forL2TP= Pre-shared key. CoId={2106E575-14C0-4FF1-98FB-47AA078AF6E6}: The user DOMAIN\user.name is trying to establish a link to the Remote Access Server for the connection named CONNECTION using the following device: Server address/Phone Number=69.61.185.246 Device= WAN Miniport (L2TP)Port= VPN3-1 MediaType= VPN. CoId={2106E575-14C0-4FF1-98FB-47AA078AF6E6}: The user DOMAIN\user.name has successfully established a link to the Remote Access Server using the following device: Server address/Phone Number=69.61.185.246 Device= WAN Miniport (L2TP)Port= VPN3-1 MediaType= VPN. CoId={2106E575-14C0-4FF1-98FB-47AA078AF6E6}: The link to the Remote Access Server has been established by user DOMAIN\user.name. CoId={2106E575-14C0-4FF1-98FB-47AA078AF6E6}: The user DOMAIN\user.name dialed a connection named CONNECTION which has failed. The error code returned on failure is 691. CoId={2106E575-14C0-4FF1-98FB-47AA078AF6E6}: The user DOMAIN\user.name dialed a connection named CONNECTION which has terminated. The reason code returned on termination is 828.

0

· · ·

Brendan5133

Chipotle

OP

Best Answer

Ok one reason that can come up is a missing certificate for TLS

Another is the user is not authorized for VPN- assuming this was checked already as it connects to the other server, those are for the same client correct?

Another is mismatched preshared secrets between the MX and RADIUS server- for this one change the pre shared secret in dashboard to something simple, verify the new Preshared secret on both the mx and radius client

1

· · ·

ClaytonDaniels

Jalapeno

OP

How can I verify missing certificate for TLS? Does this missing certificate belong on the 2012 DC? Would their be one on the 2008 DC?

I'm on my personal laptop, connecting to the VPN with my Domain Admin account. Authorization for that user should not be relevant.

The PreShared secret is correct and verified.

You did say RADIUS server... I see RADIUS as an option under the Meraki Authentication dropdown, but it is not selected. Active Directory is. Would this mean we are not using RADIUS?

0

· · ·

ClaytonDaniels

Jalapeno

OP

I've opened MMC.exe and added the Certificates for local computer on each Domain Controller.. one thing jumps out.

Server 2008
Under Personal and Trusted Root CA

  • There is a certificate issued to SERVER2008.DOMAIN.org, issued by SERVER2008 .DOMAIN.org, Exp 2/26/2019, Server Authentication (purpose), Friendly Name: Meraki

Server 2012
Under Personal and Trusted Root CA

  • There is NO such certificate
  • There is a Go Daddy Cert issued to DOMAIN.org, Exp 7/20/2020, Server/Client Auth (purpose), Freindly Name: domain.org

1

· · ·

ClaytonDaniels

Jalapeno

OP

It was a missing TLS certificate. 

On the 2008 DC, the certificate was in the Personal and Trusted Root folders

On the 2012 DC, the certificate was in the Trusted Root and Web Hosting folders.

I moved the the certificate, actually copied it, to the Personal folder of the 2012 DC and the VPN connections was successful!

Appreciate the talk through and help!

Thank you!

0

· · ·

Craig4129

Thai Pepper

OP

It always the Certs; just like it is always DNS....I am glad its working - this one is going in my bookmarks :)

Craig

1

This topic has been locked by an administrator and is no longer open for commenting.

To continue this discussion, please ask a new question.

Sours: https://community.spiceworks.com/topic/2124451-dilemma-involving-meraki-client-vpn-and-ad-authentication

I received a Meraki MR18 from attending a webinar.

I'm trying to setup two SSIDs with Active Directory authentication, one for students and one for staff.

The problem is that anyone can authenticate on either SSID because the user I have for authorization can read information for everyone in the directory.

Does anyone know of an easy way to create a user that can only read users from the specific OUs containing our staff or students. When I tried to create one, the only way I found to deny the read permission was to place it at the user level, which is a pain with so many users.

We already have Ruckus Wireless, and I would like to set-up the Meraki AP in a similar fashion so I can compare it in a more equivalent fashion. 


Best Answer

xHogan78x

Anaheim

OP

Radius Server is a good way to have different users or computers authenticate to a Domain. Create a User Security Group for each Staff and Students. Then set permissions as to what each group needs to see. 

Use GP's as well within your domain. 

View this "Best Answer" in the replies below »

7 Replies

· · ·

shdw1jz

Serrano

OP

Do you have an OU for students and another for Staff? or is all combined?

0

· · ·

shdw1jz

Serrano

OP

also i forgot to mention, do you have your network policy configured for all users to have access?

If you do have OU's to separate the users, on the NPS you will need to create two policies and each policy will have the one OU for students or for staff.

0

· · ·

CAMCSHS

Sonora

OP

Our staff is across multiple OUs and our students are in separate OUs for graduating year underneath one Student OU.

0

· · ·

xHogan78x

Anaheim

OP

Best Answer

Radius Server is a good way to have different users or computers authenticate to a Domain. Create a User Security Group for each Staff and Students. Then set permissions as to what each group needs to see. 

Use GP's as well within your domain. 

0

· · ·

Michael Quaintance

Thai Pepper

OP

1st thing: Welcome to the Community.

2nd thing: don't forget to pay the license fees to Cisco. Your AP will turn to a dud otherwise. You may have already known that.

0

· · ·

CAMCSHS

Sonora

OP

It looks like a Radius Server is probably the best choice.

Now the fun of setting it up and using it. 

0

· · ·

voiceguy2

Jalapeno

OP

You know you have Meraki support right? Just call them.. The AP license is included for you to demo. If you choose not to renew it'll quit working. Renewals are pretty cheap.. and include the cost of support (24x7) and hardware warranty (RMA). Worth it in an enterprise (your home.. probably not) :-)

If you already have AD setup you can use that easily for authentication. I dont know the specifics of your environment but if you have it setup with another vendor I'm sure it can be configured the same on Meraki. I'd call support and they will work with you to get it working, you could also visit the knowlegebase - its very easy to search and helpful. 

https://kb.meraki.com/knowledge_base/configuring-ldap-authentication-server

- Andrew

0

This topic has been locked by an administrator and is no longer open for commenting.

To continue this discussion, please ask a new question.

Sours: https://community.spiceworks.com/topic/673448-meraki-ap-and-active-directory-authentication
  1. Managerial accounting solution manual
  2. Samsung laptop cover skins
  3. Gretsch lap steel review
  4. Are virgos good kissers

Integrating Active Directory with Sign-On Splash Page For MR Access Points

  1. Last updated
  2. Save as PDF

Cisco Meraki devices (MR access points and MX security appliances) support the use of a sign-on Splash Page, requiring network users to authenticate in a web browser before being allowed access to the network. This splash page can be integrated with an Active Directory server, allowing users to provide their domain credentials to gain access.

This article outlines how to configure a sign-on Splash Page with Active Directory.

Overview

When using Active Directory authentication, your Access Points need to perform a secure LDAP bind using SSL\TLS via the starttls command. The LDAP bind authenticates the user logging into the splash page as illustrated below:

  1. A secure connection is established using TLS. After the handshake, a secure channel is established. LDAP calls are encrypted preventing outsiders from snooping the portion of the exchange highlighted in beige.
  2. The AP binds to the Domain Controller using the Active Directory admin credentials specified in Dashboard. 
  3. If the bind is successful, the AP searches the directory for the user logging in by their sAMAccountName attribute. If a match is found, the DN of the user is returned to the AP.
  4. The AP then attempts to bind with the DN of the user and password entered in Dashboard. If the credentials are OK then the user is authenticated. 

256e47d7-be16-4734-805b-3218e6cef31c

 

Configuration and Requirements

In order to configure a splash page with Active Directory authentication, 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. Please refer to Microsoft documentation for specific configuration steps.
  • Since communication between the MR 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 MR will communicate from its LAN IP with each AD server over TCP port 3268, to ensure that no firewalls or ACLs on the network or server will block that communication.

When Active Directory authentication is configured, the MR 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 all AD servers have been primed with the configuration requirements outlined above, the following steps outline how to set up AD authentication with a sign-on splash page:

  1. Log into Dashboard
  2. Navigate to Wireless > Configure > Access control.
  3. Select the desired SSID from the SSID drop-down menu.
  4. Navigate to the Splash page section.
  5. Using the Authentication Method drop-down menu, select my Active Directory server.
  6. Navigate to Active Directory servers and Active Directory admin.
  7. Click on Add a server and input the IP address of the domain controller.
    Note: Multiple servers may be added. The AP will test against these servers in sequential order, i.e. from top to bottom.
  8. Input a domain admin's credentials in the Active Directory admin section. The account can use the Windows 2000 ([email protected]) or Pre-Windows 2000 (Domain\admin) format.
    Note: It is advised these user credentials have minimal read-access permissions to the domain database. This account will only be used for the BIND to Active Directory
  9. Click the Save Changes button to save changes.

Microsoft LDAP Test

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.

Scoping Active Directory per SSID

By default, when using Active Directory for Splash Page authentication, all users in AD can be granted access. However, by using OUs and a custom AD admin account, it is possible to limit which users can get through authentication. This document will show you how to limit the scope of users that can be authenticated to an SSID using a Splash Page with Active Directory Integration.

Note: The following images and settings are intended to be used as general guidelines as these may not be updated to fit changes on the AD sidePlease refer to Microsoft documentation and support for assistance.

 

First, you will need to create users for each group of users. In this case, we have Students and Staff. We will use this example to limit Staff Users from accessing the Student SSID.

OU_intro_AD_IMAGE.png

Right click and select Properties of the Staff OU

Properties_OU_Staff.png

Deny the StudentLDAPUser's READ rights for the Staff OU

Read_rights_user.png

Now, you will use this StudentLDAPUser to Bind to AD under 'Configure >> Access Control' for your Student SSID:

Access_control_download.png

Since this user does not have the ability to read the Staff OU, Staff Users will not be able to use this SSID. You will need to apply this Deny to all User OU's that should not be allowed to access this SSID. 

You will repeat the same steps to Deny Students from accessing the Staff SSID. You'll need to Deny Read permissions for StaffLDAPUser for all OU's that should not have access to the Staff SSID.

 

Additional Resources

For additional information regarding sign-on splash pages and Active Directory integration, please refer to the following documentation:

 

Sours: https://documentation.meraki.com/MR/MR_Splash_Page/Integrating_Active_Directory_with_Sign-On_Splash_Page_For_MR_Access_Points
Meraki

OneLogin Plan for Meraki Single Sign-On

OneLogin for Meraki enables firms to easily connect their Microsoft Active Directory or LDAP Server to the Meraki Dashboard, enjoy single sign-on at the office or on the go, and enforce multi-factor authentication. Meraki brings the benefits of the cloud to the edge and branch networks, delivering easy-to-manage wireless, switching, and security solutions that enable customers to seize new business opportunities and reduce operational cost.

OneLogin integrates seamlessly with Meraki and provides the following features:

Single Sign-On

OneLogin uses SAML 2.0 to sign users into Meraki eliminating user-managed passwords and the risk of phishing.

Active Directory & LDAP Integration

OneLogin’s zero-config Active Directory Connector can be installed in minutes with no server restarts or firewall changes.

OneLogin Mobile

Many web apps don’t have a native mobile version and the ones that do often only provide a reduced feature set. OneLogin Mobile makes your web apps accessible on the go.

Multi-factor Authentication

Add an extra layer of protection with OneLogin’s free smart phone app or a pre-integrated third-party solution from RSA, Google Authenticator, Duo Security, Symantec or Yubico.

Useful Links

Sours: https://www.onelogin.com/partners/technology-partners/meraki

Authentication meraki active directory

Configuring Active Directory with MX Security Appliances

  1. Last updated
  2. Save as PDF

Active Directory (AD) integration allows you to restrict access to the network and enforce Group Policies based on membership in Active Directory groups.

Currently, Active Directory-based authentication works only if one of the following is true:

  • The Domain Controller is in a VLAN configured on the appliance
  • The Domain Controller is in a subnet for which a static route is configured on the appliance
  • The Domain Controller is accessible through the VPN.

If there are multiple Domain Controllers in the domain, all of them must meet one of these criteria in order for Active Directory integration to function properly.

Note: The information listed here should be used as a general operating system configuration guideline. Your specific options and menus may differ depending on the version of Windows Server deployed. 

Integrating with Group Policies

A Group Policy in the 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. 

Traffic Flow

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 tells 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 the 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.

Benefits of Active Directory Integration

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.

NOTE: Multiple Language Server Support

The support to query Microsoft Active Directory servers configured for non-English languages is presently not supported.

This functionality is currently under consideration by the Product and Engineering teams. We do not have an ETA on implementation.

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 10.0.0.0/24 and 192.168.0.0/24 configured under Addressing & VLANs. Active Directory sites need to be applied to both subnets.

ad subnets.PNG

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. 

2.png

Enable Security Auditing on Active Directory Domain Controllers

Explanation

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.

Configuration
  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: 

3.png

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. 

Certificate Requirements for TLS

The following notes describe certificate parameters used in Windows Server, but can be generalized for any certificate's parameters.

Under the General tab, check for the following attributes:

  • The server must have the corresponding private key. To verify that the private key exists, view the General tab of the certificate and verify that you see the following message: "You have a private key that corresponds to this certificate".
  • Verify that the following statement appears: "This certificate is intended for the following purpose(s): Proves your identity to a remote computer". 
  • Check that the certificate is still valid, based on the "Valid from" values.

161660e9-4ca1-463e-83d2-0a501dec663d

 

Under the Details tab:

  • The Version value must contain "v3", indicating that it is an X.509 Version 3 certificate.

027016df-3566-4d53-b2f3-d800f475ceb7

 

  • The Enhanced Key Usage value must contain the Server Authentication certificate purpose (OID "1.3.6.1.5.5.7.3.1").

4cec2a3f-3bff-4a0b-b837-eeba0aeb523a

 

  • The Subject value must contain the Fully Qualified Domain Name of the RADIUS server or Active Directory server, e.g. myserver.mydomain.com. 
  • The Public key value should be set to "RSA (2048 Bits)".

2fb213d1-e1a9-47d6-9c7c-7f0c5f65dbdf

 

  • The "Subject Alternative Name" value must contain the syntax "DNS Name=myserver.mydomain.com" where the the DNS name is the Fully Qualified Domain Name of your server. This is especially important when using an Active Directory-based PKI.

97a65a90-13d1-4cda-964f-64c09d2373be

 

  • The Key usage must contain the "Digital Signature" and "Key Encipherment" values.
    Note: In Server 2012, this option may be available as "Data Encipherment."

9ace3db0-f596-4c47-b9a9-7e0bd9a1d496

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 & SD-WAN > Configure > Active Directory.
  2. From the Active Directory drop-down, select Authenticate users with Active Directory.
  3. For Per-VLAN settings choose to 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.

  1. 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.
  2. To add an Active Directory server, enter the following information:
    1. Short Domain: Short name of the domain (a.k.a., NetBIOS name), as opposed to the fully qualified domain name (FQDN). Typically if the FQDN is "mx.meraki.com", the short domain is "mx".
    2. Server IP: The IP address of the domain controller.
    3. Domain admin: A domain administrator account that the MX can use to query the AD server.
    4. Password: The password of the domain administrator account.

Note: Unicode characters in usernames and passwords are not currently supported.

 

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
  1. Click the Save changes button.

10.png

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 & SD-WAN > Configure > Active Directory > LDAP policies.
  2. Click the Refresh LDAP Groups button to pull LDAP groups from the configured Active Directory servers based on the domain credentials provided in the dashboard.

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.

  1. Under Groups, select the LDAP group, and under Policy select the appropriate group policy for that LDAP group.
  2. 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 screenshot 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:

11.png

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 to 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:

12.png

Integrating Group Policies with MPLS 

An MX appliance must be configured in Passthrough mode when Active Directory-based content filtering is desired and the Active Directory domain controllers are located upstream or across an MPLS. Additional information on the traffic flow and the reason for this required configuration is explained below.

Passthrough Mode Configuration

To support Active Directory Group Policy mappings when Active Directory servers are located across an MPLS, the MX Security Appliance must be placed in Passthrough mode. This can be accomplished by going to Security & SD-WAN > Configure > Addressing & VLANs on the Cisco Meraki Dashboard and selecting the option for Passthrough or VPN Concentrator.  

new passthrough mode config.PNG

In this mode, the MX Security Appliance acts as a layer 2 bridge and does not modify the source address of traffic that traverses the WAN uplink. This configuration allows the MX to query the security logs, obtain an end-user's account name and associated device IP address, and apply the corresponding group policy.

21.png

Routed Mode Configuration

When an MX Security Appliance is configured for Routed mode and Active Directory Domain Controllers are located across an MPLS, authentication requests will traverse the MX WAN uplink. When this uplink traversal occurs, a NAT translation takes place and the source IP will be modified from the user's client device IP address to the WAN IP address of the MX Security Appliance.  

In this scenario, the Active Directory security logs will contain the IP address of the MX Security Appliance, rather than the IP address of the end-user's device. This prevents the MX from knowing which device to apply the identity-based content filtering policies. Because of this, a Routed mode configuration will not support Active Directory-based group policies.

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:

  1. The user's device attempts to establish a VPN tunnel using L2TP over IP.
  2. The user provides their valid domain credentials.
  3. The MX, from its LAN IP, queries the Global Catalog over TCP port 3268 (encrypted using TLS) to the AD server configured in Dashboard.
  4. If the user's credentials are valid, the AD server will send its response to the MX, completing authentication.
  5. 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:

  1. In Dashboard, navigate to Security & SD-WAN > Configure > Client VPN
  2. 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.

  1. Set Authentication to Active Directory.
  2. 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.

  1. 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.

Additional Resources

For more information about both Client VPN and Active Directory integration, please refer to the following articles:

Sours: https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Directory_with_MX_Security_Appliances
Meraki AP and RADIUS integration

It's a long story - Tell me. I always have time for you. Well, I owe a lot of money, and the debt expired a week ago.

You will also like:

Take the dishes, wait, I'll spill it, Horus, damn it, shine more evenly, blaspheme, come on, take the first, social life outside the door a step away from us. Boiled, gurgled in large gulps, pulled the smell of cigarettes and weed. I resolutely put my hands under Galkin's sweater, once again pushed the barrier to the boobs and grabbed them with both hands.

He moved his pelvis, tried to rub his penis where the axis so wanted. Pebbles hugged me and stiffened, no sound, no objection, not the slightest movement.



1120 1121 1122 1123 1124