Authenticating with Active Directory on MX64

[viksep]

Hi,

I am trying to authenticate users with Active Directory (primarily for Client VPN).

My Active Directory resides in Azure and I've created the S2S VPN from the Meraki to it and the connection works without any issues.

From behind the VPN, I can reach both domain controllers in Azure and telnet to the required ports.

However when try to add a server on the Meraki dashboard, the status doesn't seem to indicate that the connection was successful and from what I've seen, there's no way to get any additional information as to why it couldn't connect? E.g. credential or network issue.

Can anyone suggest anything else or perhaps advise on what I could be doing wrong / haven't considered?

I appreciate any input in advance.

Many thanks.

[PhilipDAth]

You can't add servers to the Meraki dashboard.  Could you explain further?

[viksep]

Sure,

On Security & SD-WAN > Active Directory:

I've gone with Authenticate users with Active Directory.

You can see the details here:

The status part spins for a few seconds then doesn't indicate anything else - i.e if it was successful or not.

Having said that, I found that on the Wireless menu (we have a couple of MR42 APs) there's an option under Access Control > Splash page > Sign-on with Active Directory, it gives me an option to add servers and test the connectivity which seems to have worked, so I'm not sure if the AD setup within the firewall just doesn't indicate accurately when it hasn't established the connection and / or if there's a way to view any logs / errors.

Hope this clarifies things.

Many thanks.

[Bruce]

@viksep I'm not sure if this is the exact problem, but there is this line in the documentation, "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." (https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Direc...).

I surmising that in your scenario the traffic to the AD domain controller is originating from a port/IP address on the MX that isn't being routed into the AutoVPN tunnel, whereas for the access points the traffic to the AD domain controller is hitting a LAN port of the MX and hence being successfully put into the AutoVPN tunnel.

If this is the case then your only option might be to stand-up a AD domain controller on the same site as the MX. 

This is only a suggestion as to what is happening, would be happy for anyone else to correct me.

[GreenMan]

Supported Client VPN authentication methods are all configured from within the Client VPN screen itself, not from Security & SD-WAN > Active Directory   (that area allows AD auth for LAN-attached clients)

You need to look to follow this:   https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Overview#Active_Directory

[viksep]

Hey,

Thanks for your response.

I've set the config on Security & SD-WAN > Active Directory but the Event Logs show:

Unable to connect to Domain Controller

I'm not sure, especially as I can telnet from behind the MX to both of the servers I added on port 3268.

Very puzzled right now...

Not sure how the connection is failing when I can test it fine from an AP that's on the network..

Do you know if I am missing something obvious?

[GreenMan]

Run some packet captures on your MX, to check the source address being used for the auth - my guess is it may be from a different subnet than you’re expecting (& from that of your AP)

[viksep]

Hi there, thanks for your response.

I ran the packet capture as per your suggestion, however nothing showed on the output.

I've chosen the Interface Site-Site VPN because that's how I can resolve to the IP in question (S2S from Meraki to Azure)

Still no luck.

I've also tried the other interfaces as well with the same result.

[GreenMan]

Have you been referring to the Client VPN documentation for this?

https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Overview

Within the Active Directory section:

• Server IP: The IP address of an Active Directory server on the MX LAN.  [my bold italics]

This is expanded on, in the Traffic Flow section of the more detailed AD integration section here

https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Direc...

1. The MX, from its LAN IP, queries the Global Catalog over TCP port 3268 (encrypted using TLS) to the AD server configured in Dashboard.   [again, my bold italics]

The AD server needs to be reachable on the local LAN.

[GreenMan]

I queried the detail I sent over yesterday, internally - and will be requesting updates to our documentation;   apparently it is supported for the AD server to also be reachable via VPN - and I've now seen a functioning MX set up this way.  Dashboard validates that the configured destination server is within a valid range (a configured subnet or a remote subnet on the VPN) when you configure it.   Apologies for the misinformation.

This still leaves me wondering about the source IP;  I suspect the highest VLAN is used, which maybe changes the way you filter, on any packet captures?   Is it included in the VPN config...?

[viksep]

Hi,

Thank you for following up.

Yes, I've been referring to this: https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Overview

This still leaves me wondering about the source IP;  I suspect the highest VLAN is used, which maybe changes the way you filter, on any packet captures?   Is it included in the VPN config...?

When you mean highest VLAN, do you mean the one with the smallest ID? These are mine:

The MX IP is 10.0.29.1 

For the VPN config 10.0.29.0/24 and 10.40.0.0/24 (this is my VPN subnet) are configured to reach Azure.

If I am able to successfully connect from an AP using the Active Directory sign-on from Wireless > Access Control, using the DCs IPs instead of the hostname, would it be a case of the Meraki not being able to resolve the domain?

Many thanks again.

[GreenMan]

First run pcaps across the different interfaces, filtered for the target AD server IP address, to establish the source and path.

[viksep]

I've tried running a packet capture with the following filter expression:

dst host 172.16.1.4

This was done across:

Internet:

--- Start Of Stream ---
reading from file -, link-type EN10MB (Ethernet)
13:21:25.555820 e0:cb:bc:2f:12:cd > 8c:90:d3:03:8e:1a, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 64, id 30251, offset 0, flags [DF], proto UDP (17), length 76)
5.252.223.106.42162 > 172.16.1.4.53: [udp sum ok] 9376+ A? cloud-meraki-asn.amp.cisco.com. (48)
0x0000: 4500 004c 762b 4000 4011 31fb 05fc df6a E..Lv+@.@.1....j
0x0010: ac10 0104 a4b2 0035 0038 9b9f 24a0 0100 .......5.8..$...
0x0020: 0001 0000 0000 0000 1063 6c6f 7564 2d6d .........cloud-m
0x0030: 6572 616b 692d 6173 6e03 616d 7005 6369 eraki-asn.amp.ci
0x0040: 7363 6f03 636f 6d00 0001 0001 sco.com.....
--- End Of Stream ---

LAN - no output
Site-Site VPN no output

Client VPN no output

[GreenMan]

OK, so the MX is clearly using a source IP address for the lookup, from a VLAN that isn't currently permitted in the VPN;   it's NATing to it's public IP and sending directly to the Internet (where it's blackholed).

Check that the destination IP address for the AD server lies within the VPN routing.

Assuming it already is, what I would do is allow all your VLANs access to the VPN, temporarily, then re-run the packet capture on the VPN interface, to check it's being sent via that path - you'll then also be able to see the source being used.

You can then remove the other VLANs from the VPN and, if you need to, write some VPN firewall rules to (just) allow your MX to query the AD server and no other comms with that VLAN, if you need to.

[viksep]

Hi, 

Once again thanks for your reply. 

Check that the destination IP address for the AD server lies within the VPN routing.

This is my S2S config on Meraki:

And here are the subnets from the Meraki that are enabled for the connection on Azure side.

Assuming it already is, what I would do is allow all your VLANs access to the VPN, temporarily

Would be able to clarify this? Do you mean add any remaining VLANs to the address space mentioned above or here:

My S2S outbound firewall looks like this:

Once again, I appreciate all the help.

[viksep]

This is my S2S config on Meraki: (image didn't upload)

[GreenMan]

OK - so your AD server is within the subnet for the VPN ✔️

I would initially try turning VPN participation on for the Default VLAN 192.168.128.0

You'll need to add this subnet to the permitted list for the tunnel in Azure, to match.

Then run a packet capture on the Site-to-Site VPN interface of your MX, while you initiate your VPN Client session - filter for your AD server IP 172.16.1.4 if you wish.   If you see the query bound for your server, chances are it must be sourced from 192.168.128.1 (assuming this remains the IP for the MX in that subnet)

If this works, you will need to look at your VPN firewall rules, to check they still meet your needs (hint:  you have no deny rule, currently)

[viksep]

I would initially try turning VPN participation on for the Default VLAN 192.168.128.0

Done this ✔️

You'll need to add this subnet to the permitted list for the tunnel in Azure, to match.

Done this also ✔️

I'll switch authentication to Active Directory and try to initiate a new VPN session from my client whilst packet capturing.

Thanks.

[viksep]

I've switched the authentication to Active Directory, initiated a VPN session from my client and nothing appeared whilst packet capturing on Interface = Site-Site VPN

Only results are when the Interface is set to Internet, like previously. 

[GreenMan]

It woulr probably be best for you to log a Support case with Meraki for this, if I'm honest...

[viksep]

Thank you, I did originally raise a case and was on the phone for 1 hour and 20 minutes and it seemed like the engineer knew less than I did.

I guess I'll try my luck again and hopefully someone else can assist.

I appreciate all your attention and suggestions - very many thanks.

[viksep · Accepted solution]

Hi,

I just wanted to say that after a long time troubleshooting this with Cisco Support, we did make some progress and found an issue whereby the connection was being attempted by the highest numbered VLAN that I had - in my case it was one that was not configured for the S2S.

After disabling VPN participation for that, we found some WMI errors that indicated a potential issue with the account I was using to connect to the domain.

TL;DR, I set up RADIUS instead with NPS and used the MFA extension for Azure on top of it and it's working perfectly.