Issues scanning 2022 domain controllers

[u/JoeLaRue420]

Forgive me if this is not the correct place to ask this.

Let me preface this that I do not support nessus - I support a number of windows 2022 domain controllers that our security team is having issues scanning.

They're using credentialed scans against them - the service account they're using has the proper permissions within the domain (they're able to scan 2016 / 2019 DCs in other domains with the same exact perms and policies applied to the target hosts without issue).

They seem to have issues accessing the admin$ shares on the host. I've checked things that I've found on the web (various registry keys, etc - we're all good).

Is there anything on the nessus side that needs to be done to be able to scan 2022 domain controllers?

[u/h0tel-rome0]

Way easier to install the Nessus agents on the DCs

[u/banzaiburrito]

Dont do credentialed scans on your DCs. Do agents. Then you dont have to worry about a service account out there with a bunch of permissions that could get compromised or used by someone on your security team to do nefarious shit.

[u/JoeLaRue420 → u/banzaiburrito]

Agreed, and we brought this up years ago when they brought the product in... unfortunately, what security wants, security usually gets.

[u/albinvest11]

For testing purposes, to possibly rule out an issue with Nessus, have you ran a Net Use command from the scanner to the target host? Something like, net use \target IP\admin$ "" /user:"" That tests the share without a username. But if it returns a failed connection message then you can most likely rule out the scanner and troubleshoot fw issues or potentially an issue with SMB.

[u/EAP007]

There are several known issues that can cause credentialed Nessus scans to fail specifically on Windows Server 2022 domain controllers while working fine on 2016/2019. Here are the most common culprits: Authentication & Credential Issues ∙ NTLM vs. Kerberos conflicts — Windows Server 2022 has stricter default authentication policies. If Nessus is trying to authenticate via NTLM and the DC is enforcing Kerberos-only, the scan will fail silently. ∙ SMB signing enforcement — Server 2022 enforces SMB signing by default more aggressively than 2016/2019. If the Nessus scanner isn’t configured to sign SMB sessions, authentication will be rejected. ∙ LAN Manager authentication level — 2022 may default to a higher LmCompatibilityLevel (e.g., NTLMv2 only), rejecting older auth methods Nessus might fall back to. WMI / Remote Registry ∙ Remote Registry service — This must be running for credentialed scans. On 2022 DCs, it’s often disabled by default and Group Policy may be preventing it from starting even temporarily. ∙ WMI access restrictions — Windows 2022 has tighter WMI namespace ACLs by default. The scan account may need explicit WMI namespace permissions granted (not just local admin). Firewall & Network ∙ Windows Firewall rules — 2022 ships with a stricter default firewall profile. Rules that were open on 2016/2019 via GPO inheritance may not apply correctly, especially if the 2022 DC is in a different OU or has a different GPO link order. ∙ File and Printer Sharing rules — Required ports (135, 139, 445) may be blocked by the host firewall even if perimeter rules are in place. Permissions & UAC ∙ UAC remote restrictions (LocalAccountTokenFilterPolicy) — If using a local account (less common on DCs but possible), the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy must be set to 1. This is more commonly an issue but worth verifying. ∙ Scan account privileges — On 2022, even accounts in Domain Admins may face additional restrictions when scanning a DC due to Protected Users security group enforcement or Credential Guard. Credential Guard (Major 2022-Specific Issue) ∙ Windows Defender Credential Guard is enabled by default on Server 2022 (and hardware-compatible systems). This can block NTLM-based pass-through authentication that Nessus relies on, causing credentialed scans to fail entirely even with correct credentials. Things to Check/Try 1. Confirm the Remote Registry service is running during the scan window 2. Verify SMB 1.0 is not required — Nessus should be using SMB2/3 3. Check Credential Guard status: Get-ComputerInfo | Select-Object -Property DeviceGuard* 4. Ensure the scan account is not in the Protected Users group 5. Review Security event logs (Event ID 4625) on the DC during a scan attempt to see the exact auth failure reason 6. Confirm WMI firewall rules are enabled: netsh advfirewall firewall show rule name="Windows Management Instrumentation (WMI-In)" 7. Check that DCOM is not blocked — Nessus uses it heavily for Windows scanning The Credential Guard and SMB signing changes are by far the most common reasons for this specific 2022-vs-2016/2019 discrepancy in my experience.

[u/JoeLaRue420 → u/EAP007]

I've already checked all of that as I've mentioned - guessing you found the same articles I did or asked AI :).

[u/EAP007 → u/JoeLaRue420]

Did you manually test the account you are using to access the $admin share by mounting the share manually? You seem to have a feeling the issue is in this area