# stig_rules

vuln_id: V-225016
rule_id: SV-225016r958472_rule
severity: CAT II
cci: CCI-000213
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The "Deny log on as a batch job" user right on member servers must be configured to prevent access from highly privileged domain accounts on domain systems and from unauthenticated access on all systems.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Deny log on as a batch job" user right defines accounts that are prevented from logging on to the system as a batch job, such as Task Scheduler.

  In an Active Directory Domain, denying logons to the Enterprise Admins and Domain Admins groups on lower-trust systems helps mitigate the risk of privilege escalation from credential theft attacks, which could lead to the compromise of an entire domain.

  The Guests group must be assigned to prevent unauthenticated access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Deny log on as a batch job" to include the following:

  Domain Systems Only:
  - Enterprise Admins Group
  - Domain Admins Group

  All Systems:
  - Guests Group

check_text:
  This applies to member servers and standalone or nondomain-joined systems. A separate version applies to domain controllers.

  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If the following accounts or groups are not defined for the "Deny log on as a batch job" user right, this is a finding.

  Domain Systems Only:
  - Enterprise Admins Group
  - Domain Admins Group

  All Systems:
  - Guests Group

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If the following SIDs are not defined for the "SeDenyBatchLogonRight" user right, this is a finding.

  Domain Systems Only:
  S-1-5-root domain-519 (Enterprise Admins)
  S-1-5-domain-512 (Domain Admins)

  All Systems:
  S-1-5-32-546 (Guests)


vuln_id: V-225017
rule_id: SV-225017r958472_rule
severity: CAT II
cci: CCI-000213
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The "Deny log on as a service" user right on member servers must be configured to prevent access from highly privileged domain accounts on domain systems. No other groups or accounts must be assigned this right.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Deny log on as a service" user right defines accounts that are denied logon as a service.

  In an Active Directory Domain, denying logons to the Enterprise Admins and Domain Admins groups on lower-trust systems helps mitigate the risk of privilege escalation from credential theft attacks, which could lead to the compromise of an entire domain.

  Incorrect configurations could prevent services from starting and result in a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Deny log on as a service" to include the following:

  Domain systems:
  - Enterprise Admins Group
  - Domain Admins Group

check_text:
  This applies to member servers. A separate version applies to domain controllers.

  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If the following accounts or groups are not defined for the "Deny log on as a service" user right on domain-joined systems, this is a finding.

  - Enterprise Admins Group
  - Domain Admins Group

  If any accounts or groups are defined for the "Deny log on as a service" user right on nondomain-joined systems, this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If the following SIDs are not defined for the "SeDenyServiceLogonRight" user right on domain-joined systems, this is a finding.

  S-1-5-root domain-519 (Enterprise Admins)
  S-1-5-domain-512 (Domain Admins)


vuln_id: V-225018
rule_id: SV-225018r958472_rule
severity: CAT II
cci: CCI-000213
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The "Deny log on locally" user right on member servers must be configured to prevent access from highly privileged domain accounts on domain systems and from unauthenticated access on all systems.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Deny log on locally" user right defines accounts that are prevented from logging on interactively.

  In an Active Directory Domain, denying logons to the Enterprise Admins and Domain Admins groups on lower-trust systems helps mitigate the risk of privilege escalation from credential theft attacks, which could lead to the compromise of an entire domain.

  The Guests group must be assigned this right to prevent unauthenticated access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Deny log on locally" to include the following:

  Domain Systems Only:
  - Enterprise Admins Group
  - Domain Admins Group

  All Systems:
  - Guests Group

check_text:
  This applies to member servers and standalone or nondomain-joined systems. A separate version applies to domain controllers.

  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If the following accounts or groups are not defined for the "Deny log on locally" user right, this is a finding.

  Domain Systems Only:
  - Enterprise Admins Group
  - Domain Admins Group

  All Systems:
  - Guests Group

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If the following SIDs are not defined for the "SeDenyInteractiveLogonRight" user right, this is a finding.

  Domain Systems Only:
  S-1-5-root domain-519 (Enterprise Admins)
  S-1-5-domain-512 (Domain Admins)

  All Systems:
  S-1-5-32-546 (Guests)


vuln_id: V-225019
rule_id: SV-225019r958672_rule
severity: CAT II
cci: CCI-002314
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The "Deny log on through Remote Desktop Services" user right on member servers must be configured to prevent access from highly privileged domain accounts and all local accounts on domain systems and from unauthenticated access on all systems.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Deny log on through Remote Desktop Services" user right defines the accounts that are prevented from logging on using Remote Desktop Services.

  In an Active Directory Domain, denying logons to the Enterprise Admins and Domain Admins groups on lower-trust systems helps mitigate the risk of privilege escalation from credential theft attacks, which could lead to the compromise of an entire domain.

  Local accounts on domain-joined systems must also be assigned this right to decrease the risk of lateral movement resulting from credential theft attacks.

  The Guests group must be assigned this right to prevent unauthenticated access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Deny log on through Remote Desktop Services" to include the following:

  Domain Systems Only:
  - Enterprise Admins group
  - Domain Admins group
  - Local account (see Note below)

  All Systems:
  - Guests group

  Note: "Local account" is referring to the Windows built-in security group.

check_text:
  This applies to member servers and standalone or nondomain-joined systems. A separate version applies to domain controllers.

  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If the following accounts or groups are not defined for the "Deny log on through Remote Desktop Services" user right, this is a finding.

  Domain Systems Only:
  - Enterprise Admins group
  - Domain Admins group
  - Local account (see Note below)

  All Systems:
  - Guests group

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If the following SIDs are not defined for the "SeDenyRemoteInteractiveLogonRight" user right, this is a finding.

  Domain Systems Only:
  S-1-5-root domain-519 (Enterprise Admins)
  S-1-5-domain-512 (Domain Admins)
  S-1-5-113 ("Local account")

  All Systems:
  S-1-5-32-546 (Guests)

  Note: "Local account" is referring to the Windows built-in security group.


vuln_id: V-225020
rule_id: SV-225020r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The "Enable computer and user accounts to be trusted for delegation" user right must not be assigned to any groups or accounts on member servers.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Enable computer and user accounts to be trusted for delegation" user right allows the "Trusted for Delegation" setting to be changed. This could allow unauthorized users to impersonate other users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Enable computer and user accounts to be trusted for delegation" to be defined but containing no entries (blank).

check_text:
  This applies to member servers and standalone or nondomain-joined systems. A separate version applies to domain controllers.

  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups are granted the "Enable computer and user accounts to be trusted for delegation" user right, this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs are granted the "SeEnableDelegationPrivilege" user right, this is a finding.


vuln_id: V-225021
rule_id: SV-225021r958448_rule
severity: CAT II
title: The DoD Root CA certificates must be installed in the Trusted Root Store.
cci: CCI-000185
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>To ensure secure DoD websites and DoD-signed code are properly validated, the system must trust the DoD Root Certificate Authorities (CAs). The DoD root certificates will ensure that the trust chain is established for server certificates issued from the DoD CAs.

  Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000403-GPOS-00182</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Install the DoD Root CA certificates:
  DoD Root CA 3
  DoD Root CA 4
  DoD Root CA 5
  DoD Root CA 6

  The InstallRoot tool is available on Cyber Exchange at https://cyber.mil/pki-pke/tools-configuration-files. Certificate bundles published by the PKI can be found at https://crl.gds.disa.mil/.

check_text:
  The certificates and thumbprints referenced below apply to unclassified systems; refer to PKE documentation for other networks.

  Open "Windows PowerShell" as an administrator.

  Execute the following command:

  Get-ChildItem -Path Cert:Localmachine\root | Where Subject -Like "*DoD*" | FL Subject, Thumbprint, NotAfter

  If the following certificate "Subject" and "Thumbprint" information is not displayed, this is finding. 

  Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: D73CA91102A2204A36459ED32213B467D7CE97FB
  NotAfter: 12/30/2029

  Subject: CN=DoD Root CA 4, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: B8269F25DBD937ECAFD4C35A9838571723F2D026
  NotAfter: 7/25/2032

  Subject: CN=DoD Root CA 5, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: 4ECB5CC3095670454DA1CBD410FC921F46B8564B
  NotAfter: 6/14/2041
   
  Subject: CN=DoD Root CA 6, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: D37ECF61C0B4ED88681EF3630C4E2FC787B37AEF
  Valid to: Friday, January 24, 2053                                                           

  Alternately, use the Certificates MMC snap-in:

  Run "MMC".

  Select "File", "Add/Remove Snap-in".

  Select "Certificates" and click "Add".

  Select "Computer account" and click "Next".

  Select "Local computer: (the computer this console is running on)" and click "Finish".

  Click "OK".

  Expand "Certificates" and navigate to "Trusted Root Certification Authorities >> Certificates".

  For each of the DoD Root CA certificates noted below:

  Right-click on the certificate and select "Open".

  Select the "Details" tab.

  Scroll to the bottom and select "Thumbprint".

  If the DoD Root CA certificates below are not listed or the value for the "Thumbprint" field is not as noted, this is a finding.

  DoD Root CA 3
  Thumbprint: D73CA91102A2204A36459ED32213B467D7CE97FB
  Valid to: Sunday, December 30, 2029

  DoD Root CA 4
  Thumbprint: B8269F25DBD937ECAFD4C35A9838571723F2D026
  Valid to: Sunday, July 25, 2032

  DoD Root CA 5
  Thumbprint: 4ECB5CC3095670454DA1CBD410FC921F46B8564B
  Valid to: Friday, June 14, 2041

  DoD Root CA 6
  Thumbprint: D37ECF61C0B4ED88681EF3630C4E2FC787B37AEF
  Valid to: Friday, January 24, 2053


vuln_id: V-225022
rule_id: SV-225022r958448_rule
severity: CAT II
cci: CCI-000185
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The DoD Interoperability Root CA cross-certificates must be installed in the Untrusted Certificates Store on unclassified systems.

description:
  <VulnDiscussion>To ensure users do not experience denial of service when performing certificate-based authentication to DoD websites due to the system chaining to a root other than DoD Root CAs, the DoD Interoperability Root CA cross-certificates must be installed in the Untrusted Certificate Store. This requirement only applies to unclassified systems.

  Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000403-GPOS-00182</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Install the DoD Interoperability Root CA cross-certificates on unclassified systems.

  Issued To - Issued By - Thumbprint 
  DoD Root CA 3 - DoD Interoperability Root CA 2 - 49CBE933151872E17C8EAE7F0ABA97FB610F6477                         

  The certificates can be installed using the InstallRoot tool. The tool and user guide are available on Cyber Exchange at https://cyber.mil/pki-pke/tools-configuration-files. Certificate bundles published by the PKI can be found at https://crl.gds.disa.mil/.

check_text:
  Verify the DoD Interoperability cross-certificates are installed on unclassified systems as Untrusted Certificates.

  Run "PowerShell" as an administrator.

  Execute the following command:

  Get-ChildItem -Path Cert:Localmachine\disallowed | Where {$_.Issuer -Like "*DoD Interoperability*" -and $_.Subject -Like "*DoD*"} | FL Subject, Issuer, Thumbprint, NotAfter

  If the following certificate "Subject", "Issuer", and "Thumbprint" information is not displayed, this is a finding. 

  Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Issuer: CN=DoD Interoperability Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: 49CBE933151872E17C8EAE7F0ABA97FB610F6477
  NotAfter: 11/16/2024 9:57:16 AM

  Alternately use the Certificates MMC snap-in:

  Run "MMC".

  Select "File", "Add/Remove Snap-in".

  Select "Certificates", click "Add".

  Select "Computer account", click "Next".

  Select "Local computer: (the computer this console is running on)", click "Finish".

  Click "OK".

  Expand "Certificates" and navigate to Untrusted Certificates >> Certificates.

  For each certificate with "DoD Root CA…" under "Issued To" and "DoD Interoperability Root CA…" under "Issued By":

  Right-click on the certificate and select "Open".

  Select the "Details" tab.

  Scroll to the bottom and select "Thumbprint".

  If the certificates below are not listed or the value for the "Thumbprint" field is not as noted, this is a finding.

  If an expired certificate ("Valid to" date) is not listed in the results, this is not a finding.

  Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Issuer: CN=DoD Interoperability Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: 49CBE933151872E17C8EAE7F0ABA97FB610F6477
  NotAfter: 11/16/2024 9:57:16 AM


vuln_id: V-225023
rule_id: SV-225023r958448_rule
severity: CAT II
cci: CCI-000185
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The US DoD CCEB Interoperability Root CA cross-certificates must be installed in the Untrusted Certificates Store on unclassified systems.

description:
  <VulnDiscussion>To ensure users do not experience denial of service when performing certificate-based authentication to DoD websites due to the system chaining to a root other than DoD Root CAs, the US DoD CCEB Interoperability Root CA cross-certificates must be installed in the Untrusted Certificate Store. This requirement only applies to unclassified systems.

  Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000403-GPOS-00182</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Install the US DoD CCEB Interoperability Root CA cross-certificate on unclassified systems.

  Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Issuer: CN=US DoD CCEB Interoperability Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: 9B74964506C7ED9138070D08D5F8B969866560C8
  NotAfter: 7/18/2025

  The certificates can be installed using the InstallRoot tool. The tool and user guide are available on Cyber Exchange at https://cyber.mil/pki-pke/tools-configuration-files. Certificate bundles published by the PKI can be found at https://crl.gds.disa.mil/.

check_text:
  Verify the US DoD CCEB Interoperability Root CA cross-certificate is installed on unclassified systems as an Untrusted Certificate.

  Run "PowerShell" as an administrator.

  Execute the following command:

  Get-ChildItem -Path Cert:Localmachine\disallowed | Where Issuer -Like "*CCEB Interoperability*" | FL Subject, Issuer, Thumbprint, NotAfter

  If the following certificate "Subject", "Issuer", and "Thumbprint" information is not displayed, this is a finding. 

  Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Issuer: CN=US DoD CCEB Interoperability Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: 9B74964506C7ED9138070D08D5F8B969866560C8
  NotAfter: 7/18/2025

  Alternately use the Certificates MMC snap-in:

  Run "MMC".

  Select "File", "Add/Remove Snap-in".

  Select "Certificates", click "Add".

  Select "Computer account", click "Next".

  Select "Local computer: (the computer this console is running on)", click "Finish".

  Click "OK".

  Expand "Certificates" and navigate to "Untrusted Certificates >> Certificates".

  For each certificate with "US DoD CCEB Interoperability Root CA …" under "Issued By":

  Right-click on the certificate and select "Open".

  Select the "Details" tab.

  Scroll to the bottom and select "Thumbprint".

  If the certificate below is not listed or the value for the "Thumbprint" field is not as noted, this is a finding.

  Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Issuer: CN=US DoD CCEB Interoperability Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US
  Thumbprint: 9B74964506C7ED9138070D08D5F8B969866560C8
  NotAfter: 7/18/2025


vuln_id: V-225024
rule_id: SV-225024r958504_rule
severity: CAT II
title: Windows Server 2016 built-in guest account must be disabled.
cci: CCI-000804
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>A system faces an increased vulnerability threat if the built-in guest account is not disabled. This is a known account that exists on all Windows systems and cannot be deleted. This account is initialized during the installation of the operating system with no password assigned.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Accounts: Guest account status" to "Disabled".

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options.

  If the value for "Accounts: Guest account status" is not set to "Disabled", this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas SecurityPolicy /CFG C:\Path\FileName.Txt

  If "EnableGuestAccount" equals "1" in the file, this is a finding.


vuln_id: V-225025
rule_id: SV-225025r991589_rule
severity: CAT I
title: Local accounts with blank passwords must be restricted to prevent access from the network.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>An account without a password can allow unauthorized access to a system as only the username would be required. Password policies should prevent accounts with blank passwords from existing on a system. However, if a local account with a blank password does exist, enabling this setting will prevent network access, limiting the account to local console logon only.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Accounts: Limit local account use of blank passwords to console logon only" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: LimitBlankPasswordUse

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225026
rule_id: SV-225026r991589_rule
severity: CAT II
title: Windows Server 2016 built-in administrator account must be renamed.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The built-in administrator account is a well-known account subject to attack. Renaming this account to an unidentified name improves the protection of this account and the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Accounts: Rename administrator account" to a name other than "Administrator".

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options.

  If the value for "Accounts: Rename administrator account" is not set to a value other than "Administrator", this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas SecurityPolicy /CFG C:\Path\FileName.Txt

  If "NewAdministratorName" is not something other than "Administrator" in the file, this is a finding.


vuln_id: V-225027
rule_id: SV-225027r991589_rule
severity: CAT II
title: Windows Server 2016 built-in guest account must be renamed.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The built-in guest account is a well-known user account on all Windows systems and, as initially installed, does not require a password. This can allow access to system resources by unauthorized users. Renaming this account to an unidentified name improves the protection of this account and the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Accounts: Rename guest account" to a name other than "Guest".

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options.

  If the value for "Accounts: Rename guest account" is not set to a value other than "Guest", this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas SecurityPolicy /CFG C:\Path\FileName.Txt

  If "NewGuestName" is not something other than "Guest" in the file, this is a finding.


vuln_id: V-225028
rule_id: SV-225028r958442_rule
severity: CAT II
title: Audit policy using subcategories must be enabled.
cci: CCI-000169
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Maintaining an audit trail of system activity logs can help identify configuration errors, troubleshoot service disruptions, and analyze compromises that have occurred, as well as detect attacks. Audit logs are necessary to provide a trail of evidence in case the system or network is compromised. Collecting this data is essential for analyzing the security of information assets and detecting signs of suspicious and unexpected behavior. 
  This setting allows administrators to enable more precise auditing capabilities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: SCENoApplyLegacyAuditPolicy

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225029
rule_id: SV-225029r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Domain member: Digitally encrypt or sign secure channel data (always) must be configured to Enabled.

description:
  <VulnDiscussion>Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but not all information is encrypted. If this policy is enabled, outgoing secure channel traffic will be encrypted and signed.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain member: Digitally encrypt or sign secure channel data (always)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\

  Value Name: RequireSignOrSeal

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225030
rule_id: SV-225030r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Domain member: Digitally encrypt secure channel data (when possible) must be configured to enabled.

description:
  <VulnDiscussion>Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but not all information is encrypted. If this policy is enabled, outgoing secure channel traffic will be encrypted.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain member: Digitally encrypt secure channel data (when possible)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\

  Value Name: SealSecureChannel

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225031
rule_id: SV-225031r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Domain member: Digitally sign secure channel data (when possible) must be configured to Enabled.

description:
  <VulnDiscussion>Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked. If this policy is enabled, outgoing secure channel traffic will be signed.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain member: Digitally sign secure channel data (when possible)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\

  Value Name: SignSecureChannel

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225032
rule_id: SV-225032r971545_rule
severity: CAT II
title: The computer account password must not be prevented from being reset.
cci: CCI-001967
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Computer account passwords are changed automatically on a regular basis. Disabling automatic password changes can make the system more vulnerable to malicious access. Frequent password changes can be a significant safeguard for the system. A new password for the computer account will be generated every 30 days.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain member: Disable machine account password changes" to "Disabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\

  Value Name: DisablePasswordChange

  Value Type: REG_DWORD
  Value: 0x00000000 (0)


vuln_id: V-225033
rule_id: SV-225033r991589_rule
severity: CAT II
title: The maximum age for machine account passwords must be configured to 30 days or less.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Computer account passwords are changed automatically on a regular basis. This setting controls the maximum password age that a machine account may have. This must be set to no more than 30 days, ensuring the machine changes its password monthly.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  This is the default configuration for this setting (30 days).

  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain member: Maximum machine account password age" to "30" or less (excluding "0", which is unacceptable).

check_text:
  This is the default configuration for this setting (30 days).

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\

  Value Name: MaximumPasswordAge

  Value Type: REG_DWORD
  Value: 0x0000001e (30) (or less, but not 0)


vuln_id: V-225034
rule_id: SV-225034r958908_rule
severity: CAT II
title: Windows Server 2016 must be configured to require a strong session key.
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>A computer connecting to a domain controller will establish a secure channel. The secure channel connection may be subject to compromise, such as hijacking or eavesdropping, if strong session keys are not used to establish the connection. Requiring strong session keys enforces 128-bit encryption between systems.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain member: Require strong (Windows 2000 or Later) session key" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\

  Value Name: RequireStrongKey

  Value Type: REG_DWORD
  Value: 0x00000001 (1)
   
  This setting may prevent a system from being joined to a domain if not configured consistently between systems.


vuln_id: V-225035
rule_id: SV-225035r958402_rule
severity: CAT II
title: The machine inactivity limit must be set to 15 minutes, locking the system with the screen saver.
cci: CCI-000057
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Unattended systems are susceptible to unauthorized use and should be locked when unattended. The screen saver should be set at a maximum of 15 minutes and be password protected. This protects critical and sensitive data from exposure to unauthorized personnel with physical access to the computer.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Interactive logon: Machine inactivity limit" to "900" seconds or less, excluding "0" which is effectively disabled.

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: InactivityTimeoutSecs

  Value Type: REG_DWORD
  Value: 0x00000384 (900) (or less, excluding "0" which is effectively disabled)


vuln_id: V-225036
rule_id: SV-225036r958390_rule
severity: CAT II
title: The required legal notice must be configured to display before console logon.
cci: CCI-000048
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.

  Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007, SRG-OS-000228-GPOS-00088</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Interactive Logon: Message text for users attempting to log on" to the following:

  You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

  By using this IS (which includes any device attached to this IS), you consent to the following conditions:

  -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

  -At any time, the USG may inspect and seize data stored on this IS.

  -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

  -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

  -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: LegalNoticeText

  Value Type: REG_SZ
  Value: See message text below

  You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

  By using this IS (which includes any device attached to this IS), you consent to the following conditions:

  -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

  -At any time, the USG may inspect and seize data stored on this IS.

  -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

  -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

  -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.


vuln_id: V-225037
rule_id: SV-225037r958390_rule
severity: CAT III
title: The Windows dialog box title for the legal banner must be configured with the appropriate text.
cci: CCI-000048
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.

  Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Interactive Logon: Message title for users attempting to log on" to "DoD Notice and Consent Banner", "US Department of Defense Warning Statement", or an organization-defined equivalent. 

  If an organization-defined title is used, it can in no case contravene or modify the language of the message text required in WN16-SO-000150.

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: LegalNoticeCaption

  Value Type: REG_SZ
  Value: See message title options below

  "DoD Notice and Consent Banner", "US Department of Defense Warning Statement", or an organization-defined equivalent. 

  If an organization-defined title is used, it can in no case contravene or modify the language of the banner text required in WN16-SO-000150.

  Automated tools may only search for the titles defined above. If an organization-defined title is used, a manual review will be required.


vuln_id: V-225038
rule_id: SV-225038r991589_rule
severity: CAT II
title: The Smart Card removal option must be configured to Force Logoff or Lock Workstation.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Unattended systems are susceptible to unauthorized use and must be locked. Configuring a system to lock when a smart card is removed will ensure the system is inaccessible when unattended.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Interactive logon: Smart card removal behavior" to "Lock Workstation" or "Force Logoff".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\
   
  Value Name: scremoveoption

  Value Type: REG_SZ
  Value: 1 (Lock Workstation) or 2 (Force Logoff)

  If configuring this on servers causes issues, such as terminating users' remote sessions, and the organization has a policy in place that any other sessions on the servers, such as administrative console logons, are manually locked or logged off when unattended or not in use, this would be acceptable. This must be documented with the ISSO.


vuln_id: V-225039
rule_id: SV-225039r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Microsoft network client: Digitally sign communications (always) must be configured to Enabled.

description:
  <VulnDiscussion>The server message block (SMB) protocol provides the basis for many network operations. Digitally signed SMB packets aid in preventing man-in-the-middle attacks. If this policy is enabled, the SMB client will only communicate with an SMB server that performs SMB packet signing.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Microsoft network client: Digitally sign communications (always)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\

  Value Name: RequireSecuritySignature

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225040
rule_id: SV-225040r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Microsoft network client: Digitally sign communications (if server agrees) must be configured to Enabled.

description:
  <VulnDiscussion>The server message block (SMB) protocol provides the basis for many network operations. If this policy is enabled, the SMB client will request packet signing when communicating with an SMB server that is enabled or required to perform SMB packet signing.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Microsoft network client: Digitally sign communications (if server agrees)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\

  Value Name: EnableSecuritySignature

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225041
rule_id: SV-225041r987796_rule
severity: CAT II
title: Unencrypted passwords must not be sent to third-party Server Message Block (SMB) servers.
cci: CCI-000197
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Some non-Microsoft SMB servers only support unencrypted (plain-text) password authentication. Sending plain-text passwords across the network when authenticating to an SMB server reduces the overall security of the environment. Check with the vendor of the SMB server to determine if there is a way to support encrypted password authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Microsoft Network Client: Send unencrypted password to third-party SMB servers" to "Disabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive:  HKEY_LOCAL_MACHINE
  Registry Path:  \SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\

  Value Name:  EnablePlainTextPassword

  Value Type:  REG_DWORD
  Value:  0x00000000 (0)


vuln_id: V-225042
rule_id: SV-225042r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Microsoft network server: Digitally sign communications (always) must be configured to Enabled.

description:
  <VulnDiscussion>The server message block (SMB) protocol provides the basis for many network operations. Digitally signed SMB packets aid in preventing man-in-the-middle attacks. If this policy is enabled, the SMB server will only communicate with an SMB client that performs SMB packet signing.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Microsoft network server: Digitally sign communications (always)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\

  Value Name: RequireSecuritySignature

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225043
rule_id: SV-225043r958908_rule
severity: CAT II
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The setting Microsoft network server: Digitally sign communications (if client agrees) must be configured to Enabled.

description:
  <VulnDiscussion>The server message block (SMB) protocol provides the basis for many network operations. Digitally signed SMB packets aid in preventing man-in-the-middle attacks. If this policy is enabled, the SMB server will negotiate SMB packet signing as requested by the client.

  Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Microsoft network server: Digitally sign communications (if client agrees)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\

  Value Name: EnableSecuritySignature

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225044
rule_id: SV-225044r991589_rule
severity: CAT I
title: Anonymous SID/Name translation must not be allowed.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Allowing anonymous SID/Name translation can provide sensitive information for accessing a system. Only authorized users must be able to perform such translations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network access: Allow anonymous SID/Name translation" to "Disabled".

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options.

  If the value for "Network access: Allow anonymous SID/Name translation" is not set to "Disabled", this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas SecurityPolicy /CFG C:\Path\FileName.Txt

  If "LSAAnonymousNameLookup" equals "1" in the file, this is a finding.


vuln_id: V-225045
rule_id: SV-225045r991589_rule
severity: CAT I
title: Anonymous enumeration of Security Account Manager (SAM) accounts must not be allowed.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Anonymous enumeration of SAM accounts allows anonymous logon users (null session connections) to list all accounts names, thus providing a list of potential points to attack the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network access: Do not allow anonymous enumeration of SAM accounts" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: RestrictAnonymousSAM

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225046
rule_id: SV-225046r958524_rule
severity: CAT I
title: Anonymous enumeration of shares must not be allowed.
cci: CCI-001090
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Allowing anonymous logon users (null session connections) to list all account names and enumerate all shared resources can provide a map of potential points to attack the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network access: Do not allow anonymous enumeration of SAM accounts and shares" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: RestrictAnonymous

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225047
rule_id: SV-225047r991589_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Windows Server 2016 must be configured to prevent anonymous users from having the same permissions as the Everyone group.

description:
  <VulnDiscussion>Access by anonymous users must be restricted. If this setting is enabled, anonymous users have the same rights and permissions as the built-in Everyone group. Anonymous users must not have these permissions or rights.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network access: Let everyone permissions apply to anonymous users" to "Disabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: EveryoneIncludesAnonymous

  Value Type: REG_DWORD
  Value: 0x00000000 (0)


vuln_id: V-225048
rule_id: SV-225048r958524_rule
severity: CAT I
title: Anonymous access to Named Pipes and Shares must be restricted.
cci: CCI-001090
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Allowing anonymous access to named pipes or shares provides the potential for unauthorized system access. This setting restricts access to those defined in "Network access: Named Pipes that can be accessed anonymously" and "Network access: Shares that can be accessed anonymously", both of which must be blank under other requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network access: Restrict anonymous access to Named Pipes and Shares" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\

  Value Name: RestrictNullSessAccess

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225049
rule_id: SV-225049r991589_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Services using Local System that use Negotiate when reverting to NTLM authentication must use the computer identity instead of authenticating anonymously.

description:
  <VulnDiscussion>Services using Local System that use Negotiate when reverting to NTLM authentication may gain unauthorized access if allowed to authenticate anonymously versus using the computer identity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Allow Local System to use computer identity for NTLM" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Control\LSA\

  Value Name: UseMachineId

  Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225050
rule_id: SV-225050r991589_rule
severity: CAT II
title: NTLM must be prevented from falling back to a Null session.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>NTLM sessions that are allowed to fall back to Null (unauthenticated) sessions may gain unauthorized access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Allow LocalSystem NULL session fallback" to "Disabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Control\LSA\MSV1_0\

  Value Name: allownullsessionfallback

  Type: REG_DWORD
  Value: 0x00000000 (0)


vuln_id: V-225051
rule_id: SV-225051r991589_rule
severity: CAT II
title: PKU2U authentication using online identities must be prevented.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>PKU2U is a peer-to-peer authentication protocol. This setting prevents online identities from authenticating to domain-joined systems. Authentication will be centrally managed with Windows user accounts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Allow PKU2U authentication requests to this computer to use online identities" to "Disabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Control\LSA\pku2u\

  Value Name: AllowOnlineID

  Type: REG_DWORD
  Value: 0x00000000 (0)


vuln_id: V-225052
rule_id: SV-225052r971535_rule
severity: CAT II
title: Kerberos encryption types must be configured to prevent the use of DES and RC4 encryption suites.
cci: CCI-000803
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Certain encryption types are no longer considered secure. The DES and RC4 encryption suites must not be used for Kerberos encryption.

  Note: Organizations with domain controllers running earlier versions of Windows where RC4 encryption is enabled, selecting "The other domain supports Kerberos AES Encryption" on domain trusts, may be required to allow client communication across the trust relationship.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Configure encryption types allowed for Kerberos" to "Enabled" with only the following selected:

  AES128_HMAC_SHA1
  AES256_HMAC_SHA1
  Future encryption types   

  Note: Organizations with domain controllers running earlier versions of Windows where RC4 encryption is enabled, selecting "The other domain supports Kerberos AES Encryption" on domain trusts, may be required to allow client communication across the trust relationship.

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

  Value Name: SupportedEncryptionTypes

  Value Type: REG_DWORD
  Value: 0x7ffffff8 (2147483640)


vuln_id: V-225053
rule_id: SV-225053r982199_rule
severity: CAT I
title: Windows Server 2016 must be configured to prevent the storage of the LAN Manager hash of passwords.
cci: CCI-000196
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The LAN Manager hash uses a weak encryption algorithm and there are several tools available that use this hash to retrieve account passwords. This setting controls whether a LAN Manager hash of the password is stored in the SAM the next time the password is changed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Do not store LAN Manager hash value on next password change" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: NoLMHash

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225054
rule_id: SV-225054r991589_rule
severity: CAT I
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The LAN Manager authentication level must be set to send NTLMv2 response only and to refuse LM and NTLM.

description:
  <VulnDiscussion>The Kerberos v5 authentication protocol is the default for authentication of users who are logging on to domain accounts. NTLM, which is less secure, is retained in later Windows versions for compatibility with clients and servers that are running earlier versions of Windows or applications that still use it. It is also used to authenticate logons to standalone or nondomain-joined computers that are running later versions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: LAN Manager authentication level" to "Send NTLMv2 response only. Refuse LM & NTLM".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\

  Value Name: LmCompatibilityLevel

  Value Type: REG_DWORD
  Value: 0x00000005 (5)


vuln_id: V-225055
rule_id: SV-225055r991589_rule
severity: CAT II
title: Windows Server 2016 must be configured to at least negotiate signing for LDAP client signing.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>This setting controls the signing requirements for LDAP clients. This must be set to "Negotiate signing" or "Require signing", depending on the environment and type of LDAP server in use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: LDAP client signing requirements" to "Negotiate signing" at a minimum.

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Services\LDAP\

  Value Name: LDAPClientIntegrity

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225056
rule_id: SV-225056r991589_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Session security for NTLM SSP-based clients must be configured to require NTLMv2 session security and 128-bit encryption.

description:
  <VulnDiscussion>Microsoft has implemented a variety of security support providers for use with Remote Procedure Call (RPC) sessions. All of the options must be enabled to ensure the maximum security level.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Minimum session security for NTLM SSP based (including secure RPC) clients" to "Require NTLMv2 session security" and "Require 128-bit encryption" (all options selected).

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\

  Value Name: NTLMMinClientSec

  Value Type: REG_DWORD
  Value: 0x20080000 (537395200)


vuln_id: V-225057
rule_id: SV-225057r991589_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Session security for NTLM SSP-based servers must be configured to require NTLMv2 session security and 128-bit encryption.

description:
  <VulnDiscussion>Microsoft has implemented a variety of security support providers for use with Remote Procedure Call (RPC) sessions. All of the options must be enabled to ensure the maximum security level.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Minimum session security for NTLM SSP based (including secure RPC) servers" to "Require NTLMv2 session security" and "Require 128-bit encryption" (all options selected).

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\

  Value Name: NTLMMinServerSec

  Value Type: REG_DWORD
  Value: 0x20080000 (537395200)


vuln_id: V-225058
rule_id: SV-225058r958450_rule
severity: CAT II
title: Users must be required to enter a password to access private keys stored on the computer.
cci: CCI-000186
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure.

  The cornerstone of the PKI is the private key used to encrypt or digitally sign information.

  If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user.

  Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "System cryptography: Force strong key protection for user keys stored on the computer" to "User must enter a password each time they use a key".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive:  HKEY_LOCAL_MACHINE
  Registry Path:  \SOFTWARE\Policies\Microsoft\Cryptography\

  Value Name:  ForceKeyProtection

  Type:  REG_DWORD
  Value:  0x00000002 (2)


vuln_id: V-225059
rule_id: SV-225059r958408_rule
severity: CAT II
cci: CCI-000068
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Windows Server 2016 must be configured to use FIPS-compliant algorithms for encryption, hashing, and signing.

description:
  <VulnDiscussion>This setting ensures the system uses algorithms that are FIPS-compliant for encryption, hashing, and signing. FIPS-compliant algorithms meet specific standards established by the U.S. Government and must be the algorithms used for all OS encryption functions.

  Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000478-GPOS-00223</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\

  Value Name: Enabled

  Value Type: REG_DWORD
  Value: 0x00000001 (1)
   
  Clients with this setting enabled will not be able to communicate via digitally encrypted or signed protocols with servers that do not support these algorithms. Both the browser and web server must be configured to use TLS; otherwise. the browser will not be able to connect to a secure site.


vuln_id: V-225060
rule_id: SV-225060r991589_rule
severity: CAT III
title: The default permissions of global system objects must be strengthened.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Windows systems maintain a global list of shared system resources such as DOS device names, mutexes, and semaphores. Each type of object is created with a default Discretionary Access Control List (DACL) that specifies who can access the objects with what permissions. When this policy is enabled, the default DACL is stronger, allowing non-administrative users to read shared objects but not to modify shared objects they did not create.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)" to "Enabled".

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SYSTEM\CurrentControlSet\Control\Session Manager\

  Value Name: ProtectionMode

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225061
rule_id: SV-225061r1050790_rule
severity: CAT II
title: User Account Control approval mode for the built-in Administrator must be enabled.
cci: CCI-002038
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting configures the built-in Administrator account so that it runs in Admin Approval Mode.

  Satisfies: SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00156</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Admin Approval Mode for the Built-in Administrator account" to "Enabled".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: FilterAdministratorToken

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225062
rule_id: SV-225062r958518_rule
severity: CAT II
title: UIAccess applications must not be allowed to prompt for elevation without using the secure desktop.
cci: CCI-001084
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting prevents User Interface Accessibility programs from disabling the secure desktop for elevation prompts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop" to "Disabled".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: EnableUIADesktopToggle

  Value Type: REG_DWORD
  Value: 0x00000000 (0)


vuln_id: V-225063
rule_id: SV-225063r958518_rule
severity: CAT II
title: User Account Control must, at a minimum, prompt administrators for consent on the secure desktop.
cci: CCI-001084
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting configures the elevation requirements for logged-on administrators to complete a task that requires raised privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" to "Prompt for consent on the secure desktop".

  The more secure option for this setting, "Prompt for credentials on the secure desktop", would also be acceptable.

check_text:
  UAC requirements are NA for Server Core installations (this is default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: ConsentPromptBehaviorAdmin

  Value Type: REG_DWORD
  Value: 0x00000002 (2) (Prompt for consent on the secure desktop)
  0x00000001 (1) (Prompt for credentials on the secure desktop)


vuln_id: V-225064
rule_id: SV-225064r1050790_rule
severity: CAT II
title: User Account Control must automatically deny standard user requests for elevation.
cci: CCI-002038
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting controls the behavior of elevation when requested by a standard user account.

  Satisfies: SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00156</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Behavior of the elevation prompt for standard users" to "Automatically deny elevation requests".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: ConsentPromptBehaviorUser

  Value Type: REG_DWORD
  Value: 0x00000000 (0)


vuln_id: V-225065
rule_id: SV-225065r958518_rule
severity: CAT II
cci: CCI-001084
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  User Account Control must be configured to detect application installations and prompt for elevation.

description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting requires Windows to respond to application installation requests by prompting for credentials.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Detect application installations and prompt for elevation" to "Enabled".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: EnableInstallerDetection

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225066
rule_id: SV-225066r958518_rule
severity: CAT II
cci: CCI-001084
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  User Account Control must only elevate UIAccess applications that are installed in secure locations.

description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting configures Windows to only allow applications installed in a secure location on the file system, such as the Program Files or the Windows\System32 folders, to run with elevated privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Only elevate UIAccess applications that are installed in secure locations" to "Enabled".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: EnableSecureUIAPaths

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225067
rule_id: SV-225067r1050790_rule
severity: CAT II
title: User Account Control must run all administrators in Admin Approval Mode, enabling UAC.
cci: CCI-002038
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting enables UAC.

  Satisfies: SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00156</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Run all administrators in Admin Approval Mode" to "Enabled".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: EnableLUA

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225068
rule_id: SV-225068r958518_rule
severity: CAT II
title: User Account Control must virtualize file and registry write failures to per-user locations.
cci: CCI-001084
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>User Account Control (UAC) is a security mechanism for limiting the elevation of privileges, including administrative accounts, unless authorized. This setting configures non-UAC-compliant applications to run in virtualized file and registry entries in per-user locations, allowing them to run.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "User Account Control: Virtualize file and registry write failures to per-user locations" to "Enabled".

check_text:
  UAC requirements are NA for Server Core installations (this is the default installation option for Windows Server 2016 versus Server with Desktop Experience) as well as Nano Server.

  If the following registry value does not exist or is not configured as specified, this is a finding.

  Registry Hive: HKEY_LOCAL_MACHINE 
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\

  Value Name: EnableVirtualization

  Value Type: REG_DWORD
  Value: 0x00000001 (1)


vuln_id: V-225069
rule_id: SV-225069r991589_rule
severity: CAT II
title: Zone information must be preserved when saving attachments.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Attachments from outside sources may contain malicious code. Preserving zone of origin (Internet, intranet, local, restricted) information on file attachments allows Windows to determine risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  The default behavior is for Windows to mark file attachments with their zone information.

  If this needs to be corrected, configure the policy value for User Configuration >> Administrative Templates >> Windows Components >> Attachment Manager >> "Do not preserve zone information in file attachments" to "Not Configured" or "Disabled".

check_text:
  The default behavior is for Windows to mark file attachments with their zone information.

  If the registry Value Name below does not exist, this is not a finding.

  If it exists and is configured with a value of "2", this is not a finding.

  If it exists and is configured with a value of "1", this is a finding.

  Registry Hive: HKEY_CURRENT_USER
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Attachments\

  Value Name: SaveZoneInformation

  Value Type: REG_DWORD
  Value: 0x00000002 (2) (or if the Value Name does not exist)


vuln_id: V-225070
rule_id: SV-225070r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Access Credential Manager as a trusted caller user right must not be assigned to any groups or accounts.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Access Credential Manager as a trusted caller" user right may be able to retrieve the credentials of other accounts from Credential Manager.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Access Credential Manager as a trusted caller" to be defined but containing no entries (blank).

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups are granted the "Access Credential Manager as a trusted caller" user right, this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs are granted the "SeTrustedCredManAccessPrivilege" user right, this is a finding.


vuln_id: V-225071
rule_id: SV-225071r958726_rule
severity: CAT I
title: The Act as part of the operating system user right must not be assigned to any groups or accounts.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Act as part of the operating system" user right can assume the identity of any user and gain access to resources that the user is authorized to access. Any accounts with this right can take complete control of a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Act as part of the operating system" to be defined but containing no entries (blank).

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups (to include administrators), are granted the "Act as part of the operating system" user right, this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs are granted the "SeTcbPrivilege" user right, this is a finding.

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).

  Passwords for accounts with this user right must be protected as highly privileged accounts.


vuln_id: V-225072
rule_id: SV-225072r958472_rule
severity: CAT II
title: The Allow log on locally user right must only be assigned to the Administrators group.
cci: CCI-000213
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Allow log on locally" user right can log on interactively to a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Allow log on locally" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Allow log on locally" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeInteractiveLogonRight" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225073
rule_id: SV-225073r958726_rule
severity: CAT II
title: The Back up files and directories user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Back up files and directories" user right can circumvent file and directory permissions and could allow access to sensitive data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Back up files and directories" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Back up files and directories" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeBackupPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225074
rule_id: SV-225074r958726_rule
severity: CAT II
title: The Create a pagefile user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Create a pagefile" user right can change the size of a pagefile, which could affect system performance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Create a pagefile" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Create a pagefile" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeCreatePagefilePrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)


vuln_id: V-225076
rule_id: SV-225076r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Create global objects user right must only be assigned to Administrators, Service, Local Service, and Network Service.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Create global objects" user right can create objects that are available to all sessions, which could affect processes in other users' sessions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Create global objects" to include only the following accounts or groups:

  - Administrators
  - Service
  - Local Service
  - Network Service

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Create global objects" user right, this is a finding.

  - Administrators
  - Service
  - Local Service
  - Network Service

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeCreateGlobalPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)
  S-1-5-6 (Service)
  S-1-5-19 (Local Service)
  S-1-5-20 (Network Service)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225077
rule_id: SV-225077r958726_rule
severity: CAT II
title: The Create permanent shared objects user right must not be assigned to any groups or accounts.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Create permanent shared objects" user right could expose sensitive data by creating shared objects.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Create permanent shared objects" to be defined but containing no entries (blank).

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups are granted the "Create permanent shared objects" user right, this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs are granted the "SeCreatePermanentPrivilege" user right, this is a finding.


vuln_id: V-225078
rule_id: SV-225078r958726_rule
severity: CAT II
title: The Create symbolic links user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Create symbolic links" user right can create pointers to other objects, which could expose the system to attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Create symbolic links" to include only the following accounts or groups:

  - Administrators

  Systems that have the Hyper-V role will also have "Virtual Machines" given this user right. If this needs to be added manually, enter it as "NT Virtual Machine\Virtual Machines".

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Create symbolic links" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeCreateSymbolicLinkPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  Systems that have the Hyper-V role will also have "Virtual Machines" given this user right (this may be displayed as "NT Virtual Machine\Virtual Machines", SID S-1-5-83-0). This is not a finding.


vuln_id: V-225079
rule_id: SV-225079r958726_rule
severity: CAT I
title: The Debug programs user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Debug programs" user right can attach a debugger to any process or to the kernel, providing complete access to sensitive and critical operating system components. This right is given to Administrators in the default configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Debug programs" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Debug programs" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeDebugPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).

  Passwords for application accounts with this user right must be protected as highly privileged accounts.


vuln_id: V-225080
rule_id: SV-225080r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Force shutdown from a remote system user right must only be assigned to the Administrators group.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Force shutdown from a remote system" user right can remotely shut down a system, which could result in a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Force shutdown from a remote system" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Force shutdown from a remote system" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeRemoteShutdownPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)


vuln_id: V-225081
rule_id: SV-225081r958726_rule
severity: CAT II
title: The Generate security audits user right must only be assigned to Local Service and Network Service.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Generate security audits" user right specifies users and processes that can generate Security Log audit records, which must only be the system service accounts defined.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Generate security audits" to include only the following accounts or groups:

  - Local Service
  - Network Service

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Generate security audits" user right, this is a finding.

  - Local Service
  - Network Service

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeAuditPrivilege" user right, this is a finding.

  S-1-5-19 (Local Service)
  S-1-5-20 (Network Service)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225082
rule_id: SV-225082r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Impersonate a client after authentication user right must only be assigned to Administrators, Service, Local Service, and Network Service.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Impersonate a client after authentication" user right allows a program to impersonate another user or account to run on their behalf. An attacker could use this to elevate privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Impersonate a client after authentication" to include only the following accounts or groups:

  - Administrators
  - Service
  - Local Service
  - Network Service

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Impersonate a client after authentication" user right, this is a finding.

  - Administrators
  - Service
  - Local Service
  - Network Service

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeImpersonatePrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)
  S-1-5-6 (Service)
  S-1-5-19 (Local Service)
  S-1-5-20 (Network Service)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225083
rule_id: SV-225083r958726_rule
severity: CAT II
title: The Increase scheduling priority user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Increase scheduling priority" user right can change a scheduling priority, causing performance issues or a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Increase scheduling priority" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Increase scheduling priority" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeIncreaseBasePriorityPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225084
rule_id: SV-225084r958726_rule
severity: CAT II
title: The Load and unload device drivers user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Load and unload device drivers" user right allows a user to load device drivers dynamically on a system. This could be used by an attacker to install malicious code.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Load and unload device drivers" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Load and unload device drivers" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeLoadDriverPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)


vuln_id: V-225085
rule_id: SV-225085r958726_rule
severity: CAT II
title: The Lock pages in memory user right must not be assigned to any groups or accounts.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Lock pages in memory" user right allows physical memory to be assigned to processes, which could cause performance issues or a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Lock pages in memory" to be defined but containing no entries (blank).

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups are granted the "Lock pages in memory" user right, this is a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs are granted the "SeLockMemoryPrivilege" user right, this is a finding.

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225086
rule_id: SV-225086r958434_rule
severity: CAT II
title: The Manage auditing and security log user right must only be assigned to the Administrators group.
cci: CCI-000162
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Manage auditing and security log" user right can manage the security log and change auditing configurations. This could be used to clear evidence of tampering.

  Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000063-GPOS-00032, SRG-OS-000337-GPOS-00129</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Manage auditing and security log" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeSecurityPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If the organization has an Auditors group, the assignment of this group to the user right would not be a finding.

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225087
rule_id: SV-225087r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Modify firmware environment values user right must only be assigned to the Administrators group.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Modify firmware environment values" user right can change hardware configuration environment variables. This could result in hardware failures or a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Modify firmware environment values" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Modify firmware environment values" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeSystemEnvironmentPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)


vuln_id: V-225088
rule_id: SV-225088r958726_rule
severity: CAT II
title: The Perform volume maintenance tasks user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Perform volume maintenance tasks" user right can manage volume and disk configurations. This could be used to delete volumes, resulting in data loss or a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> Perform volume maintenance tasks to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If an application requires this user right, this is not a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeManageVolumePrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)


vuln_id: V-225089
rule_id: SV-225089r958726_rule
severity: CAT II
title: The Profile single process user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Profile single process" user right can monitor non-system processes performance. An attacker could use this to identify processes to attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Profile single process" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Profile single process" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeProfileSingleProcessPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)


vuln_id: V-225091
rule_id: SV-225091r958726_rule
severity: CAT I
title: The Create a token object user right must not be assigned to any groups or accounts.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  The "Create a token object" user right allows a process to create an access token. This could be used to provide elevated rights and compromise a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Create a token object" to be defined but containing no entries (blank).

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups are granted the "Create a token object" user right, this is a finding.

  If an application requires this user right, this would not be a finding.

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs are granted the "SeCreateTokenPrivilege" user right, this is a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).

  Passwords for application accounts with this user right must be protected as highly privileged accounts.


vuln_id: V-225092
rule_id: SV-225092r958726_rule
severity: CAT II
title: The Restore files and directories user right must only be assigned to the Administrators group.
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Restore files and directories" user right can circumvent file and directory permissions and could allow access to sensitive data. It could also be used to overwrite more current data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Restore files and directories" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Restore files and directories" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeRestorePrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-225093
rule_id: SV-225093r958726_rule
severity: CAT II
cci: CCI-002235
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Take ownership of files or other objects user right must only be assigned to the Administrators group.

description:
  <VulnDiscussion>Inappropriate granting of user rights can provide system, administrative, and other high-level capabilities.

  Accounts with the "Take ownership of files or other objects" user right can take ownership of objects and make changes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Take ownership of files or other objects" to include only the following accounts or groups:

  - Administrators

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Take ownership of files or other objects" user right, this is a finding.

  - Administrators

  For server core installations, run the following command:

  Secedit /Export /Areas User_Rights /cfg c:\path\filename.txt

  Review the text file.

  If any SIDs other than the following are granted the "SeTakeOwnershipPrivilege" user right, this is a finding.

  S-1-5-32-544 (Administrators)

  If an application requires this user right, this would not be a finding.

  Vendor documentation must support the requirement for having the user right.

  The requirement must be documented with the ISSO.

  The application account must meet requirements for application account passwords, such as length (WN16-00-000060) and required frequency of changes (WN16-00-000070).


vuln_id: V-236000
rule_id: SV-236000r958478_rule
severity: CAT II
title: The Windows Explorer Preview pane must be disabled for Windows Server 2016.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>A known vulnerability in Windows could allow the execution of malicious code by either opening a compromised document or viewing it in the Windows Preview pane.

  Organizations must disable the Windows Preview pane and Windows Detail pane.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Ensure the following settings are configured for Windows Server 2016 locally or applied through group policy. 

  Configure the policy value for User Configuration >> Administrative Templates >> Windows Components >> File Explorer >> Explorer Frame Pane "Turn off Preview Pane" to "Enabled".

  Configure the policy value for User Configuration >> Administrative Templates >> Windows Components >> File Explorer >> Explorer Frame Pane "Turn on or off details pane" to "Enabled" and "Configure details pane" to "Always hide".

check_text:
  If the following registry values do not exist or are not configured as specified, this is a finding:

  Registry Hive: HKEY_CURRENT_USER
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer

  Value Name: NoPreviewPane

  Value Type: REG_DWORD

  Value: 1

  Registry Hive: HKEY_CURRENT_USER
  Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer

  Value Name: NoReadingPane

  Value Type: REG_DWORD

  Value: 1


vuln_id: V-257502
rule_id: SV-257502r958420_rule
severity: CAT II
title: Windows Server 2016 must have PowerShell Transcription enabled.
cci: CCI-000134
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Maintaining an audit trail of system activity logs can help identify configuration errors, troubleshoot service disruptions, and analyze compromises that have occurred, as well as detect attacks. Audit logs are necessary to provide a trail of evidence in case the system or network is compromised. Collecting this data is essential for analyzing the security of information assets and detecting signs of suspicious and unexpected behavior.

  Enabling PowerShell Transcription will record detailed information from the processing of PowerShell commands and scripts. This can provide additional detail when malware has run on a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Administrative Templates >> Windows Components >> Windows PowerShell >> "Turn on PowerShell Transcription" to "Enabled".

  Specify the Transcript output directory to point to a Central Log Server or another secure location to prevent user access.

check_text:
  If the following registry value does not exist or is not configured as specified, this is a finding:

  Registry Hive: HKEY_LOCAL_MACHINE
  Registry Path: \SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription\

  Value Name: EnableTranscripting

  Value Type: REG_DWORD
  Value: 1


vuln_id: V-271430
rule_id: SV-271430r1059573_rule
severity: CAT I
title: Windows Server 2016 must be configured for name-based strong mappings for certificates.
cci: CCI-000213
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Weak mappings give rise to security vulnerabilities and demand hardening measures. Certificate names must be correctly mapped to the intended user account in Active Directory. A lack of strong name-based mappings allows certain weak certificate mappings, such as Issuer/Subject AltSecID and User Principal Names (UPN) mappings, to be treated as strong mappings.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  For servers acting as a domain controller, upgrade the operating system to Microsoft Server 2019 or greater.

check_text:
  This requirement is not applicable for Member Servers.

  Note: This requirement is a permanent finding for server 2016 domain controllers per DOD CIO Memo Upgrading of MS Domain Controller OS to MS Server 2019 or Later (CIO000911-23).

  If the server is acting as a domain controller, this is a finding.


vuln_id: V-259334
rule_id: SV-259334r960735_rule
severity: CAT II
title: The Windows DNS Server must restrict incoming dynamic update requests to known clients.
cci: CCI-000054
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) on any system.

  A DNS server's function requires it to be able to handle multiple sessions at a time, so limiting concurrent sessions could impact availability.

  Primary name servers must be configured to limit the actual hosts from which they will accept dynamic updates and zone transfer requests, and all name servers should be configured to limit the hosts from/to which they receive/send zone transfers. Restricting sessions to known hosts will mitigate the DoS vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Once selected, right-click the name of the zone.

  From the displayed context menu, click the "Properties" option.

  On the opened domain's properties box, click the "General" tab.

  If the "Type:" is not "Active Directory-Integrated", configure the zone for Active Directory integration.

  Select "Secure only" from the "Dynamic updates:" drop-down list.

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc". 

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Once selected, right-click the name of the zone.

  From the displayed context menu, click the "Properties" option.

  On the opened domain's properties box, click the "General" tab.

  Verify the "Type:" is "Active Directory-Integrated".

  Verify "Dynamic updates" has "Secure only" selected.

  If the zone is "Active Directory-Integrated" and "Dynamic updates" are not configured for "Secure only", this is a finding.


vuln_id: V-259335
rule_id: SV-259335r987677_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must be configured to record who added/modified/deleted DNS zone information.

description:
  <VulnDiscussion>Without a means for identifying the individual that produced the information, the information cannot be relied on. Identifying the validity of information may be delayed or deterred.

  This requirement ensures organizational personnel have a means to identify who produced or changed specific information in transfers, zone information, or DNS configuration changes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  If not automatically started, initialize the "Server Manager" window by clicking its icon from the bottom left corner of the screen.

  On the opened "Server Manager" window, from the left pane, click to select "DNS".

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the displayed context menu, click the "DNS Manager" option.

  Click the "Event Logging" tab.

  Select the "Errors and warnings" or "All events" option.

  Click "Apply".

  Click "OK".

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  Right-click the DNS server and select "Properties".

  Click the "Event Logging" tab. By default, all events are logged.

  Verify "Errors and warnings" or "All events" is selected.

  If any option other than "Errors and warnings" or "All events" is selected, this is a finding.


vuln_id: V-259336
rule_id: SV-259336r987679_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must notify the DNS administrator in the event of an error validating another DNS server's identity.

description:
  <VulnDiscussion>Failing to act on validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, using cryptographic checksums. Validations must be performed automatically.

  At a minimum, the application must log the validation error. However, more stringent actions can be taken based on the security posture and value of the information. The organization should consider the system's environment and impact of the errors when defining the actions. Additional examples of actions include automated notification to administrators, halting system process, or halting the specific operation.

  The DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the operating system/network device manager, but the configuration to trigger the auditing is controlled by the DNS server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  To detect and notify the administrator, configure a third-party event monitoring system or, at a minimum, document and implement a procedure to require the administrator to check the DNS logs on a routine, daily basis.

check_text:
  Windows DNS Servers hosting Active Directory (AD)-integrated zones transfer zone information via AD replication. Windows DNS Servers hosting non-AD-integrated zones as a secondary name server and/or not hosting AD-integrated zones use zone transfer to sync zone data.

  If the Windows DNS Server hosts only AD-integrated zones and all other name servers for the zones hosted are Active Directory Domain Controllers, this requirement is not applicable.

  If the Windows DNS Server is not an Active Directory Domain Controller or is a secondary name server for a zone with a non-AD-integrated name server as the master, this requirement is applicable.

  Administrator notification is only possible if a third-party event monitoring system is configured or, at a minimum, there are documented procedures requiring the administrator to review the DNS logs on a routine, daily basis.

  If a third-party event monitoring system is not configured or a document procedure is not in place requiring the administrator to review the DNS logs on a routine, daily basis, this is a finding.


vuln_id: V-259337
rule_id: SV-259337r960879_rule
severity: CAT II
title: The Windows DNS Server log must be enabled.
cci: CCI-000169
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. The actual auditing is performed by the operating system/network device manager, but the configuration to trigger the auditing is controlled by the DNS server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  Right-click the DNS server and select "Properties".

  Click the "Event Logging" tab. By default, all events are logged.

  Select the "Errors and warnings" or "All events" option.

  Click "Apply".

  Click "OK".

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  Right-click the DNS server and select "Properties".

  Click the "Event Logging" tab. By default, all events are logged.

  Verify "Errors and warnings" or "All events" is selected.

  If any option other than "Errors and warnings" or "All events" is selected, this is a finding.


vuln_id: V-259338
rule_id: SV-259338r1028386_rule
severity: CAT II
title: The "Manage auditing and security log" user right must be assigned only to authorized personnel.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. The actual auditing is performed by the operating system/network device manager, but the configuration to trigger the auditing is controlled by the DNS server.

  Because the configuration of the audit logs on the DNS server dictates which events are logged to correlate events, the permissions for configuring the audit logs must be restricted to only those with the role of information system security manager (ISSM) or those appointed by the ISSM.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the permissions on the DNS logs.

  Standard user accounts or groups must not have greater than READ access.

  The default permissions listed below satisfy this requirement:

  Eventlog - Full Control
  SYSTEM - Full Control
  Administrators - Full Control

  The default locations are:

  DNS Server %SystemRoot%\System32\Winevt\Logs\DNS Server.evtx

check_text:
  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding:

  Administrators 
  Auditors (if the site has an Auditors group that further limits this privilege)

  If an application requires this user right, this is not a finding. Vendor documentation must support the requirement for having the user right. The requirement must be documented with the ISSO. The application account must meet requirements for application account passwords.

  Verify the permissions on the DNS logs.

  Standard user accounts or groups must not have greater than READ access.

  The default locations are:

  DNS Server %SystemRoot%\System32\Winevt\Logs\DNS Server.evtx

  Use PowerShell and go to PS C:\Windows\System32\winevt\logs> icacls.exe 'dns server .evtx'

  The default permissions listed below satisfy this requirement:

  Eventlog - Full Control (I)(F)
  SYSTEM - Full Control (I)(F)
  Administrators (I)(F)

  If the permissions for these files are not as restrictive as the access control lists above, this is a finding.


vuln_id: V-259339
rule_id: SV-259339r961104_rule
severity: CAT II
cci: CCI-001179
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The validity period for the Resource Record Signatures (RRSIGs) covering the Delegation Signer (DS) Resource Record (RR) for a zone's delegated children must be no less than two days and no more than one week.

description:
  <VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a zone signing key (ZSK) can use that key only during the key signing key's (KSK's) signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.

  To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to one week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone. 

  Right-click on the zone and choose DNSSEC >> Properties.
   
  On the ZSK tab, for DS signature validity period (hours), choose more than 48 and less than 168.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone. 

  View the validity period for the DS RR. 

  If the validity period for the DS RR for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding.


vuln_id: V-259340
rule_id: SV-259340r961863_rule
severity: CAT II
title: The Windows DNS name servers for a zone must be geographically dispersed.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>In addition to network-based separation, authoritative name servers should be dispersed geographically. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located in the same building. One approach is to locate some authoritative name servers in their own premises and others in their internet service provider's data centers or in partnering organizations.

  A network administrator may choose to use a "hidden" primary authoritative server and have only secondary servers visible on the network. A hidden primary authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the primary authoritative name server is hidden, a secondary authoritative name server may reside in the same building as the hidden primary.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  For non-AD integrated Windows DNS Servers, distribute secondary authoritative servers to be in different buildings from the primary authoritative server.

check_text:
  Windows DNS Servers that are Active Directory (AD) integrated must be located where required to meet the AD services. 

  If all the Windows DNS Servers are AD integrated, this check is not applicable.

  If any or all the Windows DNS Servers are standalone and non-AD integrated, verify their geographic location with the system administrator.

  If any or all of the authoritative name servers are located in the same building as the primary authoritative name server and the primary authoritative name server is not "hidden", this is a finding.


vuln_id: V-259341
rule_id: SV-259341r1081088_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must prohibit recursion on authoritative name servers for which forwarders have not been configured for external queries.

description:
  <VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to nonexistent hosts (which constitutes a denial of service) or hosts that masquerade as legitimate ones to obtain sensitive data or passwords. 

  To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select "Properties".

  Click the "Forwarders" tab.

  If forwarders are not being used, click the "Advanced" tab. 

  Select the "Disable recursion (also disables forwarders)" check box.

check_text:
  Note: In Windows DNS Server, if forwarders are configured, the recursion setting must also be enabled because disabling recursion will disable forwarders.

  If forwarders are not used, recursion must be disabled.

  In both cases, the use of root hints must be disabled. The root hints configuration requirement is addressed in WDNS-22-000012.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select "Properties".

  Click the "Forwarders" tab.

  If forwarders are enabled and configured, this check is not applicable.

  If forwarders are not enabled, click the "Advanced" tab and verify the "Disable recursion (also disables forwarders)" check box is selected.

  If forwarders are not enabled and configured, and the "Disable recursion (also disables forwarders)" check box in the "Advanced" tab is not selected, this is a finding. This is not applicable for classified networks.


vuln_id: V-259342
rule_id: SV-259342r961470_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Forwarders on an authoritative Windows DNS Server, if enabled for external resolution, must forward only to an internal, non-Active Directory (AD)-integrated DNS server or to the DOD Enterprise Recursive Services (ERS).

description:
  <VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to nonexistent hosts (which constitutes a denial of service) or hosts that masquerade as legitimate ones to obtain sensitive data or passwords. 

  To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select "Properties".

  Click the "Forwarders" tab.

  Replace the forwarders being used with another DOD-managed DNS server or the DOD ERS.

  Deselect "Use root hints if no forwarders are available".

check_text:
  Note: If the Windows DNS Server is in the classified network, this check is not applicable. If forwarders are not being used, this is not applicable.

  Note: In Windows DNS Server, if forwarders are configured, the recursion setting must also be enabled because disabling recursion will disable forwarders.

  If forwarders are not used, recursion must be disabled. In both cases, the use of root hints must be disabled.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select "Properties".

  Click the "Forwarders" tab.

  Review the IP address(es) for the forwarder(s) use.

  If the DNS server does not forward to another DOD-managed DNS server or to the DOD ERS, this is a finding.

  If "Use root hints if no forwarders are available" is selected, this is a finding.


vuln_id: V-259343
rule_id: SV-259343r961470_rule
severity: CAT I
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server with a caching name server role must restrict recursive query responses to only the IP addresses and IP address ranges of known supported clients.

description:
  <VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to nonexistent hosts (which constitutes a denial of service) or hosts that masquerade as legitimate ones to obtain sensitive data or passwords.

  To guard against poisoning, name servers specifically fulfilling the role of providing recursive query responses for external zones must be segregated from name servers authoritative for internal zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Implement DNSSEC on all non-AD-integrated, standalone, caching Windows DNS Servers to ensure the caching server validates signed zones when resolving and caching.

check_text:
  Note: Sinkhole name servers host records that are manually added and for which the name server is not authoritative. It is configured and intended to block resolvers from reaching a destination by directing the query to a sinkhole. If the sinkhole name server is not authoritative for any zones and serves only as a caching/forwarding name server, this check is not applicable.

  The non-Active Directory (AD)-integrated, standalone, caching Windows DNS Server must be configured to be DNSSEC aware. When performing caching and lookups, the caching name server must be able to obtain a zone signing key (ZSK) DNSKEY record and corresponding RRSIG record for the queried record. It will use this information to compute the hash for the hostname being resolved. The caching name server decrypts the RRSIG record for the hostname being resolved with the zone's ZSK to get the RRSIG record hash. The caching name server compares the hashes and ensures they match.

  If the non-AD-integrated, standalone, caching Windows DNS Server is not configured to be DNSSEC aware, this is a finding.


vuln_id: V-259344
rule_id: SV-259344r961635_rule
severity: CAT II
cci: CCI-002421
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must implement cryptographic mechanisms to detect changes to information during transmission.

description:
  <VulnDiscussion>Encrypting information for transmission protects it from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes.

  Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: If the Windows DNS Server hosts only Active Directory (AD)-integrated zones and does not host any file-based zones, this is not applicable. 

  Note: This requirement does not apply for classified environments.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2022 10:22:28 AM
  Signed: 10/22/2022 10:22:28 AM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259345
rule_id: SV-259345r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The validity period for the Resource Record Signatures (RRSIGs) covering a zone's DNSKEY RRSet must be no less than two days and no more than one week.

description:
  <VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a zone signing key (ZSK) can use that key only during the key signing key's (KSK's) signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the Delegation Signer (DS) Resource Record (RR) in the delegating parent. These validity periods should be short, which will require frequent re-signing.

  To minimize the impact of a compromised ZSK, a zone administrator should set a signature validity period of one week for RRSIGs covering the DNSKEY RRSet in the zone (the RRSet that contains the ZSK and KSK for the zone). The DNSKEY RRSet can be re-signed without performing a ZSK rollover, but scheduled ZSK rollovers should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Right-click the zone and select DNSSEC >> Properties.

  Select the "KSK" tab. For the "DNSKEY RRSET signature validity period (hours):" setting, configure to a value between 48 and 168 hours. 

  Select the "ZSK" tab. For the "DNSKEY signature validity period (hours):" setting, configure to a value between 48 and 168 hours.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or Windows DNS Servers on a classified network.

  Log on to the DNS server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Right-click the zone and select DNSSEC >> Properties.

  Select the "KSK" tab.

  Verify the "DNSKEY signature validity period (hours):" is set to at least 48 hours and no more than 168 hours. 

  Select the "ZSK" tab. 

  Verify the "DNSKEY signature validity period (hours):" is set to at least 48 hours and no more than 168 hours.

  If either the "KSK" or "ZSK" tab "DNSKEY signature validity period (hours):" values are set to less than 48 hours or more than 168 hours, this is a finding.


vuln_id: V-259346
rule_id: SV-259346r961863_rule
severity: CAT II
title: NSEC3 must be used for all internal DNS zones.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. This information reveals that the resource record type for the name queried, or the resource record name requested, does not exist. 

  NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented at the expense of some CPU cycles on the authoritative server and the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured. To use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.

  Once the Server Manager window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Right-click the zone and select DNSSEC >> Sign the Zone.

  Re-sign the zone using an NSEC3 algorithm (RSA/SHA-1 (NSEC3), RSA/SHA-256, RSA/SHA-512).

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account.

  Type the following command, where example.com is replaced with the zone hosted on the DNS Server: 

  PS C:\> Get-DnsServerResourceRecord -ZoneName example.com <enter>

  All of the zone's resource records will be returned. This should include the NSEC3 RRs, as depicted below.

  If NSEC3 RRs are not returned for the zone, this is a finding.

  2vf77rkf63hrgismnuvnb8... NSEC3      0                    01:00:00        [RsaSha1][False][50][F2738D980008F73C]
  7ceje475rse25gppr3vphs... NSEC3      0                    01:00:00        [RsaSha1][False][50][F2738D980008F73C]


vuln_id: V-259347
rule_id: SV-259347r961863_rule
severity: CAT I
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server's zone files must have NS records that point to active name servers authoritative for the domain specified in that record.

description:
  <VulnDiscussion>Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. 

  The list of secondary servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of secondaries. If a secondary server has been retired or is not operational but remains on the list, an adversary might have a greater opportunity to impersonate that secondary without detection, rather than if the secondary was online. For example, the adversary may be able to spoof the retired secondary's IP address without an IP address conflict, which would not be likely to occur if the true secondary were active.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  If DNS servers are Active Directory (AD) integrated, troubleshoot and remedy the replication problem where the nonresponsive name server is not being updated.

  If DNS servers are not AD integrated, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone. 

  Review the NS records for the zone.

  Select the NS record for the nonresponsive name server and remove the record.

check_text:
  Note: This check is not applicable if Windows DNS Server is only serving as a caching server and does not host any zones authoritatively.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Review the NS records for the zone.

  Verify each of the name servers, represented by the NS records, is active.

  At a command prompt on any system, type:

  nslookup <enter>;

  At the nslookup prompt, type: 

  server ###.###.###.### <enter>;
  (where the ###.###.###.### is replaced by the IP of each NS record) 

  Enter a FQDN for a known host record in the zone.

  If the NS server does not respond at all or responds with a nonauthoritative answer, this is a finding.


vuln_id: V-259348
rule_id: SV-259348r961863_rule
severity: CAT II
title: All authoritative name servers for a zone must be located on different network segments.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment.

  A network administrator may choose to use a "hidden" primary authoritative server and have only secondary servers visible on the network. A hidden primary authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the primary authoritative name server is hidden, a secondary authoritative name server may reside on the same network as the hidden primary.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers on separate network segments from the primary authoritative server.

check_text:
  Windows DNS Servers that are Active Directory (AD) integrated must be located where required to meet the Active Directory services.

  If all of the Windows DNS Servers are AD integrated, this check is not applicable.

  If any or all the Windows DNS Servers are standalone and non-AD integrated, verify their geographic location with the system administrator.

  If all of the authoritative name servers are located on the same network segment and the primary authoritative name server is not "hidden", this is a finding.


vuln_id: V-259349
rule_id: SV-259349r961863_rule
severity: CAT II
title: All authoritative name servers for a zone must have the same version of zone information.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The only protection approach for content control of a DNS zone file is the use of a zone file integrity checker. The effectiveness of integrity checking using a zone file integrity checker depends on the database of constraints built into the checker. The deployment process consists of developing these constraints with the right logic, and the only determinant of the truth value of these logical predicates is the parameter values for certain key fields in the format of various RRTypes.

  The serial number in the SOA RDATA is used to indicate to secondary name servers that a change to the zone has occurred and a zone transfer should be performed. It should always be increased whenever a change is made to the zone data. DNS NOTIFY must be enabled on the primary authoritative name server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  If all DNS servers are AD integrated, determine why the replication is not taking place to the out-of-sync secondary name servers and mitigate the issue.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Initiate a zone transfer to all secondary name servers for the zone.

check_text:
  Note: Due to the manner in which Active Directory replication increments SOA records for zones when transferring zone information via Active Directory (AD) replication, this check is not applicable for AD-integrated zones.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Review the SOA information for the zone and obtain the Serial Number.

  Access each secondary name server for the same zone and review the SOA information.

  Verify the Serial Number is the same on all authoritative name servers.

  If the Serial Number is not the same on one or more authoritative name servers, this is a finding.


vuln_id: V-259350
rule_id: SV-259350r961863_rule
severity: CAT I
title: The Windows DNS Server must be configured to enable DNSSEC Resource Records (RRs).
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The specification for a digital signature mechanism in the context of the DNS infrastructure is in the Internet Engineering Task Force's (IETF's) DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve and verify signature.

  Before a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone", using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select each zone.
   
  Review the RRs for each zone and verify all of the DNSSEC record types are included for the zone. 

  Note: The DS (Delegation Signer) record should also exist but the requirement for it is validated under WDNS-22-000054.

  RRSIG (Resource Read Signature)
  DNSKEY (Public Key)
  NSEC3 (Next Secure 3)

  If the zone does not show all the DNSSEC record types, this is a finding.


vuln_id: V-259351
rule_id: SV-259351r961863_rule
severity: CAT II
title: The digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) (FIPS186) provides three algorithm choices:
  - Digital Signature Algorithm (DSA).
  - RSA.
  - Elliptic Curve DSA (ECDSA).

  Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. Both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. 

  RSA is the recommended algorithm for this guideline. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e., RSA/SHA-256, ECDSA) are also specified. It can be expected that name servers and clients will be able to use the RSA algorithm at a minimum. It is suggested that at least one zone signing key (ZSK) for a zone use the RSA algorithm.

  NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS (FIPS186). It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before 30 September 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone. 

  Review the zone's RRs in the right windowpane.

  Review the DNSKEY encryption in the Data column. Example: [DNSKEY][RsaSha1][31021]

  Confirm the encryption algorithm specified in the DNSKEY's data is at RsaSha1, at a minimum.

  If the specified encryption algorithm is not RsaSha1 or stronger, this is a finding.


vuln_id: V-259352
rule_id: SV-259352r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  For zones split between the external and internal sides of a network, the resource records (RRs) for the external hosts must be separate from the RRs for the internal hosts.

description:
  <VulnDiscussion>Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. 

  External clients need to receive RRs that pertain only to public services (public web server, mail server, etc.). 

  Internal clients need to receive RRs pertaining to public services as well as internal hosts. 

  The zone information that serves the RRs on both the inside and the outside of a firewall should be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Remove any RRs from the internal zones for which the resolution is for an external IP address.

  Remove any RRs from the external zones for which the resolution is for an internal IP address.

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  For each zone, review the records.

  If any RRs on an internal DNS server resolve to IP addresses located outside the internal DNS server's network, this is a finding.

  If any RRs on an external DNS server resolve to IP addresses located inside the network, this is a finding.


vuln_id: V-259353
rule_id: SV-259353r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  In a split DNS configuration between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.

description:
  <VulnDiscussion>Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. 

  One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve resource records (RRs) pertaining to hosts with public services (web servers that serve external web pages or provide business-to-consumer services, mail servers, etc.).

  The other set, called internal name servers, is to be located within the firewall and should be configured so the servers are not reachable from outside and hence provide naming services exclusively to internal clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the external DNS server's firewall policy, or the network firewall, to block queries from internal hosts.

check_text:
  Consult with the system administrator to review the external Windows DNS Server's DOD approved firewall policy.

  The inbound TCP and UDP ports 53 rule should be configured to only restrict IP addresses from the internal network.

  If the DOD-approved firewall policy is not configured with the restriction, consult with the network firewall administrator to confirm the restriction on the network firewall.

  If neither the DNS server's DOD approved firewall policy nor the network firewall is configured to block internal hosts from querying the external DNS server, this is a finding.


vuln_id: V-259354
rule_id: SV-259354r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers.

description:
  <VulnDiscussion>Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control substatement designating the list of hosts from which zone transfer requests can be accepted. These restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources. 

  Based on the need to know, the only name servers that need to refresh their zone files periodically are the secondary name servers. Zone transfer from primary name servers should be restricted to secondary name servers. The zone transfer should be completely disabled in the secondary name servers. The address match list argument for the allow-transfer substatement should consist of IP addresses of secondary name servers and stealth secondary name servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Right-click the zone and select "Properties".

  Select the "Zone Transfers" tab.

  Select the "Only to servers listed on the Name Server tab" or "Only to the following servers" check box or deselect the "Allow zone transfers" check box.

  Click "OK".

check_text:
  Determine if the authoritative primary name server is Active Directory (AD) integrated.

  Determine if all secondary name servers for every zone for which the primary name server is authoritative are AD-integrated in the same Active Directory.

  If the authoritative primary name server is AD integrated and all secondary name servers are part of the same AD, this check is not a finding because AD handles the replication of DNS data.

  If one or more of the secondary name servers are non-AD integrated, verify the primary name server is configured to only send zone transfers to a specific list of secondary name servers.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Right-click the zone and select "Properties".

  Select the "Zone Transfers" tab.

  If the "Allow zone transfers:" check box is not selected, this is not a finding.

  If the "Allow zone transfers:" check box is selected, verify either "Only to servers listed on the Name Server tab" or "Only to the following servers" is selected.

  If the "To any server" option is selected, this is a finding.


vuln_id: V-259355
rule_id: SV-259355r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Servers zone database files must not be accessible for edit/write by users and/or processes other than the Windows DNS Server service account and/or the DNS database administrator.

description:
  <VulnDiscussion>Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.

  The primary objective of DNS authentication and access control is the integrity of DNS records; only authorized personnel must be able to create and modify resource records, and name servers should only accept updates from authoritative primary servers for the relevant zones. Integrity is best ensured through authentication and access control features within the name server software and the file system the name server resides on. To protect the zone files and configuration data, which should only be accessed by the name service or an administrator, access controls must be implemented on files, and rights should not be easily propagated to other users. Lack of a stringent access control policy places the DNS infrastructure at risk to malicious persons and attackers and creates the potential for a denial of service to network resources.

  DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to objects.

  When applications provide a DAC mechanism, the DNS implementation must be able to limit the propagation of those access rights.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  For a file-back Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select each zone.

  Right-click each zone and select "Properties".

  Select the "Security" tab.

  Downgrade to READ privileges any group or user that has greater than READ privileges other than the DNS administrators and the system service account under which the DNS Server Service is running.

check_text:
  For an Active Directory (AD)-integrated DNS implementation, this is not applicable by virtue of being compliant with the Windows 2022 AD STIG because DNS data within an AD-integrated zone is kept within the Active Directory.

  For a file-based Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select each zone.

  Right-click each zone and select "Properties".

  Select the "Security" tab.

  Review the permissions applied to the zone. No group or user should have greater than READ privileges other than the DNS administrators and the system service account under which the DNS Server Service is running.

  If any other account/group has greater than READ privileges, this is a finding.


vuln_id: V-259356
rule_id: SV-259356r961863_rule
severity: CAT II
title: The Windows DNS Server must implement internal/external role separation.
fix_text: Configure separate DNS servers for each of the external and internal networks.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the internet). 

  The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. To protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. Separating internal and external roles in DNS prevents address space that is private (e.g., 10.0.0.0/24) or otherwise concealed by some form of Network Address Translation from leaking into the public DNS system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, review each zone.

  Consult with the DNS Admin to determine if any of the zones also have hostnames that need to be resolved from the external network.

  If the zone is split between internal and external networks, verify separate DNS servers have been implemented for each network.

  If internal and external DNS servers have not been implemented for zones that require resolution from both the internal and external networks, this is a finding.


vuln_id: V-259357
rule_id: SV-259357r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server authoritative for local zones must only point root hints to the DNS servers that host the internal root domain.

description:
  <VulnDiscussion>All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. 

  The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a noncaching server (as recommended), they can be configured to either return a referral to the root servers or refuse to answer the query. 

  The recommendation is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server and allows it to spend more of its resources fulfilling its intended purpose of answering authoritatively for its zone.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the authoritative DNS server using the Domain Admin or Enterprise Admin account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  Right-click the DNS server and select "Properties".

  Select the "Root Hints" tab.

  Remove the root hints from the DNS Manager, the CACHE.DNS file, and from Active Directory for name servers outside the internal network. 

  Replace the existing root hints with new root hints of internal servers. 

  If the DNS server is forwarding, click to select the "Do not use recursion for this domain"" check box on the "Forwarders" tab in DNS Manager to ensure the root hints will not be used.

check_text:
  Note: If the Windows DNS Server is in the classified network, this check is not applicable.

  Log on to the authoritative DNS server using the Domain Admin or Enterprise Admin account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  Right-click the DNS server and select "Properties".

  Select the "Root Hints" tab.

  Verify "Root Hints" is empty or only has entries for internal zones under "Name servers:". All internet root server entries must be removed.

  If "Root Hints" is not empty or entries on the "Root Hints" tab under "Name servers:" are external to the local network, this is a finding.


vuln_id: V-259358
rule_id: SV-259358r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Servers zone files must not include resource records that resolve to a fully qualified domain name residing in another zone.

description:
  <VulnDiscussion>If a name server could claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. The best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone.

  The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party content delivery networks (CDNs) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Remove any resource records in a zone file if the resource record resolves to a fully qualified domain name residing in another zone.

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.
   
  Confirm with the DNS administrator that the hosts defined in the zone files do not resolve to hosts in another zone with its fully qualified domain name.

  The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party CDNs or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. Additional exceptions are CNAME records in a multidomain Active Directory environment pointing to hosts in other internal domains in the same multidomain environment.

  If resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party CDNs or cloud computing platforms with a documented and approved mission need, this is a finding.


vuln_id: V-259359
rule_id: SV-259359r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server's zone files must not include CNAME records pointing to a zone with lesser security for more than six months.

description:
  <VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning (pointing to zones with lesser security) aliases should be temporary (e.g., to facilitate a migration) and not be in place for more than six months. 

  When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. In the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers, which compounds the vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Remove any zone-spanning CNAME records that have been active for more than six months, which are not supporting zone delegations, CNAME records supporting a system migration, or CNAME records pointing to third-party CDNs or cloud computing platforms.

  In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement).

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Review the resource records to confirm there are no CNAME records older than six months.

  The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDNs) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. (Authorizing Official approval of use of a commercial cloud offering would satisfy this requirement.) Additional exceptions are CNAME records in a multidomain Active Directory environment pointing to hosts in other internal domains in the same multidomain environment.

  If there are zone-spanning (i.e., zones of lesser security) CNAME records older than six months and the CNAME records resolve to anything other than fully qualified domain names for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party CDNs or cloud computing platforms with an AO-approved and documented mission need, this is a finding.


vuln_id: V-259360
rule_id: SV-259360r961863_rule
severity: CAT II
title: Nonroutable IPv6 link-local scope addresses must not be configured in any zone.
fix_text: Remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>IPv6 link-local scope addresses are not globally routable and must not be configured in any DNS zone. Like RFC1918 addresses, if a link-local scope address is inserted into a zone provided to clients, most routers will not forward this traffic beyond the local subnet.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Expand the "Forward Lookup Zones" folder.

  Expand each zone folder and examine the host record entries. The third column titled "Data" will display the IP.

  Verify this column does not contain any IP addresses that begin with the prefixes "FE8", "FE9", "FEA", or "FEB".

  If any nonroutable IPv6 link-local scope addresses are in any zone, this is a finding.


vuln_id: V-259361
rule_id: SV-259361r1018796_rule
severity: CAT II
title: AAAA addresses must not be configured in a zone for hosts that are not dual stack.
fix_text: Remove any IPv6 records for hosts that are not in a dual stack configuration.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>DNS is only responsible for resolving a domain name to an IP address. Applications and operating systems are responsible for processing the IPv6 or IPv4 record that may be returned. 

  A denial of service could easily be implemented for an application that is not IPv6 if the user is not running dual stack or any other systems utilizing IPv6. When the application receives an IP address in hexadecimal, it is up to the application/operating system to decide how to handle the response. Combining both IPv6 and IPv4 in a dual stack records into the same domain can lead to application problems that are beyond the scope of the DNS administrator.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, select each zone and examine the host record entries. The third column titled "Data" will display the IP.

  Determine if any contain both IPv4 and IPv6 addresses.

  If any hostnames contain both IPv4 and IPv6 addresses, confirm with the system administrator that the actual hosts are in a dual stack.

  If any zones contain hosts with both IPv4 and IPv6 addresses but are determined to be not in a dual stack, this is a finding.


vuln_id: V-259363
rule_id: SV-259363r960999_rule
severity: CAT II
cci: CCI-000778
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must uniquely identify the other DNS server before responding to a server-to-server transaction.

description:
  <VulnDiscussion>Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair, TSIG, or using PKI-based authentication, SIG(0), thus uniquely identifying the other server.

  TSIG and SIG(0) are not configurable in Windows DNS Server.

  To meet the requirement for authentication between Windows DNS Servers, IPsec will be implemented between the Windows DNS Servers that host any non-Active Directory (AD)-integrated zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Complete the following procedures twice for each pair of name servers.

  Create a rule for TCP connections.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "gpme.msc" to open the Group Policy Management feature.

  In the "Browse for Group Policy Object" dialog box, double-click "Domain Controllers.domain.com".

  Click "Default Domain Controllers Policy" and click "OK".

  In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP.

  Right-click "Connection Security Rules" and select "New".

  For "Rule Type", select the "Server-to-server" radio button and click "Next".

  For Endpoint 1 and Endpoint 2, select "These IP addresses:" and add the IP addresses of all DNS servers. Click "Next".

  For "Requirements", select "Request authentication for inbound and outbound connections" and click "Next".

  For "Authentication Method", select Computer certificate and from the "Signing Algorithm:" drop-down, select "RSA (default)".

  From the "Certificate store type:" drop-down, select "Root CA (default)".

  From the "CA name:", click "Browse", select the certificate for the CA, and click "Next".

  On "Profile", accept default selections and click "Next".

  On "Name", enter a name applicable to the rule's function.

  Click "Finish".

check_text:
  Note: This requirement applies to any Windows DNS Server that hosts non-AD-integrated zones, even if the DNS servers host AD-integrated zones, too.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "gpme.msc" to open the Group Policy Management feature.

  In the "Browse for Group Policy Object" dialog box, double-click "Domain Controllers.domain.com".

  Click "Default Domain Controllers Policy" and click "OK".

  In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP.

  Click "Connection Security Rules".

  Confirm at least one rule is configured for TCP 53.

  Double-click on each rule to verify the following: 

  On the "Authentication" tab, "Authentication mode:" is set to "Request authentication for inbound and outbound connections".

  The "Signing Algorithm" is set to "RSA (default)".

  On the "Remote Computers" tab, "Endpoint1" and "Endpoint2" are configured with the IP addresses of all DNS servers.

  On the "Protocols and Ports" tab, "Protocol type:" is set to either TCP (depending on which rule is being reviewed) and the "Endpoint 1 port:" is set to "Specific ports" and "53".

  If no rules are configured with the specified requirements, this is a finding.


vuln_id: V-259364
rule_id: SV-259364r961503_rule
severity: CAT II
cci: CCI-001958
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The secondary Windows DNS name servers must cryptographically authenticate zone transfers from primary name servers.

description:
  <VulnDiscussion>Authenticity of zone transfers within Windows Active Directory (AD)-integrated zones is accomplished by AD replication. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific preauthorized devices can access the system.

  This requirement applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair, TSIG, or using PKI-based authentication, SIG(0).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the account designated as Administrator or DNS Administrator.

  If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.

  Once the Server Manager window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  In the DNS Manager console tree on the DNS server being validated, navigate to "Forward Lookup Zones".

  Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  For zones that are completely AD-integrated, this check is not a finding.

  For authenticity of zone transfers between non-AD-integrated zones, DNSSEC must be implemented.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 12/21/2022 10:215:28 AM
  Signed: 11/22/2022 10:15:28 AM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, indicating the zone has been signed with DNSSEC, this is a finding.


vuln_id: V-259365
rule_id: SV-259365r960735_rule
severity: CAT II
cci: CCI-000054
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS primary server must only send zone transfers to a specific list of secondary name servers.

description:
  <VulnDiscussion>Primary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to be made only to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in a denial of service to legitimate users.

  Active Directory (AD)-integrated DNS servers replicate zone information via AD replication. Non-AD-integrated DNS servers replicate zone information via zone transfers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  From the displayed context menu, click the "Properties" option.

  On the opened zone's properties box, go to the "Zone Transfers" tab.

  On the displayed interface, select the "Allow zone transfers" check box.

  Select the "Only to servers listed on the Name Servers tab" radio button OR select the "Only to the following servers" radio button.

  Click "Apply".

  Click "OK".

check_text:
  If the DNS server hosts only AD-integrated zones and there are no non-AD-integrated DNS servers acting as secondary DNS servers for the zones, this check is not applicable.

  For a non-AD-integrated DNS server:

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand "Forward Lookup Zones".

  From the expanded list, click to select and then right-click the zone name.

  From the displayed context menu, click the "Properties" option.

  On the opened zone's properties box, go to the "Zone Transfers" tab.

  On the displayed interface, determine if the "Allow zone transfers" check box is selected.

  If the "Allow zone transfers" check box is not selected, this is not a finding.

  If the "Allow zone transfers" check box is selected, determine if either the "Only to servers listed on the Name Servers tab" radio button is selected or the "Only to the following servers" radio button is selected.

  If the "To any server" radio button is selected, this is a finding.


vuln_id: V-259366
rule_id: SV-259366r987676_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must provide its identity with returned DNS information by enabling DNSSEC and TSIG/SIG(0).

description:
  <VulnDiscussion>Weakly bound credentials can be modified without invalidating the credential; therefore, nonrepudiation can be violated.

  This requirement supports audit requirements that provide organizational personnel with the means to identify who produced specific information in the event of an information transfer. Organizations and/or data owners determine and approve the strength of the binding between the information producer and the information based on the security category of the information and relevant risk factors.

  DNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of pieces of information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the account designated as Administrator or DNS Administrator.

  In the DNS Manager console tree on the DNS server being validated, navigate to "Forward Lookup Zones".

  Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either saved parameters or custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259367
rule_id: SV-259367r1081079_rule
severity: CAT II
cci: CCI-000186
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must be configured to enforce authorized access to the corresponding private key.

description:
  <VulnDiscussion>The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and nonrepudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.

  SIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. In cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Access Windows Explorer.

  Navigate to the following location:

  %ALLUSERSPROFILE%\Microsoft\Crypto

  Modify permissions on the keys folder, subfolders, and files to be limited to SYSTEM and Administrators FULL CONTROL to limit all other users/groups to READ. If additional permissions are needed it must be documented and approved by the ISSO or ISSM.

check_text:
  Access Windows Explorer.

  Navigate to the following location:

  %ALLUSERSPROFILE%\Microsoft\Crypto

  Note: If the folder above does not exist, this check is not applicable.

  Verify the permissions on the keys folder, subfolders, and files are limited to SYSTEM and Administrators FULL CONTROL.

  If any other user or group has greater than READ privileges to the %ALLUSERSPROFILE%\Microsoft\Crypto folder, subfolders and files, this is a finding.


vuln_id: V-259368
rule_id: SV-259368r961041_rule
severity: CAT II
cci: CCI-000186
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server key file must be owned by the account under which the Windows DNS Server service is run.

description:
  <VulnDiscussion>To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key can also be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. Transaction Signature (TSIG) is a string used to generate the message authentication hash stored in a TSIG Resource Record (RR) and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Access Windows Explorer.

  Navigate to the following location:

  %ALLUSERSPROFILE%\Microsoft\Crypto

  Right-click on each subfolder, choose "Properties", click the "Security" tab, and click the "Advanced" button.

  Click "Change" next to the listed Owner and change to be the account under which the DNS Server Service is running.

check_text:
  Access Services on the Windows DNS Server and locate the DNS Server Service.

  Determine the account under which the DNS Server Service is running. 

  Access Windows Explorer.

  Navigate to the following location:

  %ALLUSERSPROFILE%\Microsoft\Crypto

  Note: If the folder above does not exist, this check is not applicable.

  Right-click on each subfolder, choose "Properties", click the "Security" tab, and click the "Advanced" button.

  Verify the Owner on the folder, subfolders, and files is the account under which the DNS Server Service is running.

  If any other user or group is listed as OWNER of the %ALLUSERSPROFILE%\Microsoft\Crypto folder, subfolders, and files, this is a finding.


vuln_id: V-259369
rule_id: SV-259369r1081081_rule
severity: CAT II
cci: CCI-000186
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server permissions must be set so the key file can only be read or modified by the account that runs the name server software.

description:
  <VulnDiscussion>To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key can also be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. Transaction Signature (TSIG) is a string used to generate the message authentication hash stored in a TSIG Resource Record (RR) and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Access Windows Explorer.

  Navigate to the following location:
  %ALLUSERSPROFILE%\Microsoft\Crypto

  Modify permissions on the folder, subfolders, and files to "FULL CONTROL" for "SYSTEM" and Administrators and to "READ" for all other users/groups. If additional permissions are needed, it must be documented and approved by the ISSO or ISSM.

check_text:
  Access Windows Explorer.

  Navigate to the following location:
  %ALLUSERSPROFILE%\Microsoft\Crypto

  Note: If the folder above does not exist, this check is not applicable.

  Verify the permissions on the folder, subfolders, and files are limited to "SYSTEM" and Administrators for "FULL CONTROL".

  If any other user or group has greater than READ permissions to the %ALLUSERSPROFILE%\Microsoft\Crypto folder, subfolders, and files, this is a finding.


vuln_id: V-259370
rule_id: SV-259370r961041_rule
severity: CAT II
cci: CCI-000186
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The private key corresponding to the zone signing key (ZSK) must only be stored on the name server that does support dynamic updates.

description:
  <VulnDiscussion>The private keys in the key signing key (KSK) and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file primary copy.

  This strategy is not feasible in situations in which the DNSSEC-aware name server must support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) must have both the zone file master copy and the private key corresponding to the zone signing key (ZSK-private) online to immediately update the signatures for the updated resource record (RR) sets. The private key corresponding to the key signing key (KSK-private) can still be kept offline.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Ensure the private key corresponding to the ZSK is only stored on the name server accepting dynamic updates.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory (AD)-integrated zones or for Windows DNS Servers on a classified network.

  Note: This requirement is not applicable to servers with only a caching role.

  For AD-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through AD replication. Each authoritative server signs its own copy of the zone when it receives the key. For optimal performance, and to prevent increasing the size of the AD database file, the signed copy of the zone remains in memory for AD-integrated zones. A DNSSEC-signed zone is only committed to disk for file-backed zones. Secondary DNS servers pull a full copy of the zone, including signatures, from the primary DNS server.

  If all DNS servers are AD integrated, this check is not applicable.

  If a DNS server is not AD integrated and has file-backed zones, does not accept dynamic updates, and has a copy of the private key corresponding to the ZSK, this is a finding.


vuln_id: V-259371
rule_id: SV-259371r1015766_rule
severity: CAT II
title: The Windows DNS Server must implement a local cache of revocation data for PKI authentication.
cci: CCI-004068
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Not configuring a local cache of revocation data could allow access to users who are no longer authorized (users with revoked certificates).

  SIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. In cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure local revocation data to be used in the event access to Certificate Authorities is hindered.

check_text:
  Consult with the system administrator to determine if a third-party CRL server is being used for certificate revocation lookup.

  If there is, determine if a documented procedure is in place to store a copy of the CRL locally (local to the site, as an alternative to querying the actual Certificate Authorities). An example would be an OCSP responder installed at the local site.

  If there is no local cache of revocation data, this is a finding.


vuln_id: V-259372
rule_id: SV-259372r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The salt value for zones signed using NSEC3 resource records (RRs) must be changed every time the zone is completely re-signed.

description:
  <VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist.

  NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles on the authoritative server and the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured. To use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

  Revalidate the NSEC3PARAM Inception date and time against the DNSKEY date and time.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  In Windows, the NSEC3 salt values are automatically changed when the zone is re-signed.

  To validate:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS Server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone. 

  Review the zone's RRs in the right windowpane.

  Determine the RRSIG NSEC3PARAM's Inception (in the Data column). Compare the Inception to the RRSIG DNSKEY Inception. The date and time should be the same.

  If the NSEC3PARAM's Inception date and time is different than the DNSKEY Inception date and time, this is a finding.


vuln_id: V-259373
rule_id: SV-259373r961101_rule
severity: CAT II
cci: CCI-001178
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must include data origin with authoritative data the system returns in response to external name/address resolution queries.

description:
  <VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. The security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure valid data has originated from the right source. Establishing trust in the source is called data origin authentication.

  The security objectives, and consequently the security services, that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification.

  The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the account designated as Administrator or DNS Administrator.

  If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.

  Once the Server Manager window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  In the DNS Manager console tree on the DNS server being validated, navigate to "Forward Lookup Zones".

  Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Authenticity of query responses is provided with DNSSEC signing of zones.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by Windows DNS Server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259374
rule_id: SV-259374r1081084_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server's IP address must be statically defined and configured locally on the server.

description:
  <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated. 

  Ensuring all name servers have static IP addresses makes it possible to configure restricted DNS communication, such as with DNSSEC, between the name servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. 

  Use "ipconfig /all" to identify all network adapters. 
  or
  Locate the "Network Internet Access" icon, right-click on it, and select "Open Network & Sharing Center".

  Click "Change adapter settings".

  Right-click on the Ethernet and click "Properties".

  Select "Internet Protocol Version 4 (TCP/IPv4)" and click "Properties".

  Select "Use the following IP address" and populate with an IP address, subnet mask, and default gateway.

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Use "ipconfig /all" to identify all network adapters. 
  or
  Locate the "Network Internet Access" icon, right-click on it, and select "Open Network & Sharing Center".

  Click "Change adapter settings".

  Right-click on the Ethernet and click "Properties".

  Select "Internet Protocol Version 4 (TCP/IPv4)" and click "Properties".

  Verify the "Use the following IP address" is selected, with an IP address, subnet mask, and default gateway assigned.

  If the "Use the following IP address" is not selected with a configured IP address, subnet mask, and default gateway, this is a finding.


vuln_id: V-259375
rule_id: SV-259375r987695_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must return data information in response to internal name/address resolution queries.

description:
  <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  By default, when DNS servers are configured with DNSSEC signed zones, they will automatically respond to query requests, providing validating data in the response, whenever the query requests that validation. Because this takes place inherently when the zone is signed with DNSSEC, the requirement is satisfied by ensuring zones are signed.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259376
rule_id: SV-259376r987696_rule
severity: CAT II
title: The Windows DNS Server must use DNSSEC data within queries to confirm data origin to DNS resolvers.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated.

  A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to ensure the authenticity and integrity of response data.

  In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259377
rule_id: SV-259377r961581_rule
severity: CAT II
title: WINS lookups must be disabled on the Windows DNS Server.
cci: CCI-002462
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated.

  A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. 

  In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.

  If/when WINS lookups are enabled, the validity of the data becomes questionable because the WINS data is provided to the requestor unsigned and invalidated. To ensure only the DNSSEC-signed data is being returned, WINS lookups must be disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click each zone and then click "Properties".

  In the "Properties" dialog box for the zone, click the "WINS" tab.

  Uncheck the "Use WINS forward" lookup check box.

  Click "OK".

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click each zone and then click "Properties".

  In the "Properties" dialog box for the zone, click the "WINS" tab.

  Verify the "Use WINS forward lookup" check box is not selected.

  If the "Use WINS forward lookup" check box is selected, this is a finding.


vuln_id: V-259378
rule_id: SV-259378r961581_rule
severity: CAT II
cci: CCI-002462
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must use DNSSEC data within queries to confirm data integrity to DNS resolvers.

description:
  <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated.

  A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. 

  In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259379
rule_id: SV-259379r961104_rule
severity: CAT II
cci: CCI-001179
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must be configured with the Delegation Signer (DS) Resource Records (RR) carrying the signature for the RR that contains the public key of the child zone.

description:
  <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of DS records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain from the top of the DNS hierarchy down.

  A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to ensure the authenticity and integrity of response data. 

  In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent.

  A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.

  When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through several intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor).

  One way to indicate the security status of child subspaces is through the use of DS RRs in the DNS.

  Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
[cell repeats an earlier one in this file: 567 characters]

check_text:
[cell repeats an earlier one in this file: 1464 characters]


vuln_id: V-259380
rule_id: SV-259380r961107_rule
severity: CAT II
cci: CCI-001663
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must enforce approved authorizations between DNS servers using digital signatures in the Resource Record Set (RRSet).

description:
  <VulnDiscussion>A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data.

  Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics).

  Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.

  Within the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.
   
  Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone. 

  Review the records for the zone and ensure the complete RRSet of records is present: RRSIG, NSEC3, DNSKEY, indicating DNSSEC compliance.

  If the RRSet of records is not in the zone, this is a finding.


vuln_id: V-259381
rule_id: SV-259381r961107_rule
severity: CAT II
cci: CCI-001663
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Name Resolution Policy Table (NRPT) must be configured in Group Policy to enforce clients to request DNSSEC validation for a domain.

description:
  <VulnDiscussion>The NRPT is used to require DNSSEC validation. The NRPT can be configured in local Group Policy for a single computer or domain Group Policy for some or all computers in the domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Implement this fix for configuring name resolvers, including DNS servers configured for the caching role only.

  On Domain Controller, on the Server Manager menu bar, click "Tools" and then click "Group Policy Management".

  In the Group Policy Management console tree, under Domains >> domainname >> Group Policy Objects, right-click "Default Domain Policy" and then click "Edit".

  In the Group Policy Management Editor console tree, navigate to Computer Configuration >> Policies >> Windows Settings >> Name Resolution Policy.

  In the details pane, under "Create Rules" and "to which part of the namespace does this rule apply", choose "Suffix" from the drop-down list and type "domain.mil" next to "Suffix".
   
  On the "DNSSEC" tab, select "Enable DNSSEC" in this rule check box and then under "Validation", select the check box for "Require DNS clients to check that name and address data has been validated by the DNS server".

  In the bottom right corner, click "Create" and then verify that a rule for domain.mil was added under the NRPT.

  Click "Apply" and then close the Group Policy Management Editor.

  Open a Windows PowerShell prompt and enter the following commands:
  gpupdate /force <enter>
  get-dnsclientnrptpolicy <enter>

  In the results, select "True" for the "DnsSecValidationRequired" setting for the domain.mil namespace.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  The NRPT is configured in, and deployed to clients from, Group Policy and will be pushed to all clients in the domain. The Active Directory zones will be signed and the clients, with NRPT, will require a validation of signed data when querying.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  At the Windows PowerShell prompt, type the following command:

  get-dnsclientnrptpolicy <enter>

  In the results, verify the "DnsSecValidationRequired" is "True".

  If there are no results to the "get-dnsclientnrptpolicy" cmdlet or the "DnsSecValidationRequired" is not "True", this is a finding.


vuln_id: V-259382
rule_id: SV-259382r961107_rule
severity: CAT II
cci: CCI-001663
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must be configured to validate an authentication chain of parent and child domains via response data.

description:
  <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down. 

  Like the DNSKEY resource record, the DS Resource Record (RR) can be used to create a trust anchor for a signed zone. The DS record is smaller in size than a DNSKEY record because it contains only a hash of the public key.

  The DS record is not added to a zone during the signing process like some DNSSEC-related RRs, even if a delegation already exists in the zone. To add a DS record, it must be manually added or imported. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Primary when a zone is signed. The DSSET file can be used with the "Import-DnsServerResourceRecordDS" cmdlet to import DS records to the parent zone.

  A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to ensure the authenticity and integrity of response data.

  DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the DS RRs in the DNS, the security status of a child domain can be validated. The DS RR is used to identify the DNSSEC signing key of a delegated zone.

  Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. 

  After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of an RRSet. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus.

  This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be ensured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  A DS record must be added manually or imported.

  The DSSET is automatically added as a file to the Key primary when a zone is signed. 

  This file can be used with the "Import-DnsServerResourceRecordDS" cmdlet to import DS records to the parent zone.

  Example:
  PS C:\> Import-DnsServerResourceRecordDS -ZoneName adatum.com -DSSetFile "c:\windows\system32\dns\dsset-corp.adatum.com"

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:

  PS C:\> Get-DnsServerResourceRecord -ZoneName adatum.com -RRType DS

  Replace "adatum.com" with the parent zone on the DNS server being evaluated.

  HostName RecordType Timestamp TimeToLive RecordData
  -------- ---------- --------- ---------- ----------
  corp DS 0 01:00:00 [58555][Sha1][RsaSha1NSec3]
  corp DS 0 01:00:00 [58555][Sha256][RsaSha1NSec3]
  corp DS 0 01:00:00 [63513][Sha1][RsaSha1NSec3]
  corp DS 0 01:00:00 [63513][Sha256][RsaSha1NSec3]

  If the results do not show the DS records for the child domain(s), this is a finding.

  In the previous example, DS records for the child zone, corp.adatum.com, were imported into the parent zone, adatum.com, by using the DSSET file in the c:\windows\system32\dns directory. The DSSET file was located in this directory because the local DNS server is the Key primary for the child zone.

  If the Key Master DNS server for a child zone is not the same computer as the primary authoritative DNS server for the parent zone where the DS record is being added, the DSSET file must be obtained for the child zone and made available to the primary authoritative server for the parent zone. Alternatively, the DS records can be added manually.


vuln_id: V-259383
rule_id: SV-259383r961107_rule
severity: CAT II
cci: CCI-001663
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  Trust anchors must be exported from authoritative Windows DNS Servers and distributed to validating Windows DNS Servers.

description:
  <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down.

  A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data.

  DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the DS Resource Records (RRs) in the DNS, the security status of a child domain can be validated. The DS RR is used to identify the DNSSEC signing key of a delegated zone.

  Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. 

  After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of an RRSet. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus.

  This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured.

  A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named "TrustAnchors.dns". A DNS server running Windows Server also displays configured trust anchors in the DNS Manager console tree in the Trust Points container. Trust anchors can also be viewed by executing Windows PowerShell commands or "Dnscmd.exe" at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log onto the primary DNS server and click Windows Explorer on the taskbar.

  Navigate to C:\Windows\System32, right-click the DNS folder, point to "Share with", and then click "Advanced sharing".

  In the "DNS Properties" dialog box, click "Advanced Sharing", select the "Share this folder" check box, verify the Share name is "DNS", and then click "OK".

  Click "Close" and then close Windows Explorer.

  Log on to each of the validating Windows DNS Servers.

  In the DNS Manager console tree, navigate to the "Trust Points" folder.

  Right-click "Trust Points", point to "Import", and then click "DNSKEY".

  In the "Import DNSKEY" dialog box, type \\primaryhost\dns\keyset-domain.mil (where primaryhost represent the FQDN of the Primary DNS Server and domain.mil represents the zone or zones).

  Click "OK".

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log onto each of the validating Windows DNS Servers.

  In the DNS Manager console tree, navigate to each hosted zone under the "Trust Points" folder.

  Two DNSKEY trust points should be displayed, one for the active key and one for the standby key.

  If each validating Windows DNS Server does not reflect the DNSKEY trust points for each of the hosted zone(s), this is a finding.


vuln_id: V-259384
rule_id: SV-259384r961107_rule
severity: CAT II
title: Automatic Update of Trust Anchors must be enabled on key rollover.
cci: CCI-001663
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. 

  On standalone DNS servers, trust anchors are stored in a file named "TrustAnchors.dns". A DNS server running Windows Server also displays configured trust anchors in the DNS Manager console tree in the "Trust Points" container. Trust anchors can also be viewed by executing Windows PowerShell commands or "Dnscmd.exe" at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.

  Once the Server Manager window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select and then right-click the zone name.

  From the displayed context menu, click DNSSEC >> Properties.

  Click the "KSK" tab.

  For each KSK that is listed under key signing keys (KSKs), click the KSK, click "Edit", and in the "Key Rollover" section, select the "Enable automatic rollover" check box.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.

  Once the Server Manager window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select and then right-click the zone name.

  From the displayed context menu, click DNSSEC >> Properties.

  Click the "KSK" tab.

  For each KSK that is listed under Key signing keys (KSKs), click the KSK, click "Edit", and in the "Key Rollover" section, verify the "Enable automatic rollover" check box is selected.

  If the "Enable automatic rollover" check box is not selected for every KSK listed, this is a finding.


vuln_id: V-259385
rule_id: SV-259385r961584_rule
severity: CAT II
cci: CCI-002465
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS secondary servers must request data origin authentication verification from the primary server when requesting name/address resolution.

description:
  <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication must be performed to thwart these types of attacks.

  Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from either a Windows 8 client or a Windows 2008 or higher server, authenticated as a Domain Administrator or Local Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows 10 or higher client.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2022 10:22:28 PM
  Signed: 10/22/2022 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259386
rule_id: SV-259386r961587_rule
severity: CAT II
cci: CCI-002466
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS secondary server must request data integrity verification from the primary server when requesting name/address resolution.

description:
  <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks.

  Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
[cell repeats an earlier one in this file: 567 characters]

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2022 10:22:28 PM
  Signed: 10/22/2022 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259387
rule_id: SV-259387r961590_rule
severity: CAT II
cci: CCI-002467
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS secondary server must validate data integrity verification on the name/address resolution responses received from primary name servers.

description:
  <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks.

  Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
[cell repeats an earlier one in this file: 567 characters]

check_text:
[cell repeats an earlier one in this file: 1464 characters]


vuln_id: V-259388
rule_id: SV-259388r961593_rule
severity: CAT II
cci: CCI-002468
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS secondary server must validate data origin verification authentication on the name/address resolution responses received from primary name servers.

description:
  <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks.

  Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
[cell repeats an earlier one in this file: 567 characters]

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2022 10:22:28 PM
  Signed: 10/22/2022 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259389
rule_id: SV-259389r1043178_rule
severity: CAT II
title: The Windows DNS Server must protect the authenticity of zone transfers via transaction signing.
cci: CCI-001184
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair, TSIG, or using PKI-based authentication, SIG(0), thus uniquely identifying the other server.

  TSIG and SIG(0) are not configurable in Windows DNS Server.

  To meet the requirement for authentication between Windows DNS Servers, IPsec will be implemented between the Windows DNS Servers that hosts any non-Active Directory (AD)-integrated zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Complete the following procedures twice for each pair of name servers.
   
  Create a rule for UDP connections and then create a rule for TCP connections.
   
  Refer to the Microsoft Windows Server DNS Overview.pdf for Microsoft links for this procedure.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "gpme.msc" to open the Group Policy Management feature.

  In the "Browse for Group Policy Object" dialog box, double-click "Domain Controllers.domain.com".

  Click "Default Domain Controllers Policy" and click "OK".

  In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Defender Firewall with Advanced Security\Windows Defender Firewall with Advanced Security - Local Group Policy Object.

  Right-click "Connection Security Rules" and select "New".

  For "Rule Type", select the "Server-to-server" radio button and click "Next".

  For Endpoint 1 and Endpoint 2, select "These IP addresses:" and add the IP addresses of all DNS servers. Click "Next".

  For "Requirements", select "Request authentication for inbound and outbound connections" and click "Next".

  For "Authentication Method", select Computer certificate and from the "Signing Algorithm:" drop-down, select "RSA (default)".

  From the "Certificate store type:" drop-down, select "Root CA (default).

  From "CA name:", click "Browse" and select the certificate generated by the internally managed server performing the AD CS role. Click "Next".

  On "Profile", accept the default selections and click "Next".

  On "Name", enter a name applicable to the rule's function (i.e., DNSSEC UDP).

  Click "Finish".

check_text:
  Note: This requirement applies to any Windows DNS Servers that host non-AD-integrated zones (file based) even if the DNS servers host AD-integrated zones, too.

  If the Windows DNS Servers host only AD-integrated zones, this requirement is not applicable.

  To protect authenticity of zone transfers between Windows DNS Servers with file-based zones, IPsec must be configured on each pair of name servers in a zone transfer transaction for those zones.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "gpme.msc" to open the Group Policy Management feature.

  In the "Browse for Group Policy Object" dialog box, double-click "Domain Controllers.domain.com".

  Click "Default Domain Controllers Policy" and click "OK".

  In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Defender Firewall with Advanced Security\Windows Defender Firewall with Advanced Security - Local Group Policy Object.

  Click Connection Security Rules.

  Consult with the SA to determine which Rules meet the intent of the server-to-server authentication.

  If Rules exist, double-click on each Rule to verify the following:

  For the "Authentication:" tab, click on the "Customize..." button.

  On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections".

  Confirm the "Signing Algorithm" is set to "RSA (default)".

  Under "Method", ensure the "Advanced:" radio button is selected.

  Click the "Customize" button.

  For "First authentication methods:", double-click on the entry.

  Verify the "Select the credential to use for first authentication:" has "Computer certificate from this certification authority (CA):" radio button selected.

  Review the certificate specified and verify the certificate used was generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role.

  If rules do not exist for server-to-server authentication, this is a finding.

  If rules exist for this server to authenticate to other name servers hosting the same file based zones when transacting zone transfers, but the rules are not configured with the above settings, this is a finding.


vuln_id: V-259390
rule_id: SV-259390r1043178_rule
severity: CAT I
title: The Windows DNS Server must protect the authenticity of dynamic updates via transaction signing.
cci: CCI-001184
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed.

  The combination of signing DNS zones by DNSSEC and requiring clients to send their dynamic updates securely ensures the authenticity of those DNS records when providing query responses for them.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.

  Once the Server Manager window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  In the DNS Manager console tree on the DNS server being validated, navigate to "Forward Lookup Zones".

  Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Once resource records are received by a DNS server via a secure dynamic update, the resource records will automatically become signed by DNSSEC if the zone was originally signed by DNSSEC. Authenticity of query responses for resource records dynamically updated can be validated by querying for whether the zone/record is signed by DNSSEC.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace 131.77.60.235 with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an Expirations, date signed, signer, and signature, similar to the following:

  Name : www.zonename.mil
  QueryType : RRSIG
  TTL : 189
  Section : Answer
  TypeCovered : CNAME
  Algorithm : 8
  LabelCount : 3
  OriginalTtl : 300
  Expiration : 11/21/2014 10:22:28 PM
  Signed : 10/22/2014 10:22:28 PM
  Signer : zonename.mil
  Signature : {87, 232, 34, 134...}

  Name : origin-www.zonename.mil
  QueryType : A
  TTL : 201
  Section : Answer
  IP4Address : 156.112.108.76

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259391
rule_id: SV-259391r1043178_rule
severity: CAT II
title: The Windows DNS Server must protect the authenticity of query responses via DNSSEC.
cci: CCI-001184
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. An integral part of integrity verification is to ensure that valid data has originated from the right source. DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  In the DNS Manager console tree on the DNS server being validated, navigate to "Forward Lookup Zones".

  Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either saved parameters or custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Authenticity of query responses is provided with DNSSEC signing of zones.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259392
rule_id: SV-259392r961596_rule
severity: CAT II
title: The Windows DNS Server must use an approved DOD PKI certificate authority.
cci: CCI-002470
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Untrusted certificate authorities (CA) can issue certificates, but the certificates may be issued by organizations or individuals that seek to compromise DOD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DOD-approved CA, trust of this CA has not been established.

  The DOD will only accept PKI certificates obtained from a DOD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates.

  TSIG and SIG(0) are not configurable in Windows DNS Server. To meet the requirement for authentication between Windows DNS Servers, IPsec must be implemented between the Windows DNS Servers.

  Note: If multiple certificates from the same CA are present on the DNS server, IPsec authentication might fail due to an incorrect certificate being chosen. For this purpose, an Active Directory Certificate Services (AD CS) role must be installed and configured as an Enterprise certificate authority (CA).

  Refer to the Microsoft Windows Server DNS Overview.pdf for references on deploying certificates for this procedure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Complete the following procedures twice for each pair of name servers.
   
  Create a rule for UDP connections and then create a rule for TCP connections.
   
  Refer to the Microsoft Windows Server DNS Overview.pdf for Microsoft links for this procedure.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "gpme.msc" to open the Group Policy Management feature.

  In the "Browse for Group Policy Object" dialog box, double-click "Domain Controllers.domain.com".

  Click "Default Domain Controllers Policy" and click "OK".

  In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP.

  Right-click "Connection Security Rules" and select "New".

  For "Rule Type", select the "Server-to-server" radio button and click "Next".

  For Endpoint 1 and Endpoint 2, select "These IP addresses:" and add the IP addresses of all DNS servers. Click "Next".

  For "Requirements", select "Request authentication for inbound and outbound connections" and click "Next".

  For "Authentication Method", select Computer certificate and from the "Signing Algorithm:" drop-down, select "RSA (default)".

  From the "Certificate store type:" drop-down, select "Root CA (default)".

  From the "CA name:", click "Browse" and select the certificate generated by the internally managed server performing the AD CS role. Click "Next".

  On "Profile", accept the default selections and click "Next".

  On "Name", enter a name applicable to the rule's function (i.e., DNSSEC UDP).

  Click "Finish".

check_text:
  Note: This requirement applies to any Windows DNS Servers that host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too.

  This requirement is not applicable to servers with only a caching role.

  If the Windows DNS Servers host only AD-integrated zones, this requirement is not applicable.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "gpme.msc" to open the Group Policy Management feature.

  In the "Browse for Group Policy Object" dialog box, double-click "Domain Controllers.domain.com".

  Click "Default Domain Controllers Policy" and click "OK".

  In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP.

  Click "Connection Security Rules".

  Consult with the system administrator to determine which Rules meet the intent of DNSSEC server-to-server authentication.

  Double-click on each "Rule" to verify the following:

  For the "Authentication" tab, click on the "Customize..." button.

  On the "Authentication" tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections".

  Confirm the "Signing Algorithm" is set to "RSA (default)".

  Under "Method", verify the "Advanced:" radio button is selected. Click the "Customize" button.

  For "First authentication methods:", double-click on the entry.

  Verify the "Select the credential to use for first authentication:" has "Computer certificate from this certification authority (CA):" radio button selected.

  Review the certificate specified and verify the certificate used was generated by the internally managed server performing the AD CS role.

  If the certificate used does not meet the requirements, this is a finding.


vuln_id: V-259393
rule_id: SV-259393r1028387_rule
severity: CAT II
title: The Windows DNS Server must protect secret/private cryptographic keys while at rest.
cci: CCI-001199
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and nonvolatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.

  The DNS server must protect the confidentiality and integrity of shared keys for TSIG and private keys for SIG(0) and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  To ensure the cryptographic keys are protected after being backed up to tape or other medium, develop a backup policy that includes the protection of backup date at or above the level as the DNS server.

check_text:
  This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network.

  To verify the cryptographic keys are protected after being backed up to another medium (tape, disk, SAN, etc.), consult with the system administrator to determine the backup policy in place for the DNS server.

  If a backup policy does not exist or the backup policy does not specify the protection required for the backup medium to be at or above the level as the server, this is a finding.


vuln_id: V-259394
rule_id: SV-259394r961599_rule
severity: CAT II
title: The Windows DNS Server must only contain zone records that have been validated annually.
cci: CCI-002475
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>If zone information has not been validated in more than a year, there is no assurance that it is still valid. If invalid records are in a zone, an adversary could potentially use their existence for improper purposes. A standard operating procedure detailing this process can resolve this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Create a separate database to maintain record documentation for non-AD-integrated zones.

  Develop a procedure to validate annually all zone information on the DNS server against the separately maintained database.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Select the zone records that have not been validated in more than a year and revalidate.

check_text:
  This requirement is not applicable for a Windows DNS Server that is hosting only Active Directory (AD)-integrated zones.

  For a Windows DNS Server that hosts a mix of AD-integrated zones and manually maintained zones, ask the DNS database administrator if they maintain a separate database with record documentation for the non-AD-integrated zone information. Verify that the record's last verified date is less than one year prior to the date of the review.

  If a separate database with record documentation is not maintained for the non-AD-integrated zone information, this is a finding.

  If a separate database with record documentation is maintained for the non-AD-integrated zone information, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Review the zone records of the non-AD-integrated zones and compare to the separate documentation maintained.

  Determine if any records have not been validated in more than a year.

  If zone records exist that have not been validated in more than a year, this is a finding.


vuln_id: V-259395
rule_id: SV-259395r961152_rule
severity: CAT II
cci: CCI-001094
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must restrict individuals from using it for launching denial-of-service (DoS) attacks against other information systems.

description:
  <VulnDiscussion>Applications and application developers must take steps to ensure users cannot use an authorized application to launch DoS attacks against other systems and networks. For example, applications may include mechanisms that throttle network traffic, so users are not able to generate unlimited network traffic via the application. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> Allow log on through Remote Desktop Services to include only the following accounts or groups:

  Administrators

  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> Deny access to this computer from the network to include the following:

  Guests Group

  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> Deny log on locally to include the following:

  Guests Group

check_text:
  Review the DNS server to confirm the server restricts direct and remote console access to users other than Administrators.

  Verify the effective setting in Local Group Policy Editor.

  Run "gpedit.msc".

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If any accounts or groups other than the following are granted the "Allow log on through Remote Desktop Services" user right, this is a finding: 

  Administrators

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If the following accounts or groups are not defined for the "Deny access to this computer from the network" user right, this is a finding: 

  Guests Group

  Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

  If the following accounts or groups are not defined for the "Deny log on locally" user right, this is a finding: 

  Guests Group


vuln_id: V-259396
rule_id: SV-259396r961155_rule
severity: CAT II
cci: CCI-001095
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must use DNS Notify to prevent denial of service (DoS) through increase in workload.

description:
  <VulnDiscussion>In the case of application DoS attacks, care must be taken when designing the application to ensure it makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  In the list of hosts, review the NS records. Determine if any of the hosts listed as NS records are non-AD-integrated servers.

  If the DNS server hosts only AD-integrated zones and no non-AD-integrated DNS servers are acting as secondary DNS servers for the zones, this is not applicable.

  For a non-AD-integrated DNS server, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select and then right-click the zone name.

  From the displayed context menu, click the "Properties" option.

  On the opened zone's properties box, go to the "Zone Transfers" tab.

  On the displayed interface, determine if the "Allow zone transfers" check box is selected.

  If the "Allow zone transfers" check box is selected, click the "Notify" button and enable Notify to the non-AD-integrated DNS servers.

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  In the list of hosts, review the Name Server (NS) records. Determine if any of the hosts listed as NS records are non-Active Directory (AD)-integrated servers.

  If the DNS server hosts only AD-integrated zones and no non-AD-integrated DNS servers are acting as secondary DNS servers for the zones, this check is not applicable.

  For a non-AD-integrated DNS server, right-click on the "Forward Lookup Zone" and select "Properties".

  On the opened zone's properties box, go to the "Zone Transfers" tab.

  On the displayed interface, determine if the "Allow zone transfers" check box is selected.

  If the "Allow zone transfers" check box is selected, click the "Notify" button and verify "Automatically notify with Servers" is listed on the "Name Servers" tab.

  If the "Notify" button is not enabled for non-AD-integrated DNS servers, this is a finding.


vuln_id: V-259397
rule_id: SV-259397r961632_rule
severity: CAT I
title: The Windows DNS Server must protect the integrity of transmitted information.
cci: CCI-002418
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.

  Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa.

  Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
[cell repeats an earlier one in this file: 567 characters]

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259398
rule_id: SV-259398r961638_rule
severity: CAT II
cci: CCI-002420
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must maintain the integrity of information during preparation for transmission.

description:
  <VulnDiscussion>Information can be unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
[cell repeats an earlier one in this file: 1464 characters]


vuln_id: V-259399
rule_id: SV-259399r961641_rule
severity: CAT II
title: The Windows DNS Server must maintain the integrity of information during reception.
cci: CCI-002422
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Information can be unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the Windows DNS Server using the Domain Admin or Enterprise Admin account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand "Forward Lookup Zones".

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2022 10:22:28 PM
  Signed: 10/22/2022 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259400
rule_id: SV-259400r961857_rule
severity: CAT II
cci: CCI-002450
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.

description:
  <VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

  The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) (FIPS186) provides three algorithm choices:
  - Digital Signature Algorithm (DSA).
  - RSA.
  - Elliptic Curve DSA (ECDSA).

  Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. Both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm for this guideline. 

  RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e., RSA/SHA-256, ECDSA) are also specified.

  It can be expected that name servers and clients will be able to use the RSA algorithm at a minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm.

  NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS (FIPS186). It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before 30 September 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign, the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones". 

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone", using either approved saved parameters or approved custom parameters.

check_text:
  Note: This requirement applies to any Windows DNS Server that hosts non-Active Directory (AD)-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server hosts only AD-integrated zones and does not host any file-based zones, this is not applicable.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2014 10:22:28 PM
  Signed: 10/22/2014 10:22:28 PM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259401
rule_id: SV-259401r961158_rule
severity: CAT II
cci: CCI-001310
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must be configured to only allow zone information that reflects the environment for which it is authoritative, including IP ranges and IP versions.

description:
  <VulnDiscussion>DNS zone data for which a Windows DNS Server is authoritative should represent the network for which it is responsible. If a Windows DNS Server hosts zone records for other networks or environments, the records could become invalid or stale or be redundant/conflicting with a DNS server truly authoritative for the other network environment.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  If not automatically started, initialize the "Server Manager" window by clicking its icon from the bottom left corner of the screen.

  Once the "Server Manager" window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  Remove any zone information that is not part of the environment.

check_text:
  Consult with the system administrator to determine the IP ranges for the environment.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  If not automatically started, initialize the "Server Manager" window by clicking its icon from the bottom left corner of the screen.

  Once the "Server Manager" window is initialized, from the left pane, click to select the DNS category.

  From the right pane, under the "SERVERS" section, right-click the DNS server.

  From the context menu that appears, click "DNS Manager".

  On the opened DNS Manager snap-in from the left pane, expand the server name and then expand "Forward Lookup Zones".

  From the expanded list, click to select and then right-click the zone name.

  Review the zone information and compare it to the IP ranges for the environment.

  If any zone information is for a different IP range or domain, this is a finding.


vuln_id: V-259402
rule_id: SV-259402r987708_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must follow procedures to re-role a secondary name server as the primary name server if the primary name server permanently loses functionality.

description:
  <VulnDiscussion>Failing to an unsecure condition negatively impacts application security and can lead to system compromise. Failure conditions include, for example, loss of communications among critical system components or between system components and operational facilities. Fail-safe procedures include, for example, alerting operator personnel and providing specific instructions on subsequent steps to take (e.g., do nothing, reestablish system settings, shutdown processes, restart the system, or contact designated organizational personnel).

  If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  AD-integrated DNS servers will handle the promotion of a secondary DNS server when a primary DNS server loses functionality.

  Develop, test, and implement documented procedures to re-role a non-AD-integrated secondary name server to a master name server role if a master name server loses functionality.

check_text:
  Active Directory (AD)-integrated DNS servers will handle the promotion of a secondary DNS server when a primary DNS server loses functionality.

  If all of the DNS servers are AD integrated, this is not a finding.

  Consult with the system administrator to determine if there are documented procedures to re-role a non-AD-integrated secondary name server to a master name server role if a master name server loses functionality.

  If there are no documented procedures to re-role a non-AD-integrated secondary name server to primary if a master name server loses functionality, this is a finding.


vuln_id: V-259403
rule_id: SV-259403r1001264_rule
severity: CAT II
title: The DNS Name Server software must be configured to refuse queries for its version information.
cci: CCI-002201
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because it has design changes incorporated to address those vulnerabilities. The vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with respect to the nature of those exploits. It makes good business sense to run the latest version of name server software because theoretically it is the safest version.

  In some installations, it may not be possible to switch to the latest version of name server software immediately. If the version of the name server software is revealed in queries, this information may be used by attackers looking for a specific version of the software that has a discovered weakness. To prevent information about which version of name server software is running on a system, name servers should be configured to refuse queries for its version information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  To disable the version being returned in queries, execute the following command:

  dnscmd /config /EnableVersionQuery 0 <enter>

check_text:
  The "EnableVersionQuery" property controls what version information the DNS server will respond with when a DNS query with class set to "CHAOS" and type set to "TXT" is received.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Open a command window and execute the command:

  nslookup <enter>
  Note: Confirm the Default Server is the DNS server on which the command is being run.

  At the nslookup prompt, type:

  set type=TXT <enter>
  set class=CHAOS <enter>
  version.bind <enter>

  If the response returns something similar to text = "Microsoft DNS 6.1.7601 (1DB14556)", this is a finding.


vuln_id: V-259404
rule_id: SV-259404r1001265_rule
severity: CAT II
title: The HINFO, RP, TXT, and LOC RR types must not be used in the zone SOA.
cci: CCI-002201
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Several types of resource records (RRs) in the DNS are meant to convey information to humans and applications about the network, hosts, or services. These RRs include the Responsible Person (RP) record, the Host Information (HINFO) record, the Location (LOC) record, and the catch-all text string resource record (TXT) (RFC1035). Although these record types are meant to provide information to users in good faith, they also allow attackers to gain knowledge about network hosts before attempting to exploit them. For example, an attacker may query for HINFO records, looking for hosts that list an operating system or platform known to have exploits.

  Therefore, great care should be taken before including these record types in a zone. They are best left out completely.

  More careful consideration should be taken with the TXT resource record type. A DNS administrator will have to decide if the data contained in a TXT RR constitutes an information leak or is a necessary piece of information. For example, several authenticated email technologies use TXT RRs to store email sender policy information such as valid email senders for a domain. These judgments will have to be made on a case-by-case basis.

  A DNS administrator should take care when including HINFO, RP, TXT, LOC, or other RR types that could divulge information that would be useful to an attacker or the external view of a zone if using split DNS.

  RRs such as HINFO and TXT provide information about software name and versions (e.g., for resources such as web servers and mail servers) that will enable the well-equipped attacker to exploit the known vulnerabilities in those software versions and launch attacks against those resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Remove all HINFO, RP, TXT, and LOC RRs from all zones hosted by the DNS server.

check_text:
  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones".

  From the expanded list, click to select the zone.

  Review the zone's RRs and verify HINFO, RP, and LOC RRs are not used. If TXT RRs are used, they must not reveal any information about the organization that could be used for malicious purposes.

  If there are any HINFO, RP, LOC, or revealing TXT RRs in any zone hosted by the DNS server, this is a finding.


vuln_id: V-259405
rule_id: SV-259405r987640_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must, when a component failure is detected, activate a notification to the system administrator.

description:
  <VulnDiscussion>Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fail to function, the system could continue operating in an insecure state. The organization must be prepared, and the application must support requirements that specify if the application must alarm for such conditions and/or automatically shut down the application or the system.

  This can include conducting a graceful application shutdown to avoid losing information. Automatic or manual transfer of components from standby to active mode can occur, for example, upon detection of component failures.

  If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Implement a third-party monitoring system to detect and notify the system administrator upon component failure or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.

check_text:
  Notification to the system administrator is not configurable in Windows DNS Server. For system administrators to be notified when a component fails, the system administrator would have to implement a third-party monitoring system. At a minimum, the system administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day.

  If a third-party monitoring system is not in place to detect and notify the system administrator upon component failures, and the system administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding.


vuln_id: V-259406
rule_id: SV-259406r961734_rule
severity: CAT II
cci: CCI-002699
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must verify the correct operation of security functions upon startup and/or restart, upon command by a user with privileged access, and/or every 30 days.

description:
  <VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes but is not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Without verification, security functions may not operate correctly, and this failure may go unnoticed. 

  Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.

  The DNS server should perform self-tests, such as at server startup, to confirm that its security functions are working properly.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Sign or re-sign the hosted zone(s) on the DNS server being validated.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Press the Windows key + R and execute "dnsmgmt.msc".

  On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand "Forward Lookup Zones". 

  From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click "Sign the Zone" using either approved saved parameters or approved custom parameters.

check_text:
  Note: This requirement applies to any Windows DNS Server that hosts non-Active Directory (AD)-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server hosts only AD-integrated zones and does not host any file-based zones, this is not applicable.

  Validate this check from the Windows DNS Server being configured/reviewed.

  Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.

  Determine a valid host in the zone.

  Open the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.

  Issue the following command:
  (Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows DNS Server hosting the signed zone.)

  resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>

  Note: It is important to use the -server switch followed by the DNS server name/IP address.

  The result should show the "A" record results.

  In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:

  Name: www.zonename.mil
  QueryType: RRSIG
  TTL: 189
  Section: Answer
  TypeCovered: CNAME
  Algorithm: 8
  LabelCount: 3
  OriginalTtl: 300
  Expiration: 11/21/2022 10:22:28 AM
  Signed: 10/22/2022 10:22:28 AM
  Signer: zonename.mil
  Signature: {87, 232, 34, 134...}

  Name: origin-www.zonename.mil
  QueryType: A
  TTL: 201
  Section: Answer
  IP4Address: ###.###.###.###

  If the results do not show the RRSIG and signature information, this is a finding.


vuln_id: V-259407
rule_id: SV-259407r961734_rule
severity: CAT II
fix_text: Install an approved DOD system monitoring solution.
cci: CCI-002699
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must verify the correct operation of security functions upon system startup and/or restart, upon command by a user with privileged access, and/or every 30 days.

description:
  <VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes but is not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Without verification, security functions may not operate correctly, and this failure may go unnoticed. 

  Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.

  The DNS server should perform self-tests, such as at server startup, to confirm that its security functions are working properly.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

check_text:
  This functionality should be performed by an approved and properly configured DOD system monitoring solution. 

  If all required DOD products are not installed and /or the installed productions are not enabled, this is a finding.


vuln_id: V-259408
rule_id: SV-259408r961737_rule
severity: CAT II
cci: CCI-002702
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.

description:
  <VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes but is not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles and/or hardware indications, such as lights.

  If anomalies are not acted on, security functions may fail to secure the system.

  The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the operating system/network device manager can then trigger notification messages to the system administrator based on the presence of those audit records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG has been removed or broken or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.

check_text:
  Note: If the only zones hosted are AD-integrated zones, this check is not applicable.

  Notification to the system administrator is not configurable in Windows. For the administrator to be notified if functionality of DNSSEC/TSIG has been removed or broken, the information system security officer (ISSO), information system security manager (ISSM), or DNS administrator would need to implement a third-party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day.

  If a third-party monitoring system is not in place to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG has been removed or broken and the ISSO/ISSM/DNS administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding.


vuln_id: V-259409
rule_id: SV-259409r961185_rule
severity: CAT II
cci: CCI-001294
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server must be configured to notify the information system security officer (ISSO), information system security manager (ISSM), or DNS administrator when functionality of DNSSEC/TSIG has been removed or broken.

description:
  <VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes but is not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. If personnel are not notified of failed security verification tests, they will not be able to take corrective action, and the unsecure condition(s) will remain. Notifications provided by information systems include messages to local computer consoles and/or hardware indications, such as lights.

  The DNS server should be configured to generate audit records whenever a self-test fails. The operating system/network device manager is responsible for generating notification messages related to this audit record.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of Secure Updates has been removed or broken or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.

check_text:
  Note: This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network.

  Notification to the system administrator is not configurable in Windows DNS Server. For the ISSO/ISSM/DNS administrator to be notified if functionality of Secure Updates has been removed or broken, the ISSO/ISSM/DNS administrator would need to implement a third party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day.

  If a third-party monitoring system is not in place to detect and notify the ISSO/ISSM/DNS administrator if functionality of Secure Updates has been removed or broken and the ISSO/ISSM/DNS administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding.


vuln_id: V-259410
rule_id: SV-259410r1081086_rule
severity: CAT II
title: A unique Transaction Signature (TSIG) key must be generated for each pair of communicating hosts.
fix_text: Regenerate a unique TSIG key for each pair of communicating hosts within the DNS architecture.
cci: CCI-000186
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string generated by most key generation utilities used with DNSSEC is Base64 encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG Resource Record (RR) and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

check_text:
  This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network.

  Review the DNS implementation. Verify that each pair of communicating hosts has a unique TSIG key (i.e., a separate key for each secondary name server to authenticate transactions with the primary name server, etc.).

  If a unique TSIG key has not been generated for each pair of communicating hosts, this is a finding.

  If using DNSSEC, this requirement is not applicable.


vuln_id: V-259411
rule_id: SV-259411r961062_rule
severity: CAT II
cci: CCI-000877
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The DNS server implementation must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.

description:
  <VulnDiscussion>If unauthorized personnel use maintenance tools, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data.

  Nonlocal maintenance and diagnostic activities are conducted by individuals communicating through an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, public key infrastructure (PKI) where certificates are stored on a token protected by a password, passphrase, or biometric.

  This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping", "ls", or "ipconfig" or the hardware and software implementing the monitoring port of an Ethernet switch).

  Lack of authentication enables anyone to gain access to the network or possibly a network element that provides opportunity for intruders to compromise resources within the network infrastructure. Network access control mechanisms interoperate to prevent unauthorized access and enforce the organization's security policy. Authorization for access to any network element requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of all administrator accounts for all privilege levels must be accomplished using two or more factors that include the following:

  (i) something the user knows (e.g., password/PIN); 
  (ii) something the user has (e.g., cryptographic identification device, token); or 
  (iii) something the user is (e.g., biometric).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the DNS system to use multifactor authentication for nonlocal access for maintenance and diagnostics.

check_text:
  Review the DNS implementation's authentication methods and settings to determine if multifactor authentication is used to gain nonlocal access for maintenance and diagnostics.

  If multifactor authentication is not used, this is a finding.


vuln_id: V-259412
rule_id: SV-259412r961125_rule
severity: CAT II
cci: CCI-001665
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  In the event of a system failure, the Windows DNS Server must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.

description:
  <VulnDiscussion>Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Advanced Audit Policy Configuration >> System Audit Policies >> Object Access >> Audit File System with "Failure" selected.

check_text:
  Use the AuditPol tool to review the current Audit Policy configuration:

  Open a Command Prompt with elevated privileges ("Run as Administrator").

  Enter "AuditPol /get /category:*".

  Compare the AuditPol settings with the following. If the system does not audit the following, this is a finding.

  Object Access >> File System - Failure


vuln_id: V-259413
rule_id: SV-259413r961863_rule
severity: CAT II
title: The DNS Name Server software must run with restricted privileges.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
description:
  <VulnDiscussion>Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications.

  Logical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).

  If the name server software is run as a privileged user (e.g., root in Unix systems), any break-in into the software can have disastrous consequences in terms of resources resident in the name server platform. Specifically, a hacker who breaks into the software acquires unrestricted access and therefore can execute any commands or modify or delete any files. It is necessary to run the name server software as a nonprivileged user with access restricted to specified directories to contain damages resulting from break-in.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the permissions of the account being used to run the DNS software to have the least privileges required to run the DNS software.

check_text:
  Review the account under which the DNS software is running and determine the permissions that account has been assigned.

  If the account under which the DNS software is running has not been restricted to the least privileged permissions required for the purpose of running the software, this is a finding.


vuln_id: V-259414
rule_id: SV-259414r1028388_rule
severity: CAT II
fix_text: Store the private keys of the ZSK and KSK offline in an encrypted file system.
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The private keys corresponding to both the zone signing key (ZSK) and the key signing key (KSK) must not be kept on the DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.

description:
  <VulnDiscussion>The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy.

  This strategy is not feasible in situations in which the DNSSEC-aware name server must support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) must have both the zone file master copy and the private key corresponding to the zone signing key (ZSK-private) online to immediately update the signatures for the updated Resource Record Sets. The private key corresponding to the key signing key (KSK-private) can still be kept offline.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

check_text:
  This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network. 

  Review the DNS name server and documentation to determine if it accepts dynamic updates. 

  If dynamic updates are not accepted, verify the private keys corresponding to both the ZSK and KSK are not located on the name server.

  If the private keys to the ZSK and/or the KSK are located on the name server, this is a finding.


vuln_id: V-259415
rule_id: SV-259415r960948_rule
severity: CAT II
cci: CCI-001348
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  The Windows DNS Server audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.

description:
  <VulnDiscussion>Protection of log data includes ensuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto media separate from the system being audited on a defined frequency helps to ensure the audit records will be retained in the event of a catastrophic system failure.

  This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.

  This requirement applies only to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Document and implement a backup policy to back up the DNS server's audit records at least every seven days.

check_text:
  Consult with the system administrator to determine the backup policy in place for Windows DNS Server.

  Review the backup methods used and determine if the backup's methods have been successful at backing up the audit records at least every seven days.

  If the organization does not have a backup policy in place for backing up the Windows DNS Server's audit records and/or the backup methods have not been successful at backing up the audit records at least every seven days, this is a finding.


vuln_id: V-259416
rule_id: SV-259416r961863_rule
severity: CAT II
cci: CCI-000366
created_at: 2026-01-14 17:55:45
updated_at: 2026-01-14 17:55:45
title:
  In a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.

description:
  <VulnDiscussion>Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. 

  One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve resource records (RRs) pertaining to hosts with public services (web servers that serve external web pages or provide business-to-consumer services, mail servers, etc.).

  The other set, called internal name servers, is to be located within the firewall and should be configured so the servers are not reachable from outside and hence provide naming services exclusively to internal clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

fix_text:
  Configure the internal DNS server's firewall policy, or the network firewall, to block queries from external hosts.

check_text:
  Consult with the system administrator to review the internal Windows DNS Server's firewall policy.

  The inbound TCP and UDP ports 53 rule should be configured to only allow hosts from the internal network to query the internal DNS server.

  If the firewall policy is not configured with the restriction, consult with the network firewall administrator to confirm the restriction on the network firewall.

  If neither the DNS server's firewall policy nor the network firewall is configured to block external hosts from querying the internal DNS server, this is a finding.


