acceptedActive Directory Domain Security Technical Implementation Guide (STIG)This STIG provides focused security requirements for the AD or Active Directory Domain Services (AD DS) element for Windows Server 2003, Windows Server 2008 and Windows Server 2008R2. These requirements apply to the domain and can typically be reviewed once per AD domain. The separate Active Directory Forest STIG contains forest level requirements. Systems must also be reviewed using the applicable Windows STIG. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil. DISA, Field Security OperationsSTIG.DOD.MILRelease: 2 Benchmark Date: 29 Mar 20132I - Mission Critial Classified<ProfileDescription></ProfileDescription>I - Mission Critial Public<ProfileDescription></ProfileDescription>I - Mission Critial Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>Object Ownership Delegation<GroupDescription></GroupDescription>AD.0260User accounts with delegated authority must be removed from Windows built-in administrative groups or remove the delegated authority from the accounts.<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>Information Assurance Manager</Responsibility><IAControls>ECLP-1, ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain8701. Remove user accounts with delegated authority from Windows built-in administrative groups or remove the delegated authority from the accounts.
2. Document all user accounts with delegated AD object ownership or update authority.
3. Annotate the account list with a statement such as, “The high number of privileged accounts is required to address site operational requirements.”
4. Reduce the number of user accounts with delegated AD object ownership or update authority.
1. Interview the IAM or site representative and obtain the list of accounts that have been delegated AD object ownership or update permissions and that are not members of Windows built-in administrative groups.
(This includes accounts for help desk or support personnel who are not Administrators, but have authority in AD to maintain user accounts or printers.)
2. If accounts with delegated authority are defined and there is no list, then this is a finding.
3. Count the number of accounts on the list.
4. If the number of accounts with delegated authority is greater than 10, review the site documentation that justifies this number. Validate that the IAM explicitly acknowledges the need to have a high number of privileged users.
5. If the number of accounts with delegated authority is greater than 10 and there is no statement in the documentation that justifies the number, then this is a finding.Directory Service Inter-Enclave VPN Usage<GroupDescription></GroupDescription>DS00.1140_ADA VPN must be used to protect directory network traffic for directory service implementation spanning enclave boundaries.<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>Information Assurance Officer</Responsibility><Responsibility>Information Assurance Manager</Responsibility><IAControls>DCPP-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Implement a VPN or other network protection solution in accordance with the Network Infrastructure STIG that protects AD data in transit across DoD enclave boundaries.1. Review the site's network diagram(s) to determine if domain controllers for the domain are located in multiple enclaves. The object is to determine if network traffic is traversing enclave network boundaries.
2. Request information about RODC or ADAM instances are installed. In particular, request details of Active Diretory functionality installed or extended into the DMZ or configured/allowed to cross the sites outbound firewall boundary. Ensure communications and replication traffic is encrypted.
3. If domain controllers are not located in multiple enclaves, then this check is not applicable.
4. If domain controllers are located in multiple enclaves, verify that a VPN is used to transport the network traffic (replication, user logon, queries, etc.).
5. If a VPN solution is not used to transport directory network traffic across enclave boundaries, then this is a finding.
6. If the ADAM mode is in use and a migration plan for converting to RODC is not in place, then this is a finding.IDS Visibility of Directory VPN Data Transport<GroupDescription></GroupDescription>DS00.4140_ADIf a VPN is used in the AD implementation, the traffic must be inspected by the network Intrusion detection system (IDS).<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>Information Assurance Officer</Responsibility><IAControls>EBVC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Replace the VPN solution or reconfigure it so that directory data is inspected by a network or host-based IDS.1. Interview the site representative. Ask about the location of the domain controllers.
2. If domain controllers are not located in multiple enclaves, then this check is not applicable.
3. If domain controllers are located in multiple enclaves and a VPN is not used, then this check is not applicable.
4. If domain controllers are located in multiple enclaves and a VPN is used, review the site network diagram(s) with the SA, NSO, or network reviewer as required to determine if the AD network traffic is visible to a network or host IDS.
5. If the AD network traffic is not visible to a network or host IDS, then this is a finding.Directory Service Availability<GroupDescription></GroupDescription>DS00.6140_ADWhen the domain supports a MAC I or II domain, the directory service must be supported by multiple directory servers.<VulnDiscussion>In AD architecture, multiple domain controllers provide availability through redundancy. If an AD domain or servers within it are designated as MAC I or II 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>Information Assurance Officer</Responsibility><IAControls>COTR-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870When the domain supports a MAC I or II domain, the directory service will be supported by multiple directory servers.1. Determine the MAC level information for the directory server. If the asset is registered in VMS, this is available by using Asset Finding Maint. and navigating to the asset or by running an Asset Information (AS01) report for the location.
2. If the MAC level of the directory server is III, this check is not applicable.
3. Start the Active Directory Users and Computers console (Start, Run, “dsa.msc”).
4. Select and expand the left pane item that matches the name of the domain being reviewed.
5. Select the Domain Controllers [OU] item in the left pane.
6. Count the number of computers (objects) in the Domain Controllers OU.
7. If there is only one domain controller for a MAC I or II level domain, then this is a finding.Directory Service Architecture DR Documentation<GroupDescription></GroupDescription>DS00.6120_ADAD implementation information must be added to the sites disaster recovery plans, including AD forest, tree, and domain structure.
<VulnDiscussion>When an incident occurs that requires multiple 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>Information Assurance Officer</Responsibility><IAControls>CODP-1, CODP-2, CODP-3, COEF-1, COEF-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Update the disaster recovery plans to include directory service architecture details such as hierarchy and replication structure.1. Interview the IAO. Ask about the MAC levels of the system.
2. Determine the MAC level information for the AD Domain asset. If the asset is registered in VMS, this is available by using Asset Finding Maint. and navigating to the asset or by running an Asset Information (AS01) report for the location.
3. If the MAC level of the AD Domain is III, this check is not applicable.
4. Obtain a copy of the site’s disaster recovery planning documents.
5. Check the disaster recovery plans for documentation on the AD hierarchy (forest, tree, and domain structure).
(A chart showing forest hierarchy and domain names is the minimum suggested.)
6. If the disaster recovery plans that cover a MAC I or II level AD Domain do not include directory hierarchy information, then this is a finding.Cross-Directory Authentication INFOCON Procedures<GroupDescription></GroupDescription>DS00.7100_ADThe impact of INFOCON changes on the cross-directory authentication configuration must be considered and procedures documented.<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>Information Assurance Officer</Responsibility><IAControls>VIIR-1, VIIR-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Evaluate cross-directory configurations (such as trusts and pass-through authentication) and provide documentation that indicates:
1. That an evaluation was performed.
2. The specific AD trust configurations, if any, that should be disabled during changes in INFOCON status because they could represent increased risk. 1. Refer to the list of actual manual AD trusts (cross-directory configurations) collected from the site representative.
2. If there are no manual AD trusts (cross-directory configurations) defined, this check is not applicable.
For AD, this includes external, forest, or realm trust relationship types.
3. Obtain a copy of the site’s supplemental INFOCON procedures as required by Strategic Command Directive (SD) 527-1.
4. Verify that it has been determined by the IAM whether INFOCON response actions need to include procedures to disable manual AD trusts (cross-directory configurations). The objective is to determine if the need has been explicitly evaluated.
5. If it has been determined that actions to disable manual AD trusts (cross-directory configurations) are not necessary, then this check is not applicable.
6. If it has been determined that actions to disable manual AD trusts (cross-directory configurations) *are* necessary, verify that the policy to implement these actions has been documented.
7. If actions to disable manual AD trusts (cross-directory configurations) *are* needed and no policy has been documented, then this is a finding.Cross-Directory Authentication Documentation<GroupDescription></GroupDescription>DS00.1120_ADEach cross-directory authentication configuration must be documented.<VulnDiscussion>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>Information Assurance Officer</Responsibility><IAControls>DCID-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Develop documentation for each AD external, forest, and realm trust configuration. At a minimum this must include:
a. Type (external, forest, or realm).
b. Name of the other party.
c. MAC, confidentiality, and classification level of the other party.
d. Trust direction (inbound and\or outbound).
e. Transitivity.
f. Status of the Selective Authentication option.
g. Status of the SID filtering option. 1. Start the Active Directory Domains and Trusts console (Start, Run, “domain.msc”).
2. Select the left pane item that matches the name of the domain being reviewed.
3. Right-click the domain name and select the Properties item.
4. On the domain object Properties window, select the Trusts tab.
5. For each outbound and inbound external, forest, and realm trust, record the name of the other party (domain name), the trust type, transitivity, and the trust direction. (Keep this trust information for use in subsequent checks.)
6. Compare the list of actual trusts identified with the list in local documentation maintained by the IAO. For each trust, the documentation must contain type (external, forest, or realm), name of the other party, MAC and classification level of the other party, trust direction (inbound and\or outbound), transitivity, status of the Selective Authentication option, and status of the SID filtering option.
7. If an identified trust is not listed in the documentation or if any of the required items are not documented, then this is a finding.Trusts - document need <GroupDescription></GroupDescription>AD.0170Access to need-to-know information must be restricted to an authorized community of interest.<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>Information Assurance Officer</Responsibility><IAControls>ECAN-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Delete the unneeded trust relationship or document the access requirement or mission need for the trust.
1. Before performing this check, perform V-8530 which validates the trusts within the documentation are current within AD.
2. Obtain documentation of the site's approved trusts from the site representative.
3. For each of the identified trusts, verify that the documentation includes a justification or explanation of the need-to-know basis of the trust.
4. If the need for the trust is not documented, then this is a finding.Trust - Classification Levels<GroupDescription></GroupDescription>AD.0180Interconnections between DoD directory services of different classification levels must use a cross-domain solution that is approved for use with inter-classification trusts.<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>Information Assurance Officer</Responsibility><IAControls>ECIC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Delete the trust relationship that is defined between entities with resources at different DoD classification levels.1. Refer to the list of identified trusts and the trust documentation provided by the site representative. (Obtained in V-8530)
2. For each of the identified trusts between DoD organizations, compare the classification level (unclassified, confidential, secret, and top secret) of the domain being reviewed with the classification level of the other trust party as noted in the documentation.
3. If the classification level of the domain being reviewed is different than the classification level of any of the entities for which a trust relationship is defined, then this is a finding.
Trust - Non-DoD<GroupDescription></GroupDescription>AD.0181A controlled interface must have interconnections among DoD information systems operating between DoD and non-DoD systems or networks.<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>Information Assurance Officer</Responsibility><IAControls>ECIC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Obtain DAA approval and document external, forest, or realm trust relationship. Or obtain documentation of the network connection approval and explicit trust approval by the DAA.1. Refer to the list of identified trusts obtained in a previous check (V8530).
2. For each of the identified trusts, determine if the other trust party is a non-DoD entity. For example, if the fully qualified domain name of the other party does not end in “.mil”, the other party is probably not a DoD entity.
3. Review the local documentation approving the external network connection and documentation indicating explicit approval of the trust by the DAA.
4. The external network connection documentation is maintained by the IAO\NSO for compliance with the Network Infrastructure STIG.
5. If any trust is defined with a non-DoD system and there is no documentation indicating approval of the external network connection and explicit DAA approval of the trust, then this is a finding.Trust - SID Filter Quarantining <GroupDescription></GroupDescription>AD.0190Security identifiers (SIDs) must be configured to use only authentication data of directly trusted external or forest trust. <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. Also, 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>Information Assurance Officer</Responsibility><IAControls>ECAN-1, ECCD-1, ECCD-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Enable SID filtering on all external or forest trusts. You can enable SID filter quarantining only from the trusting side of the trust. Enter the following line from a command line.
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /quarantine:Yes
/usero:<DomainAdministratorAcct> /passwordo:<DomainAdminPwd>1. Start the Active Directory Domains and Trusts console (Start, Run, "domain.msc”).
2. Select the left pane item that matches the name of the domain being reviewed.
3. Right-click the domain name and select the Properties item.
4. On the domain object Properties window, select the Trusts tab.
5. Use the following command to verify the quarantine setting for each trust.
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /quarantine
6. If the output of the netdom commands indicates that SID filtering is not enabled for each trusting external or forest trust, then this is a finding.Trust - Selective Authentication<GroupDescription></GroupDescription>AD.0200Selective Authentication must be enabled on the outgoing forest trust.<VulnDiscussion>Outbound AD forest trusts can be configured with the Selective Authentication option. Enabling this option 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.
Further Policy Details: Selective Authentication can be configured with the Domains and Trusts console (domain.msc). It may be necessary to configure the Allowed to Authenticate permission on resources in the trusting domain. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts>Implementation requires configuration of the Allowed to Authenticate permission on resources in the trusting domain for which access is desired. Failure to configure this permission could result in operational problems including denied resource access to authorized users.</PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECAN-1, ECCD-1, ECCD-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Enable Selective Authentication on the outgoing forest trust.1. Start the Active Directory Domains and Trusts console (Start, Run, “domain.msc”).
2. Select the left pane item that matches the name of the domain being reviewed and perform the following:
a. Right-click the domain name and select the Properties item.
b. On the domain object Properties window, select the Trusts tab.
c. For each outgoing forest trust, right-click the trust item and select the Properties item.
d. On the trust Properties window, select the Authentication tab. Determine if the Selective Authentication option is selected.
3. If the Selective Authentication option is not selected on every outgoing forest trust, then this is a finding.Pre-Windows 2000 Compatible Access Group<GroupDescription></GroupDescription>AD.0220The Everyone and Anonymous Logon groups must be removed from the Pre-Windows 2000 Compatible Access group.
<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.
Implementation in a Windows forest in which Windows NT domain controllers are still deployed could result in operational problems including denied access to authorized users.
When the Everyone or Anonymous Logon 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>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECAN-1, ECCD-1, ECCD-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Remove the Everyone and Anonymous Logon groups from the Pre-Windows 2000 Compatible Access group.1. Start the Active Directory Users and Computers console (Start, Run, “dsa.msc”).
2. Select and expand the left pane item that matches the name of the domain being reviewed and perform the following:
a. Select the Builtin item.
b. Double-click the Pre-Windows 2000 Compatible Access group and select the Members tab.
3. If the Anonymous Logon group or Everyone group is a member of the Pre-Windows 2000 Compatible Access group, then this is a finding.Privileged Group Membership - Intra-Forest<GroupDescription></GroupDescription>AD.0240The number of member accounts in privileged groups must not be excessive. <VulnDiscussion>Membership in the following Windows security groups assigns a high privilege level for AD functions: Domain Admins, Enterprise Admins, Schema Admins, Group Policy Creator Owners, and Incoming Forest Trust Builders.
When a large number of users are members of highly privileged groups, the risk from unintended updates or compromised accounts is significantly increased.
A lack of specific baseline documentation on privileged group membership makes it impossible to determine if the assigned accounts are consistent with the intended security policy.
Further Policy Details: It is possible to move the highly privileged AD security groups out of the AD Users container. If the Domain Admins, Enterprise Admins, Schema Admins, or Group Policy Creator Owners groups are not in the AD Users container, ask the SA for the new location and use that location for this check.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Manager</Responsibility><IAControls>ECLP-1, ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Update the site documentation to include all the accounts that are members of highly privileged groups. Annotate the account list(s) with a statement such as, “The high number of privileged accounts is required to address site operational requirements.” Reduce the number of accounts in highly privileged groups to the minimum level necessary. 1. Start the Active Directory Users and Computers console (Start, Run, “dsa.msc”).
2. Select and expand the left pane item that matches the name of the domain being reviewed.
3. Select the Built-in container. If the Incoming Forest Trust Builders group is defined perform the following:
a. Double-click on the group and select the Members tab
b. Count the number of accounts in the group
c. Compare the accounts in the group with the local documentation.
4. Select the Users container. For each of the Domain Admins, Enterprise Admins, Schema Admins, and Group Policy Creator Owners groups perform the following:
a. Double-click on the group and select the Members tab
b. Count the number of accounts in the group
c. Compare the accounts in the group with the local documentation.
5. If an account in a highly privileged AD security group is not listed in the local documentation, then this is a finding.
6. If the number of accounts defined in a highly privileged AD security group is greater than the number below, review the site documentation that justifies this number.
a. For the Enterprise Admins, Schema Admins, Group Policy Creator Owners, and Incoming Forest Trust Builders groups, the number of accounts should be between zero (0) and five (5).
b. The number of Domain Admins should be between one (1) and ten (10).
7. If the number of accounts defined in a highly privileged AD security group is greater than the guidance above and there is no documentation that justifies the number, then this is a finding.Privileged Group Membership - Cross-Directory<GroupDescription></GroupDescription>DS00.3200_ADAccounts 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.
<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>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECLP-1, ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Remove accounts from outside directories that are not part of the same organization or are not subject to the same security policies from the highly privileged groups.
1. Start the Active Directory Users and Computers console (Start, Run, “dsa.msc”).
2. Select and expand the left pane item that matches the name of the domain being reviewed.
3. Select the Built-in container.
a. If the Incoming Forest Trust Builders group is defined, double-click on the group, and select the Members tab
b. Examine the defined accounts to see if they are from a domain that is not in the forest being reviewed.
4. Select the Users container
a. For each group (Domain Admins, Enterprise Admins, Schema Admins, and Group Policy Creator Owners), double-click on the group, and select the Members tab.
b. Examine the defined accounts to see if they are from a domain that is not in the forest being reviewed.
5. If any account in a privileged group is from a domain outside the forest being reviewed and that outside forest is not maintained by the same organization (e.g., enclave) or subject to the same security policies, then this is a finding.
Supplementary Notes:
Note: An account that is from an outside domain appears in the format “outside-domain-NetBIOSname\account” or “account@outside-domain-fully-qualified-name”. Examples are “AOFN21\jsmith” or “jsmith@AOFN21.OST.COM”. It may be necessary to use the AD Domains and Trusts (domain.msc) console to determine if the domain is from another AD forest.
Note: It is possible to move the highly privileged AD security groups out of the AD Users container. If the Domain Admins, Enterprise Admins, Schema Admins, or Group Policy Creator Owners groups are not in the AD Users container, ask the SA for the new location and use that location for this check.Domain Functional Level<GroupDescription></GroupDescription>AD.0160The domain functional level must be Windows 2003 or higher.<VulnDiscussion>Non-vendor supported versions of AD are not permitted for use in DoD. Domain controllers using Windows NT and Windows 2000 are no longer supported or updated by the vendor. If Windows NT or Windows 2000 domain controllers are used in AD domains, the level of security in the domain and forest is significantly reduced because many advanced features of the directory are not available.
Further Policy Details: Raising the domain functional level to Windows Server 2003 or higher is a non-reversible task. This action prevents the addition of Windows NT- or Windows 2000–based domain controllers to the domain. Any existing Windows NT- or Windows 2000–based domain controllers in the environment will no longer function. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Raise the domain functional level to Windows Server 2003 or higher.1. Select the left pane item that matches the name of the domain being reviewed.
2. Right-click the domain name and select the Properties item.
3. On the General tab, note the value of “Domain functional level”.
4. If the current domain functional level is Windows Server 2000, Windows 2003 Interim, or Windows NT, then this is a finding.Replication Schedule<GroupDescription></GroupDescription>DS00.3230_ADReplication must be enabled and configured to occur at least daily.<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.
Further policy details:
An AD instance may have no AD site links defined. The following are ways in which site link properties would prevent daily AD replication:
1. Setting the “Replicate every” value to a number greater than 1440 (the number of minutes in one day).
2. Setting the Schedule value for all hours in a day to “Replication Not Available”.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECAN-1, ECCD-1, ECCD-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Enable daily replication (at a minimum) for the directory service.
1. Start the Active Directory Sites and Services console (Start, Run, “dssite.msc”).
2. Select and expand the Sites item in the left pane.
3. Select and expand the Inter-Site Transports item and the IP item in the left pane.
4. For each site link that is defined perform the following:
a. Right-click the site link item and select the Properties item.
b. Note the interval indicated in the “Replicate every” field.
c. Click the Change Schedule button.
d. Using the values indicated for “Replication Available”, determine if the replication interval would allow daily replication to occur.
e. Click the Cancel button for the Schedule window.
f. Click the Cancel button for the Properties window.
g. If the replication interval and replication available properties do not allow daily replication, then this is a finding.Directory Data Backup<GroupDescription></GroupDescription>DS00.0160_ADDirectory data must be backed up at the required frequency.<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>Information Assurance Officer</Responsibility><IAControls>CODB-1, CODB-2, CODB-3</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain8701. Change local site procedures to include a complete backup of directory data in compliance with the following frequency:
a. MAC I or II system - back up the directory data at least daily.
b. MAC III systems - back up the directory data at least weekly.
2. Change local site procedures to use a backup tool that is appropriate for the directory technology.
3. Ensure that the type of backup is appropriate to capturing the directory data. For AD domain controllers, this must include a System State data backup 1. Interview the IAO.
2. Obtain a copy of the site’s SOP for backups.
3. Check the SOP for the frequency at which directory data is backed up. Alternatively, physically verify that backups are being performed.
4. If the directory data for a MAC III system is not backed up at least weekly, then this is a finding.
5. If the directory data for a MAC I or II system is not backed up at least daily, then this is a finding.DSRM Password Change Policy<GroupDescription></GroupDescription>AD.0151The Directory Service Restore Mode (DSRM) password must be changed at least annually. <VulnDiscussion>This is a tremendously powerful password which should be changed periodically. This password is unique to each DC and is used to logon to a DC when rebooting into the server recovery mode. With a weak or known password, anyone with local access to the DC can reboot this machine, copy or modify the Active Directory database, and reboot the server without leaving any trace of the activity.
Failure to change the DSRM password periodically could allow a compromised resource (maliciously or through personnel turnover) to go undetected for an extended period. Failure to change the DSRM password could 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>Information Assurance Manager</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Create or implement a local site policy to change the DSRM password at least yearly. 1. Interview the IAM.
2. Obtain a copy of the site’s policy that addresses password change frequency.
3. Check that the policy addresses the requirement for the DSRM password to be changed at least yearly. Alternatively review logs or other evidence that indicates that the password has been changed within the last year.
Note that there is no known method to check password age online while the server is active as a domain controller.
4. If there is no policy for changing the DSRM password at least yearly or no indication that it has been changed within the last year, then this is a finding.Review of Hosting Domain and Forest<GroupDescription></GroupDescription>AD.9100Security vulnerability reviews of the domain and/or forest in which the domain controller resides must be conducted at least annually.
<VulnDiscussion>An AD domain controller is impacted by the AD environment created by the security configuration of the domain and forest in which the domain controller resides. A proper review of the AD environment requires checks at the domain controller, domain, and forest level. If the domain or forest-level checks are not performed at the same time or within a reasonable time frame, the domain controller may be at risk from non-secure settings at those levels.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Perform reviews of the domain and/or forest in which the domain controller resides at least annually. 1. Verify that the domain and forest in which the domain controller resides have been reviewed using the requirements in the appropriate document in the Active Directory STIG.
2. The security assessment must be conducted at the same time or no more than 1 year prior to the review of the domain controller.
3. VMS asset information, dated reports, or other documentation can be used to provide verification.
4. If it is not possible to verify that the domain and forest have been reviewed, then this is a finding.Replication in the DMZ (RODC)<GroupDescription></GroupDescription>AD.0270Read-only Domain Controller (RODC) architecture and configuration must comply with directory services requirements.<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>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain8701. Ensure compliance with VPN and IPSec requirements in the Network Insfrastucture STIG.
2. Ensure IPSec and other communications and security configurations for the management and replication of the RODC uses the minimum required Group Policy Objects (GPOs) to provide the required functionality.
3. Replicate only the information needed to provide the functionality required. If full replication of all directory data is not needed, then replicated selective ID and authentication information as needed to the RODC.
4. Include an inspection of the RODC server in the DMZ when inspection for least privilege.1. Verify that the site has applied the Network Infrastucture STIG to configure the VPN and IPSec.
2. Verify that IPSec and other communications and security configurations for the management and replication of the RODC will be managed by use of the minimum required Group Policy Objects (GPOs).
3. Include an inspection of the RODC server in the DMZ when inspection for least privilege.
4. Verify that required patches and compatibility packs are installed if RODC is used with Windows 2003 (or earlier) clients.
5. If RODC server and configuration does not comply with requirements, then this is a finding.Enterprise Admins Group Members<GroupDescription></GroupDescription>AD.0001Membership to the Enterprise Admins group must be restricted to accounts used only to manage the Active Directory Forest.<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>ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Create the necessary documentation that identifies the members of the Enterprise Admins group. Ensure that each member has a separate unique account that can only be used to manage the Active Directory Forest. Remove any Enterprise Admin accounts from other administrator groups.Review the Enterprise Admins group in Active Directory Users and Computers. Any accounts that are members of the Enterprise Admins group must be documented with the IAO. Each Enterprise Administrator must have a separate unique account specifically for managing the Active Directory forest.
If any account listed in the Enterprise Admins group is a member of other administrator groups including the Domain Admins group, domain member server administrators groups, or domain workstation administrators groups, this is a finding.Domain Admins Group Members<GroupDescription></GroupDescription>AD.0002Membership to the Domain Admins group must be restricted to accounts used only to manage the Active Directory domain and domain controllers.<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>ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Create the necessary documentation that identifies the members of the Domain Admins group. Ensure that each member has a separate unique account that can only be used to manage the Active Directory domain and domain controllers. Remove any Domain Admin accounts from other administrator groups.Review the Domain Admins group in Active Directory Users and Computers. Any accounts that are members of the Domain Admins group must be documented with the IAO. Each Domain Administrator must have a separate unique account specifically for managing the Active Directory domain and domain controllers.
If any account listed in the Domain Admins group is a member of other administrator groups including the Enterprise Admins group, domain member server administrators groups, or domain workstation administrators groups, this is a finding.Domain Member Server Administrators Group Members<GroupDescription></GroupDescription>AD.0003Administrators must have separate accounts specifically for managing domain member servers.<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>ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Create the necessary documentation that identifies the members of domain member server administrator groups. Ensure that each member has a separate unique account that can only be used to manage domain member servers. Remove any domain member server accounts from other administrator groups.Review the membership groups in Active Directory Users and Computers. Membership groups must be designated at the domain level specifically for domain member server administrators. Domain member server administrator groups and any accounts that are members of the groups must be documented with the IAO. Each member server administrator must have a separate unique account specifically for managing member servers.
If any account listed in a domain member server administrator group is a member of other administrator groups including the Enterprise Admins group, the Domain Admins group, or domain workstation administrator groups, this is a finding.Domain Workstation Administrators Group Members<GroupDescription></GroupDescription>AD.0004Administrators must have separate accounts specifically for managing domain workstations.<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>ECPA-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Create the necessary documentation that identifies the members of domain workstation administrator groups. Ensure that each member has a separate unique account that can only be used to manage domain workstations. Remove any domain workstation administrator accounts from other administrator groups.Review the membership groups in Active Directory Users and Computers. Membership groups must be designated at the domain level specifically for domain workstation administrators. Domain workstation administrator groups and any accounts that are members of the groups must be documented with the IAO. Each domain workstation administrator must have a separate unique account specifically for managing domain workstations.
If any account listed in a domain workstation administrator group is a member of other administrator groups including the Enterprise Admins group, the Domain Admins group, or domain member server administrator groups, this is a finding.Delegation of Privileged Accounts<GroupDescription></GroupDescription>AD.0005Delegation of privileged accounts must be prohibited.<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>ECLP-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Open Active Directory Users and Computers. View the properties of all privileged accounts. Under the Account tab, select "Account is sensitive and cannot be delegated" in the Account Options section.Review the properties of all privileged accounts in Active Directory Users and Computers. Under the Account tab, verify "Account is sensitive and cannot be delegated" is selected in the Account Options section. If delegation is not prohibited for any privileged account, this is a finding.Dedicated Systems for Managing Active Directory<GroupDescription></GroupDescription>AD.0006Only systems dedicated for the sole purpose of managing Active Directory must be used to manage Active Directory remotely.<VulnDiscussion>Only domain systems used exclusively to manage Active Directory must be used to manage Active Directory remotely. Dedicating domain systems to be used solely for managing Active Directory will aid in protecting privileged domain accounts from being compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECSC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Set aside domain systems to manage Active Directory remotely. Ensure they are used only for the purpose of managing Active Directory. Otherwise, use the local domain controller console to manage Active Directory.Verify that any domain systems used to manage Active Directory remotely are used exclusively for managing Active Directory. If domain systems used for managing Active Directory are used for additional functions, this is a finding.
If Active Directory is managed with local logons to domain controllers, not remotely, this can be marked NA.Block Internet Access for Dedicated Systems Used for Managing Active Directory <GroupDescription></GroupDescription>AD.0007Dedicated systems used for managing Active Directory remotely must be blocked from Internet Access.<VulnDiscussion>A system used to manage Active Directory provides access to highly privileged areas of a domain. Such a system with Internet access may be exposed to numerous attacks and compromise the domain. Restricting Internet access for dedicated systems used to manage Active Directory will aid in protecting privileged domain accounts from being compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECSC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Block Internet access for systems dedicated to managing Active Directory. This can be accomplished by restrictions at boundary firewalls, proxy services, with the Windows Firewall or other methods.Verify access to the internet is prevented for systems dedicated to managing Active Directory. Various methods may be employed to accomplish this, such as restrictions at boundary firewalls, through proxy services, or with the Windows Firewall.
Review the Internet access restrictions with the administrator. If Internet access is not prevented, this is a finding.Unique Passwords for all Local Administrator Accounts<GroupDescription></GroupDescription>AD.0008Local administrator accounts on domain systems must not share the same password.<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>ECSC-1</IAControls>VMS Target Active Directory DomainDISA FSOVMS TargetActive Directory Domain870Set unique passwords for all local administrator accounts on domain systems.Verify local administrator accounts on domain systems are using unique passwords. If local administrator accounts on domain systems are sharing a password, this is a finding.