WMI error Active Directory authentication

[iscs-mark]

MX67 on 18.211 connecting to 2x fully patched 2016 DCs with self-signed certificates

Not sure when this happened, but noticed that I am getting a WMI error in the dashboard when connecting to either AD server in Security & SD-WAN - Active Directory. This worked from the beginning when the MX was installed.

Tried a new account, know the password is right, always

Have the same setup at a few other customers and they are working fine. Not sure what is different.

Security logs on the DCs show the password is not right, but I know it is.

Tried changing the short domain to just domain from domain.local, changed the user to user, domain\user, user@domain.local.

Seeing this on the DCs:

An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: svc.merakildap
Account Domain: WORKGROUP

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC000006A

Process Information:
Caller Process ID: 0x0
Caller Process Name: -

Network Information:
Workstation Name: MAC17C8D12801
Source Network Address: 192.168.0.1
Source Port: 46424

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

Could it be because of NTLM as the package?

[MichaelMitchell]

Yeah, that NTLM detail is actually a big clue. The MX uses NTLM for these WMI/AD checks, so if something changed on your 2016 DCs—like tightened security policies or NTLM restrictions—it could explain why it suddenly broke. The error code points to bad credentials, but in reality it’s often the DC rejecting NTLM auth. Check local/domain security policies for NTLM blocking or “Network security: LAN Manager auth level.” Also verify the account isn’t locked or restricted to certain logon types. It’s likely not the password, but how it’s being authenticated.

[acaruwor63]

This almost sounds more like an authentication or protocol mismatch than an actual bad password. Since it worked before and other customers with similar setups are still fine, I’d check whether a Windows update hardened WMI, NTLM, or DCOM settings on those DCs. Self-signed certs could also be part of it if something changed around trust validation. I’d also verify the MX can still resolve the DCs correctly by hostname and that the account isn’t being blocked by new security policies or “log on as a service/network” restrictions. The security log details and event IDs would probably point to the exact failure.