MX can't connect to AD

Solved
mitchmutch
Here to help

MX can't connect to AD

Hello,

 

First off : I opened a case, currently ongoing, this topic is to gather information from fellow administrators/engineers, if you have 5 mn to spare.

 

I would like your help by testing this feature that failed 2 days ago (no action on my part, failed on its own), we were unable to update MDM based on this auth, and the account that was used was locked out for too many atuh failures. I tried changing the account to mine, and it doesn't work.

 

pre-requisite : make sure to be connected to Active Directory to unlock your account or not to use your own admin account as it could be locked really quick performing the following test: 

 

1) On a given Network that is allowed to access your Domain Controllers (DC), Can you please go to Security/SDWAN -> Active Directory.

2) Select "Authenticate Users with Active directory" on top

3) enter your informations, mine look like this (user needs to be a domain admin, DC must be able to be LDAP/WMI query-ed by this user

mitchmutch_0-1628854928519.png

4)  It's been failing for no reason for two days now, and I tried everything, changing the syntax of every field, the short domain (group or its FQDN), the user (user@group, user, group\user, same with domain fqdn), the DC (I have 8 of them), the password policy to make it alphanumeric only, the meraki network, it always fails whatever I try.

 

Note : on my DC, in event observer with the settings posted in the screenshot above, I get 2 lines of eventat each try : first, it tries user-admin in WORKGROUP (fail, event type 4625) then user-admin in GROUP (my AD domain) and it succeeds (event type 4624) -yet the Meraki displays a red cross everytime.

 

Then, after a few tries, my user-admin is locked for too many authentication failures.

 

Can you please share your results without saving this configuration (works / doesn't / which event appears in the DC? )? I'd like to make sure it's still working broadly, because I don't understand why WORKGROUP is being used here (which seems to be the cause of the failure), and I didn't set it up originally, so I don't know if it was always this way.

 

Regards,

 

Michel (France, sorry for the wall of text)

1 Accepted Solution
mitchmutch
Here to help

It looks like my domain admin disabled (for security purposes) : NTLM & LM responses were disabled to have only NTLMv2 working. After enabling it again, it works. I will send a wish to have this feature support NTLMv2 (which came out about 10 years ago).

View solution in original post

4 Replies 4
JimmyM
Getting noticed

The connection to your DC need to be secure.

 

Does your DC can communicate with Secure LDAP on 636 port ?

mitchmutch
Here to help

Hello,

 

Thanks for your reply : 

 

It does work with 636 port for LDAPS (tried with another application in my LAN, provided the DC Certificate Authorities in the application)

but when I do a packet capture on the MX when I try to set this up (the issue), I see it tries to join the Domain Controller through DCE-RPCE (using TCP port 135), no mention of port 636. The meraki support also deciphered DCE-RCP packet while trying to help me.

mitchmutch
Here to help

It looks like my domain admin disabled (for security purposes) : NTLM & LM responses were disabled to have only NTLMv2 working. After enabling it again, it works. I will send a wish to have this feature support NTLMv2 (which came out about 10 years ago).

dustinnewby
Here to help

We disabled it as well because of Petitpotam.  I guess that makes sense why my local auth won't work.  A bit disconcerting that a security product only supports an insecure legacy protocol.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels