Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Documents
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
Active Directory Domain Security Technical Implementation Guide
Active Directory Domain Security Technical Implementation Guide
An XCCDF Benchmark
Details
Profiles
Items
Prose
36 rules organized in 36 groups
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Membership to the Enterprise Admins group must be restricted to accounts used only to manage the Active Directory Forest.
High Severity
<VulnDiscussion>The Enterprise Admins group is a highly privileged group. Personnel who are system administrators must log on to Active Directory systems only using accounts with the level of authority necessary. Only system administrator accounts used exclusively to manage the Active Directory Forest may be members of the Enterprise Admins group. A separation of administrator responsibilities helps mitigate the risk of privilege escalation resulting from credential theft attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Membership to the Domain Admins group must be restricted to accounts used only to manage the Active Directory domain and domain controllers.
High Severity
<VulnDiscussion>The Domain Admins group is a highly privileged group. Personnel who are system administrators must log on to Active Directory systems only using accounts with the level of authority necessary. Only system administrator accounts used exclusively to manage an Active Directory domain and domain controllers may be members of the Domain Admins group. A separation of administrator responsibilities helps mitigate the risk of privilege escalation resulting from credential theft attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Administrators must have separate accounts specifically for managing domain member servers.
Medium Severity
<VulnDiscussion>Personnel who are system administrators must log on to domain systems only using accounts with the minimum level of authority necessary. Only system administrator accounts used exclusively to manage domain member servers may be members of an administrator group for domain member servers. A separation of administrator responsibilities helps mitigate the risk of privilege escalation resulting from credential theft attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Administrators must have separate accounts specifically for managing domain workstations.
Medium Severity
<VulnDiscussion>Personnel who are system administrators must log on to domain systems only using accounts with the minimum level of authority necessary. Only system administrator accounts used exclusively to manage domain workstations may be members of an administrators group for domain workstations. A separation of administrator responsibilities helps mitigate the risk of privilege escalation resulting from credential theft attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Delegation of privileged accounts must be prohibited.
High Severity
<VulnDiscussion>Privileged accounts such as those belonging to any of the administrator groups must not be trusted for delegation. Allowing privileged accounts to be trusted for delegation provides a means for privilege escalation from a compromised system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000112
1 Rule
<GroupDescription></GroupDescription>
Local administrator accounts on domain systems must not share the same password.
Medium Severity
<VulnDiscussion>Local administrator accounts on domain systems must use unique passwords. In the event a domain system is compromised, sharing the same password for local administrator accounts on domain systems will allow an attacker to move laterally and compromise multiple domain systems.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Separate smart cards must be used for Enterprise Admin (EA) and Domain Admin (DA) accounts from smart cards used for other accounts.
Medium Severity
<VulnDiscussion>A separate smart card for Enterprise Admin and Domain Admin accounts eliminates the automatic exposure of the private keys for the EA/DA accounts to less secure user platforms when the other accounts are used. Having different certificates on one card does not provide the necessary separation. The same smart card may be used by an administrator for both EA and DA accounts. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Separate domain accounts must be used to manage public facing servers from any domain accounts used to manage internal servers.
Medium Severity
<VulnDiscussion>Public facing servers should be in DMZs with separate Active Directory forests. If, because of operational necessity, this is not possible, lateral movement from these servers must be mitigated within the forest. Having different domain accounts for administering domain joined public facing servers, from domain accounts used on internal servers, protects against an attacker's lateral movement from a compromised public facing server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000076
1 Rule
<GroupDescription></GroupDescription>
Windows service \ application accounts with administrative privileges and manually managed passwords, must have passwords changed at least every 60 days.
Medium Severity
<VulnDiscussion>NT hashes of passwords for accounts that are not changed regularly are susceptible to reuse by attackers using Pass-the-Hash. Windows service \ application account passwords are not typically changed for longer periods of time to ensure availability of the applications. If a service \ application also has administrative privileges it will provide elevated access if compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Domain controllers must be blocked from Internet access.
Medium Severity
<VulnDiscussion> Domain controllers provide access to highly privileged areas of a domain. Such systems with Internet access may be exposed to numerous attacks and compromise the domain. Restricting Internet access for domain controllers will aid in protecting these privileged areas from being compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000076
1 Rule
<GroupDescription></GroupDescription>
All accounts, privileged and unprivileged, that require smart cards must have the underlying NT hash rotated at least every 60 days.
Medium Severity
<VulnDiscussion>When a smart card is required for a domain account, a long password, unknown to the user, is generated. This password and associated NT hash are not changed as are accounts with passwords controlled by the maximum password age. Disabling and reenabling the "Smart card is required for interactive logon" (SCRIL) replaces the NT hash of the account with a newly randomized hash. Otherwise, the existing NT hash could be reused for Pass-the-Hash in the future. Windows Server 2016 includes a built-in feature for SCRIL hash rolling that will automatically reset NT hashes in accordance with the existing maximum password age policy. This requires the domain functional level to be Windows Server 2016. In Active Directory with a domain functional level below Windows Server 2016, scripts can be used to reset the NT hashes of all domain accounts. Associated documentation should be reviewed for potential issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
User accounts with domain level administrative privileges must be members of the Protected Users group in domains with a domain functional level of Windows 2012 R2 or higher.
Medium Severity
<VulnDiscussion>User accounts with domain level administrative privileges are highly prized in Pass-the-Hash/credential theft attacks. The Protected Users group provides extra protections to accounts such as preventing authentication using NTLM. These accounts include Enterprise and Domain Admins as well as other accounts that may have domain level privileges. The Protected Users group requires a domain functional level of at least Windows 2012 R2 to provide domain level protections.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Domain-joined systems (excluding domain controllers) must not be configured for unconstrained delegation.
Medium Severity
<VulnDiscussion>Unconstrained delegation enabled on a computer can allow the computer account to be impersonated without limitation. If delegation is required, it must be limited/constrained to the specific services and accounts required.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
The Directory Service Restore Mode (DSRM) password must be changed at least annually.
Medium Severity
<VulnDiscussion>The Directory Service Restore Mode (DSRM) password, used to log on to a domain controller (DC) when rebooting into the server recovery mode, is very powerful. With a weak or known password, someone with local access to the DC can reboot the server and copy or modify the Active Directory database without leaving any trace of the activity. Failure to change the DSRM password periodically could allow compromised of the Active Directory. It could also allow an unknown (lost) password to go undetected. If not corrected during a periodic review, the problem might surface during an actual recovery operation and delay or prevent the recovery.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
The domain functional level must be at a Windows Server version still supported by Microsoft.
Medium Severity
<VulnDiscussion>Domains operating at functional levels below Windows Server versions no longer supported by Microsoft reduce the level of security in the domain and forest as advanced features of the directory are not available. This also prevents the addition of domain controllers to the domain using Windows Server versions prior to the current domain functional level.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Access to need-to-know information must be restricted to an authorized community of interest.
Medium Severity
<VulnDiscussion>Because trust relationships effectively eliminate a level of authentication in the trusting domain or forest, they represent less stringent access control at the domain or forest level in which the resource resides. To mitigate this risk, trust relationships must be documented so that they can be readily verified during periodic inspections designed to validate only approved trusts are configured in AD.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Interconnections between DoD directory services of different classification levels must use a cross-domain solution that is approved for use with inter-classification trusts.
High Severity
<VulnDiscussion>If a robust cross-domain solution is not used, then it could permit unauthorized access to classified data. To support secure access between resources of different classification levels, the solution must meet discretionary access control requirements. There are currently, no DOD- approved solutions. Further Policy Details: Do not define trust relationships between domains, forests, or realms with resources at different classification levels. The configuration of a trust relationship is one of the steps used to allow users in one AD domain to access resources in another domain, forest, or Kerberos realm. (This check does not apply to trusts with non-DoD organizations since these trusts are examined in a previous check.)</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
A controlled interface must have interconnections among DoD information systems operating between DoD and non-DoD systems or networks.
High Severity
<VulnDiscussion>The configuration of an AD trust relationship is one of the steps used to allow users in one domain to access resources in another domain, forest, or Kerberos realm. When a trust is defined between a DoD organization and a non-DoD organization, the security posture of the two organizations might be significantly different. If the non-DoD organization maintained a less secure environment and that environment were compromised, the presence of the AD trust might allow the DoD environment to be compromised also.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000104
1 Rule
<GroupDescription></GroupDescription>
Security identifiers (SIDs) must be configured to use only authentication data of directly trusted external or forest trust.
Medium Severity
<VulnDiscussion>Under some circumstances it is possible for attackers or rogue administrators that have compromised a domain controller in a trusted domain to use the SID history attribute (sIDHistory) to associate SIDs with new user accounts, granting themselves unauthorized rights. To help prevent this type of attack, SID filter quarantining is enabled by default on all external trusts. However, it is possible for an administrator to change this setting or the trust may have been created in an older version of AD. SID filtering causes SID references that do not refer to the directly trusted domain or forest to be removed from inbound access requests in the trusting domain. Without SID filtering, access requests could contain spoofed SIDs, permitting unauthorized access. In cases where access depends on SID history or Universal Groups, failure to enable SID filtering could result in operational problems, including denial of access to authorized users. When the quarantine switch is applied to external or forest trusts, only those SIDs from the single, directly trusted domain are valid. In effect, enabling /quarantine on a trust relationship will break the transitivity of that trust so that only the specific domains on either side of the trust are considered participants in the trust.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000080
1 Rule
<GroupDescription></GroupDescription>
Selective Authentication must be enabled on outgoing forest trusts.
Medium Severity
<VulnDiscussion>Enabling Selective Authentication on outbound Active Directory (AD) forest trusts significantly strengthens access control by requiring explicit authorization (through the Allowed to Authenticate permission) on resources in the trusting forest. When Selective Authentication is not enabled, less secure resource access permissions (such as those that specify Authenticated Users) might permit unauthorized access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000121
1 Rule
<GroupDescription></GroupDescription>
The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.
Medium Severity
<VulnDiscussion>The Pre-Windows 2000 Compatible Access group was created to allow Windows NT domains to interoperate with AD domains by allowing unauthenticated access to certain AD data. The default permissions on many AD objects are set to allow access to the Pre-Windows 2000 Compatible Access group. When the Anonymous Logon or Everyone groups are members of the Pre-Windows 2000 Compatible Access group, anonymous access to many AD objects is enabled. Anonymous access to AD data could provide valuable account or configuration information to an intruder trying to determine the most effective attack strategies.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Membership in the Group Policy Creator Owners and Incoming Forest Trust Builders groups must be limited.
Medium Severity
<VulnDiscussion>Membership in the Group Policy Creator Owners and Incoming Forest Trust Builders groups assigns a high privilege level for AD functions. Unnecessary membership increases the risk from compromise or unintended updates. Members of these groups must specifically require those privileges and be documented.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
User accounts with delegated authority must be removed from Windows built-in administrative groups or remove the delegated authority from the accounts.
Low Severity
<VulnDiscussion>In AD it is possible to delegate account and other AD object ownership and administration tasks. (This is commonly done for help desk or other user support staff.) This is done to avoid the need to assign users to Windows groups with more widely ranging privileges. If a user with delegated authority to user accounts in a specific OU is also a member of the Administrators group, that user has the ability to reconfigure a wide range of domain security settings and change user accounts outside of the OU to which s/he is a delegated authority. A lack of specific baseline documentation of accounts with delegated privileges makes it impossible to determine if the configured privileges are consistent with the intended security policy.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Read-only Domain Controller (RODC) architecture and configuration must comply with directory services requirements.
Medium Severity
<VulnDiscussion>The RODC role provides a unidirectional replication method for selected information from your internal network to the DMZ. If not properly configured so that the risk footprint is minimized, the interal domain controller or forest can be compromised. RODC is considered part of the site's Forest or Domain installation since it is not a standalone product, but rather a role of the the Windows AD DS full installation or Server Core installation. It is possible to have Windows 2003 clients authenticated using RODC, however, compatibility packs are needed. Note that RODC is not authorized for use across the site's perimeter firewall.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Usage of administrative accounts must be monitored for suspicious and anomalous activity.
Medium Severity
<VulnDiscussion>Monitoring the usage of administrative accounts can alert on suspicious behavior and anomalous account usage that would be indicative of potential malicious credential reuse.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Systems must be monitored for attempts to use local accounts to log on remotely from other systems.
Medium Severity
<VulnDiscussion>Monitoring for the use of local accounts to log on remotely from other systems may indicate attempted lateral movement in a Pass-the-Hash attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Systems must be monitored for remote desktop logons.
Medium Severity
<VulnDiscussion>Remote Desktop activity for administration should be limited to specific administrators, and from limited management workstations. Monitoring for any Remote Desktop logins outside of expected activity can alert on suspicious behavior and anomalous account usage that could be indicative of potential malicious credential reuse.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Active Directory data must be backed up daily for systems with a Risk Management Framework categorization for Availability of moderate or high. Systems with a categorization of low must be backed up weekly.
Medium Severity
<VulnDiscussion>Failure to maintain a current backup of directory data could make it difficult or impossible to recover from incidents including hardware failure or malicious corruption. A failure to recover from the loss of directory data used in identification and authentication services (i.e., Active Directory) could result in an extended loss of availability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Each cross-directory authentication configuration must be documented.
Low Severity
<VulnDiscussion>Active Directory (AD) external, forest, and realm trust configurations are designed to extend resource access to a wider range of users (those in other directories). If specific baseline documentation of authorized AD external, forest, and realm trust configurations is not maintained, it is impossible to determine if the configurations are consistent with the intended security policy.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000423
1 Rule
<GroupDescription></GroupDescription>
A VPN must be used to protect directory network traffic for directory service implementation spanning enclave boundaries.
Medium Severity
<VulnDiscussion>The normal operation of AD requires the use of IP network ports and protocols to support queries, replication, user authentication, and resource authorization services. At a minimum, LDAP or LDAPS is usually required for communication with every domain controller. DoD Ports, Protocols, and Services Management (PPSM) policy restricts the use of LDAP, LDAPS, and many of the AD-related protocols across enclave boundaries because vulnerabilities exist in the protocols or service implementations. To comply with the restrictions and address the vulnerabilities, a VPN implementation may be used. If AD data traverses enclave network boundaries using a vulnerable protocol or service without the protection provided by a VPN, that data might be subject to tampering or interception. Further Policy Details: Implement a VPN or other network protection solution in accordance with the Network Infrastructure STIG that protects AD data in transit across DoD enclave boundaries. VPN requirements will include registering the VPN and connection points with the PPSM. Current guidance is available in the Network Infrastructure STIG and from the PPSM.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Accounts from outside directories that are not part of the same organization or are not subject to the same security policies must be removed from all highly privileged groups.
Medium Severity
<VulnDiscussion>Membership in certain default directory groups assigns a high privilege level for access to the directory. In AD, membership in the following groups enables high privileges relative to AD and the Windows OS: Domain Admins, Enterprise Admins, Schema Admins, Group Policy Creator Owners, and Incoming Forest Trust Builders. When accounts from an outside directory are members of highly privileged groups in the directory being reviewed, less rigorous security policies or compromises of accounts in the outside directory could increase the risk to the directory where the privileged groups are defined. A compromise to the outside directory would allow unauthorized, privileged access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Inter-site replication must be enabled and configured to occur at least daily.
Medium Severity
<VulnDiscussion>Timely replication makes certain that directory service data is consistent across all servers that support the same scope of data for their clients. In AD implementation using AD Sites, domain controllers defined to be in different AD Sites require Site links to specify properties for replication scheduling. If AD Site link schedule and replication interval properties are configured improperly, AD data replication may not occur frequently enough and updates to identification, authentication, or authorization data may not be current on all domain controllers. If this data is not current, access to resources may be incorrectly granted or denied. The default for inter-site replication is to occur every 180 minutes, 24 hours a day.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000032
1 Rule
<GroupDescription></GroupDescription>
If a VPN is used in the AD implementation, the traffic must be inspected by the network Intrusion detection system (IDS).
Medium Severity
<VulnDiscussion>To provide data confidentiality, a VPN is configured to encrypt the data being transported. While this protects the data, some implementations do not allow that data to be processed through an intrusion detection system (IDS) that could detect data from a compromised system or malicious client. Further policy details:Replace the VPN solution or reconfigure it so that directory data is processed by a network or host-based intrusion detection system (IDS). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Active Directory implementation information must be added to the organization contingency plan where the Risk Management Framework categorization for Availability is moderate or high.
Low Severity
<VulnDiscussion>When an incident occurs that requires multiple Active Directory (AD) domain controllers to be rebuilt, it is critical to understand the AD hierarchy and replication flow so that the correct recovery sequence and configuration values can be selected. Without appropriate AD forest, tree and domain structural documentation, it may be impossible or very time consuming to reconstruct the original configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
Active Directory must be supported by multiple domain controllers where the Risk Management Framework categorization for Availability is moderate or high.
Medium Severity
<VulnDiscussion>In Active Directory (AD) architecture, multiple domain controllers provide availability through redundancy. If an AD domain or servers within it have an Availability categorization of medium or high and the domain is supported by only a single domain controller, an outage of that machine can prevent users from accessing resources on servers in that domain and in other AD domains.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-OS-000480
1 Rule
<GroupDescription></GroupDescription>
The impact of INFOCON changes on the cross-directory authentication configuration must be considered and procedures documented.
Low Severity
<VulnDiscussion>When incidents occur that require a change in the INFOCON status, it may be necessary to take action to restrict or disable certain types of access that is based on a directory outside the Component's control. Cross-directory configurations (such as trusts and pass-through authentication) are specifically designed to enable resource access across directories. If conditions indicate that an outside directory is at increased risk of compromise in the immediate or near future, actions to avoid a spread of the effects of the compromise should be taken. A trusted outside directory that is compromised could allow an unauthorized user to access resources in the trusting directory.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>