Active Directory Domain Security Technical Implementation Guide (STIG)

Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

Vuln ID:
V-8521
Rule ID:
SV-9018r3_rule
Group ID:
Object Ownership Delegation
Version:
AD.0260
CCI:
CCI-000366
Severity:
Low
Description:
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.Information Assurance ManagerECLP-1, ECPA-1
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.Information Assurance ManagerECLP-1, ECPA-1
Check:
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.
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.
Fix:
1. 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. 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.
Vuln ID:
V-8522
Rule ID:
SV-30991r3_rule
Group ID:
Directory Service Inter-Enclave VPN Usage
Version:
DS00.1140_AD
CCI:
CCI-002418
Severity:
Medium
Description:
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.Information Assurance OfficerInformation Assurance ManagerDCPP-1
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.Information Assurance OfficerInformation Assurance ManagerDCPP-1
Check:
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.
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.
Fix:
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.
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.
Vuln ID:
V-8523
Rule ID:
SV-30994r3_rule
Group ID:
IDS Visibility of Directory VPN Data Transport
Version:
DS00.4140_AD
CCI:
CCI-000067
Severity:
Medium
Description:
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). Information Assurance OfficerEBVC-1
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). Information Assurance OfficerEBVC-1
Check:
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.
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.
Fix:
Replace the VPN solution or reconfigure it so that directory data is inspected by a network or host-based IDS.
Replace the VPN solution or reconfigure it so that directory data is inspected by a network or host-based IDS.
Vuln ID:
V-8524
Rule ID:
SV-30996r3_rule
Group ID:
Directory Service Availability
Version:
DS00.6140_AD
CCI:
CCI-000366
Severity:
Medium
Description:
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.Information Assurance OfficerCOTR-1
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.Information Assurance Officer
Check:
Determine the Availability categorization information for the domain. If the Availability categorization of the domain is low, this is NA. If the Availability categorization of the domain is moderate or high, verify the domain is supported by more than one domain controller. Start "Active Directory Users and Computers" (Available from various menus or run "dsa.msc"). Expand the left pane item that matches the domain being reviewed. Select the Domain Controllers Organizational Unit (OU) in the left pane. If there is only one domain controller in the OU, this is a finding.
Determine the Availability categorization information for the domain. If the Availability categorization of the domain is low, this is NA. If the Availability categorization of the domain is moderate or high, verify the domain is supported by more than one domain controller. Start "Active Directory Users and Computers" (Available from various menus or run "dsa.msc"). Expand the left pane item that matches the domain being reviewed. Select the Domain Controllers Organizational Unit (OU) in the left pane. If there is only one domain controller in the OU, this is a finding.
Fix:
Implement multiple domain controllers in domains with an Availability categorization of moderate or high.
Implement multiple domain controllers in domains with an Availability categorization of moderate or high.
Vuln ID:
V-8525
Rule ID:
SV-30995r4_rule
Group ID:
Directory Service Architecture DR Documentation
Version:
DS00.6120_AD
CCI:
CCI-000366
Severity:
Low
Description:
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.Information Assurance OfficerCODP-1, CODP-2, CODP-3, COEF-1, COEF-2
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.Information Assurance Officer
Check:
Determine the Availability categorization information for the domain. If the Availability categorization of the domain is low, this is NA. If the Availability categorization of the domain is moderate or high, verify the organization's disaster recovery plans includes documentation on the AD hierarchy (forest, tree and domain structure). (A chart showing forest hierarchy and domain names is the minimum suggested.) If the disaster recovery plans do not include directory hierarchy information, this is a finding.
Determine the Availability categorization information for the domain. If the Availability categorization of the domain is low, this is NA. If the Availability categorization of the domain is moderate or high, verify the organization's disaster recovery plans includes documentation on the AD hierarchy (forest, tree and domain structure). (A chart showing forest hierarchy and domain names is the minimum suggested.) If the disaster recovery plans do not include directory hierarchy information, this is a finding.
Fix:
Update the disaster recovery plans to include the AD hierarchy structure for domains with an Availability categorization of moderate or high.
Update the disaster recovery plans to include the AD hierarchy structure for domains with an Availability categorization of moderate or high.
Vuln ID:
V-8526
Rule ID:
SV-31214r2_rule
Group ID:
Cross-Directory Authentication INFOCON Procedures
Version:
DS00.7100_AD
CCI:
CCI-000366
Severity:
Low
Description:
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.Information Assurance OfficerVIIR-1, VIIR-2
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.Information Assurance OfficerVIIR-1, VIIR-2
Check:
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.
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.
Fix:
Evaluate 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.
Evaluate 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.
Vuln ID:
V-8530
Rule ID:
SV-30989r3_rule
Group ID:
Cross-Directory Authentication Documentation
Version:
DS00.1120_AD
CCI:
CCI-000366
Severity:
Low
Description:
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.Information Assurance OfficerDCID-1
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.Information Assurance Officer
Check:
Start "Active Directory Domains and Trusts" (Available from various menus or run "domain.msc"). Select the left pane item that matches the name of the domain being reviewed. Right-click the domain name and select "Properties". Select the "Trusts" tab. 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.) Compare the list of trusts identified with documentation maintained by the ISSO. For each trust, the documentation must contain the following: Type (external, forest, or realm) Name of the other party Confidentiality, Availability, and Integrity categorization Classification level of the other party Trust direction (inbound and/or outbound) Transitivity Status of the Selective Authentication option Status of the SID filtering option If an identified trust is not listed in the documentation or if any of the required items are not documented, this is a finding.
Start "Active Directory Domains and Trusts" (Available from various menus or run "domain.msc"). Select the left pane item that matches the name of the domain being reviewed. Right-click the domain name and select "Properties". Select the "Trusts" tab. 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.) Compare the list of trusts identified with documentation maintained by the ISSO. For each trust, the documentation must contain the following: Type (external, forest, or realm) Name of the other party Confidentiality, Availability, and Integrity categorization Classification level of the other party Trust direction (inbound and/or outbound) Transitivity Status of the Selective Authentication option Status of the SID filtering option If an identified trust is not listed in the documentation or if any of the required items are not documented, this is a finding.
Fix:
Develop documentation for each AD external, forest, and realm trust configuration. At a minimum this must include: Type (external, forest, or realm) Name of the other party Confidentiality, Availability, and Integrity categorization Classification level of the other party Trust direction (inbound and/or outbound) Transitivity Status of the Selective Authentication option Status of the SID filtering option
Develop documentation for each AD external, forest, and realm trust configuration. At a minimum this must include: Type (external, forest, or realm) Name of the other party Confidentiality, Availability, and Integrity categorization Classification level of the other party Trust direction (inbound and/or outbound) Transitivity Status of the Selective Authentication option Status of the SID filtering option
Vuln ID:
V-8533
Rule ID:
SV-9030r2_rule
Group ID:
Trusts - document need
Version:
AD.0170
CCI:
CCI-000366
Severity:
Medium
Description:
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.Information Assurance OfficerECAN-1
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.Information Assurance OfficerECAN-1
Check:
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.
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.
Fix:
Delete the unneeded trust relationship or document the access requirement or mission need for the trust.
Delete the unneeded trust relationship or document the access requirement or mission need for the trust.
Vuln ID:
V-8534
Rule ID:
SV-9031r2_rule
Group ID:
Trust - Classification Levels
Version:
AD.0180
CCI:
CCI-000366
Severity:
High
Description:
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.)Information Assurance OfficerECIC-1
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.)Information Assurance OfficerECIC-1
Check:
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.
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.
Fix:
Delete the trust relationship that is defined between entities with resources at different DoD classification levels.
Delete the trust relationship that is defined between entities with resources at different DoD classification levels.
Vuln ID:
V-8536
Rule ID:
SV-9033r2_rule
Group ID:
Trust - Non-DoD
Version:
AD.0181
CCI:
CCI-000366
Severity:
High
Description:
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.Information Assurance OfficerECIC-1
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.Information Assurance OfficerECIC-1
Check:
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.
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.
Fix:
Obtain 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.
Obtain 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.
Vuln ID:
V-8538
Rule ID:
SV-9035r3_rule
Group ID:
Trust - SID Filter Quarantining
Version:
AD.0190
CCI:
CCI-000764
Severity:
Medium
Description:
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.Information Assurance OfficerECAN-1, ECCD-1, ECCD-2
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.Information Assurance Officer
Check:
Open "Active Directory Domains and Trusts". (Available from various menus or run "domain.msc".) Right click the domain in the left pane and select Properties. Select the Trusts tab. Note any existing trusts and the type. If no trusts exist, this is NA. If the trust type is External, run the following command on the trusting domain: "netdom trust <trusting domain> /d:<trusted domain> /quarantine" If the result does not specify "SID filtering is enabled for this trust. Only SIDs from the trusted domain will be accepted for authorization data returned during authentication. SIDs from other domains will be removed.", this is a finding. If the trust type is Forest, run the following command on the trusting domain: "netdom trust <trusting domain> /d:<trusted domain> /enablesidhistory" If the result does not specify "SID history is disabled for this trust", this is a finding.
Open "Active Directory Domains and Trusts". (Available from various menus or run "domain.msc".) Right click the domain in the left pane and select Properties. Select the Trusts tab. Note any existing trusts and the type. If no trusts exist, this is NA. If the trust type is External, run the following command on the trusting domain: "netdom trust <trusting domain> /d:<trusted domain> /quarantine" If the result does not specify "SID filtering is enabled for this trust. Only SIDs from the trusted domain will be accepted for authorization data returned during authentication. SIDs from other domains will be removed.", this is a finding. If the trust type is Forest, run the following command on the trusting domain: "netdom trust <trusting domain> /d:<trusted domain> /enablesidhistory" If the result does not specify "SID history is disabled for this trust", this is a finding.
Fix:
Ensure SID filtering is enabled on all external trusts. You can enable SID filtering 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> Ensure SID history is disabled for all forest trusts. You can disable SID history only from the trusting side of the trust. Enter the following line from a command line: netdom trust <TrustingDomainName> /d:<TrustedDomainName> /enablesidhistory:No /usero:<DomainAdministratorAcct> /passwordo:<DomainAdminPwd>
Ensure SID filtering is enabled on all external trusts. You can enable SID filtering 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> Ensure SID history is disabled for all forest trusts. You can disable SID history only from the trusting side of the trust. Enter the following line from a command line: netdom trust <TrustingDomainName> /d:<TrustedDomainName> /enablesidhistory:No /usero:<DomainAdministratorAcct> /passwordo:<DomainAdminPwd>
Vuln ID:
V-8540
Rule ID:
SV-9037r3_rule
Group ID:
Trust - Selective Authentication
Version:
AD.0200
CCI:
CCI-000213
Severity:
Medium
Description:
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.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.Information Assurance OfficerECAN-1, ECCD-1, ECCD-2
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.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.Information Assurance Officer
Check:
Open "Active Directory Domains and Trusts". (Available from various menus or run "domain.msc".) Right click the domain name in the left pane and select "Properties". Select the "Trusts" tab. For each outgoing forest trust, right-click the trust item and select "Properties". Select the "Authentication" tab. If the "Selective Authentication" option is not selected on every outgoing forest trust, this is a finding.
Open "Active Directory Domains and Trusts". (Available from various menus or run "domain.msc".) Right click the domain name in the left pane and select "Properties". Select the "Trusts" tab. For each outgoing forest trust, right-click the trust item and select "Properties". Select the "Authentication" tab. If the "Selective Authentication" option is not selected on every outgoing forest trust, this is a finding.
Fix:
Enable Selective Authentication on outgoing forest trust. Open "Active Directory Domains and Trusts". (Available from various menus or run "domain.msc".) Right click the domain name in the left pane and select "Properties". Select the "Trusts" tab. For each outgoing forest trust, right-click the trust item and select "Properties". Select the "Authentication" tab. Select the "Selective Authentication" option. (It may be necessary to configure the "Allowed to Authenticate" permission on resources in the trusting domain.)
Enable Selective Authentication on outgoing forest trust. Open "Active Directory Domains and Trusts". (Available from various menus or run "domain.msc".) Right click the domain name in the left pane and select "Properties". Select the "Trusts" tab. For each outgoing forest trust, right-click the trust item and select "Properties". Select the "Authentication" tab. Select the "Selective Authentication" option. (It may be necessary to configure the "Allowed to Authenticate" permission on resources in the trusting domain.)
Vuln ID:
V-8547
Rule ID:
SV-9044r3_rule
Group ID:
Pre-Windows 2000 Compatible Access Group
Version:
AD.0220
CCI:
CCI-000804
Severity:
Medium
Description:
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.System AdministratorInformation Assurance OfficerECAN-1, ECCD-1, ECCD-2
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.System AdministratorInformation Assurance Officer
Check:
Open "Active Directory Users and Computers" (available from various menus or run "dsa.msc"). Expand the domain being reviewed in the left pane and select the "Builtin" container. Double-click on the "Pre-Windows 2000 Compatible Access" group in the right pane. Select the "Members" tab. If the "Anonymous Logon" or "Everyone" groups are members, this is a finding. (By default, these groups are not included in current Windows versions.)
Open "Active Directory Users and Computers" (available from various menus or run "dsa.msc"). Expand the domain being reviewed in the left pane and select the "Builtin" container. Double-click on the "Pre-Windows 2000 Compatible Access" group in the right pane. Select the "Members" tab. If the "Anonymous Logon" or "Everyone" groups are members, this is a finding. (By default, these groups are not included in current Windows versions.)
Fix:
Ensure the "Anonymous Logon" and "Everyone" groups are not members of the "Pre-Windows 2000 Compatible Access group". (By default, these groups are not included in current Windows versions.) Open "Active Directory Users and Computers" (available from various menus or run "dsa.msc"). Expand the domain being reviewed in the left pane and select the "Builtin" container. Double-click on the "Pre-Windows 2000 Compatible Access" group in the right pane. Select the "Members" tab. If the "Anonymous Logon" or "Everyone" groups are members, select each and click "Remove".
Ensure the "Anonymous Logon" and "Everyone" groups are not members of the "Pre-Windows 2000 Compatible Access group". (By default, these groups are not included in current Windows versions.) Open "Active Directory Users and Computers" (available from various menus or run "dsa.msc"). Expand the domain being reviewed in the left pane and select the "Builtin" container. Double-click on the "Pre-Windows 2000 Compatible Access" group in the right pane. Select the "Members" tab. If the "Anonymous Logon" or "Everyone" groups are members, select each and click "Remove".
Vuln ID:
V-8548
Rule ID:
SV-9045r2_rule
Group ID:
Privileged Group Membership - Intra-Forest
Version:
AD.0240
CCI:
CCI-000366
Severity:
Medium
Description:
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.Information Assurance ManagerECLP-1, ECPA-1
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.Information Assurance Manager
Check:
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.
Start "Active Directory Users and Computers" (Available from various menus or run "dsa.msc"). Review the membership of the "Incoming Forest Trust Builders" group. Navigate to the "Built-in" container. Right-click on the "Incoming Forest Trust Builders", select "Properties" and then the "Members" tab. If any accounts are not documented as necessary with the ISSO, this is a finding. Review the membership of the "Group Policy Creator Owner" group. Navigate to the "Users" container. Right-click on the "Group Policy Creator Owner", select "Properties" and then the "Members" tab. If any accounts are not documented as necessary with the ISSO, this is a finding. It is possible to move some system-defined groups from their default locations. If a group is not in the location noted, review other containers to locate.
Fix:
Update 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.
Document membership of the Group Policy Creator Owners and Incoming Forest Trust Builders groups. Remove any accounts that do not require the privileges these groups assign.
Vuln ID:
V-8549
Rule ID:
SV-31557r2_rule
Group ID:
Privileged Group Membership - Cross-Directory
Version:
DS00.3200_AD
CCI:
CCI-000366
Severity:
Medium
Description:
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.System AdministratorInformation Assurance OfficerECLP-1, ECPA-1
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.System AdministratorInformation Assurance OfficerECLP-1, ECPA-1
Check:
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 “[email protected]”. 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.
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 “[email protected]”. 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.
Fix:
Remove 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.
Remove 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.
Vuln ID:
V-8551
Rule ID:
SV-9048r3_rule
Group ID:
Domain Functional Level
Version:
AD.0160
CCI:
CCI-000366
Severity:
Medium
Description:
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.System AdministratorInformation Assurance OfficerECSC-1
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.System AdministratorInformation Assurance Officer
Check:
Open "Active Directory Domains and Trusts" (run "domain.msc") or "Active Directory Users and Computers" (run "dsa.msc"). Right click in the left pane on the name of the Domain being reviewed. Select "Raise domain functional level…" The current domain functional level will be displayed (as well as the option to raise the domain functional level). Select "Cancel" to exit. Alternately, using PowerShell (Windows 2008 R2 or later). Select "Active Directory Module for Windows PowerShell", available in Administrative Tools or the Start Screen. Run "Get-ADDomain". View the value for "DomainMode:" If the current domain functional level is a Windows Server version no longer supported by Microsoft, this is a finding. Microsoft will no longer support Windows Server 2003 after 14 July 2015.
Open "Active Directory Domains and Trusts" (run "domain.msc") or "Active Directory Users and Computers" (run "dsa.msc"). Right click in the left pane on the name of the Domain being reviewed. Select "Raise domain functional level…" The current domain functional level will be displayed (as well as the option to raise the domain functional level). Select "Cancel" to exit. Alternately, using PowerShell (Windows 2008 R2 or later). Select "Active Directory Module for Windows PowerShell", available in Administrative Tools or the Start Screen. Run "Get-ADDomain". View the value for "DomainMode:" If the domain functional level is not Windows Server 2008 or later, this is a finding. Using the highest domain functional level supported by the domain controllers is recommended.
Fix:
Raise the domain functional level to a Windows Server version still supported by Microsoft. Microsoft will no longer support Windows Server 2003 after 14 July 2015. Raising the domain functional level needs to be carefully planned and implemented. This prevents the addition of domain controllers to the domain using Windows versions prior to the current domain functional level. See Microsoft documentation for the process and requirements of raising the domain functional level.
Raise the domain functional level to Windows Server 2008 or later. Using the highest domain functional level supported by the domain controllers is recommended. Raising the domain functional level needs to be carefully planned and implemented. This prevents the addition of domain controllers to the domain using Windows versions prior to the current domain functional level. See Microsoft documentation for the process and requirements of raising the domain functional level.
Vuln ID:
V-8553
Rule ID:
SV-30992r3_rule
Group ID:
Replication Schedule
Version:
DS00.3230_AD
CCI:
CCI-000366
Severity:
Medium
Description:
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.System AdministratorInformation Assurance OfficerECAN-1, ECCD-1, ECCD-2
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.System AdministratorInformation Assurance Officer
Check:
Open "Active Directory Sites and Services". (Available from various menus or run "dssite.msc".) Expand "Sites" in the left pane. If only a single site exists, this is NA. By default the first site in a domain is named "Default-First-Site-Name" but may have been changed. If more than one site exists, expand "Inter-Site Transports" and select "IP". For each site link that is defined in the right pane perform the following: Right click the site link item and select "Properties". If the interval on the "General" tab for the "Replicate every" field is greater than "1440", this is a finding. Click the "Change Schedule" button. If the time frames selected for "Replication Available" do not allow for replication to occur at least daily, this is a finding. Click the Cancel buttons to exit.
Open "Active Directory Sites and Services". (Available from various menus or run "dssite.msc".) Expand "Sites" in the left pane. If only a single site exists, this is NA. By default the first site in a domain is named "Default-First-Site-Name" but may have been changed. If more than one site exists, expand "Inter-Site Transports" and select "IP". For each site link that is defined in the right pane perform the following: Right click the site link item and select "Properties". If the interval on the "General" tab for the "Replicate every" field is greater than "1440", this is a finding. Click the "Change Schedule" button. If the time frames selected for "Replication Available" do not allow for replication to occur at least daily, this is a finding. Click the Cancel buttons to exit.
Fix:
Maintain an Active Directory replication schedule that allows inter-site replication to occur at least on a daily basis. Open "Active Directory Sites and Services". (Available from various menus or run "dssite.msc".) Expand "Sites" in the left pane. Expand "Inter-Site Transports" and select "IP". For each site link that is defined in the right pane perform the following: Right click the site link item and select "Properties". Select an interval in the "Replicate every" field less than "1440". (By default this is 180.) Click the Change Schedule button. Select time frames for "Replication Available" to allow for replication to occur at least daily.
Maintain an Active Directory replication schedule that allows inter-site replication to occur at least on a daily basis. Open "Active Directory Sites and Services". (Available from various menus or run "dssite.msc".) Expand "Sites" in the left pane. Expand "Inter-Site Transports" and select "IP". For each site link that is defined in the right pane perform the following: Right click the site link item and select "Properties". Select an interval in the "Replicate every" field less than "1440". (By default this is 180.) Click the Change Schedule button. Select time frames for "Replication Available" to allow for replication to occur at least daily.
Vuln ID:
V-25385
Rule ID:
SV-31547r3_rule
Group ID:
Directory Data Backup
Version:
DS00.0160_AD
CCI:
CCI-000366
Severity:
Medium
Description:
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. Information Assurance OfficerCODB-1, CODB-2, CODB-3
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. Information Assurance Officer
Check:
Review the organization's procedures for the backing up active directory data. Verify the frequency at which active directory data is backed up. If the Availability categorization of the domain is low, this must be at least weekly. If the Availability categorization of the domain is moderate or high, this must be at least daily. Verify the type of backup is appropriate to capturing the directory data. For AD domain controllers, this must include a System State data backup. If any of these conditions are not met, this is a finding.
Review the organization's procedures for the backing up active directory data. Verify the frequency at which active directory data is backed up. If the Availability categorization of the domain is low, this must be at least weekly. If the Availability categorization of the domain is moderate or high, this must be at least daily. Verify the type of backup is appropriate to capturing the directory data. For AD domain controllers, this must include a System State data backup. If any of these conditions are not met, this is a finding.
Fix:
Update the organization's procedures for the backing up active directory data. Ensure the frequency at which active directory data is backed up is as follows: If the Availability categorization of the domain is low, this must be at least weekly. If the Availability categorization of the domain is moderate or high, this must be at least daily. Ensure the type of backup is appropriate to capturing the directory data. For AD domain controllers, this must include a System State data backup.
Update the organization's procedures for the backing up active directory data. Ensure the frequency at which active directory data is backed up is as follows: If the Availability categorization of the domain is low, this must be at least weekly. If the Availability categorization of the domain is moderate or high, this must be at least daily. Ensure the type of backup is appropriate to capturing the directory data. For AD domain controllers, this must include a System State data backup.
Vuln ID:
V-25840
Rule ID:
SV-32179r2_rule
Group ID:
DSRM Password Change Policy
Version:
AD.0151
CCI:
CCI-000366
Severity:
Medium
Description:
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.Information Assurance ManagerIAIA-1, IAIA-2
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.Information Assurance Manager
Check:
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.
Verify the organization has a process that addresses DSRM password change frequency. If DSRM passwords are not changed at least annually, this is a finding.
Fix:
Create or implement a local site policy to change the DSRM password at least yearly.
Change the DSRM password at least annually.
Vuln ID:
V-25841
Rule ID:
SV-32180r2_rule
Group ID:
Review of Hosting Domain and Forest
Version:
AD.9100
CCI:
CCI-000366
Severity:
Low
Description:
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.Information Assurance OfficerECSC-1
Check:
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.
Fix:
Perform reviews of the domain and/or forest in which the domain controller resides at least annually.
Vuln ID:
V-25997
Rule ID:
SV-32648r2_rule
Group ID:
Replication in the DMZ (RODC)
Version:
AD.0270
CCI:
CCI-000366
Severity:
Medium
Description:
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.Information Assurance OfficerECSC-1
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.Information Assurance OfficerECSC-1
Check:
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.
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.
Fix:
1. 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. 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.
Vuln ID:
V-36431
Rule ID:
SV-47837r2_rule
Group ID:
Enterprise Admins Group Members
Version:
AD.0001
CCI:
CCI-000366
Severity:
High
Description:
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.ECPA-1
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.ECPA-1
Check:
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.
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.
Fix:
Create 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.
Create 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.
Vuln ID:
V-36432
Rule ID:
SV-47838r2_rule
Group ID:
Domain Admins Group Members
Version:
AD.0002
CCI:
CCI-000366
Severity:
High
Description:
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.ECPA-1
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.ECPA-1
Check:
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.
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.
Fix:
Create 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.
Create 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.
Vuln ID:
V-36433
Rule ID:
SV-47839r2_rule
Group ID:
Domain Member Server Administrators Group Members
Version:
AD.0003
CCI:
CCI-000366
Severity:
Medium
Description:
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.ECPA-1
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.ECPA-1
Check:
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.
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.
Fix:
Create 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.
Create 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.
Vuln ID:
V-36434
Rule ID:
SV-47840r2_rule
Group ID:
Domain Workstation Administrators Group Members
Version:
AD.0004
CCI:
CCI-000366
Severity:
Medium
Description:
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.ECPA-1
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.
Check:
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.
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.
Fix:
Create 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.
Create 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.
Vuln ID:
V-36435
Rule ID:
SV-47841r2_rule
Group ID:
Delegation of Privileged Accounts
Version:
AD.0005
CCI:
CCI-000366
Severity:
High
Description:
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.ECLP-1
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.ECLP-1
Check:
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.
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.
Fix:
Open 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.
Open 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.
Vuln ID:
V-36436
Rule ID:
SV-47842r4_rule
Group ID:
Dedicated Systems for Managing Active Directory
Version:
AD.MP.0001
CCI:
CCI-001082
Severity:
Medium
Description:
Only domain systems used exclusively to manage Active Directory (referred to as AD admin platforms) 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. This includes the management of Active Directory itself and the Domain Controllers (DCs) that run Active Directory, including such activities as domain level user and computer management, administering trusts, replication, schema changes, site topology, domain-wide group policy, the addition of new DCs, DC software installation, and DC backups and restore operations. Some maintenance activities may be delegated and do not require the use of an AD admin platform. These include non-domain level activities such as user and computer management as well as group policy maintenance in site defined organizational units. Accounts that have been delegated these activities must not be members of Domain or Enterprise Admin groups. These activities may still be performed with the use of an AD admin platform for the additional protections they provide.ECSC-1
Check:
If Active Directory is only managed with local logons to domain controllers, not remotely, this can be marked NA. 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. In situations where an additional physical machine dedicated to AD admin tasks is not practicable, virtual machines (VM) may be securely employed in either of the following configurations: -Windows 8, Windows Server 2012 or later for the AD admin management role. -Use local guest VMs running within Hyper-V for all other tasks to include admin roles on other servers as well as any user tasks such as web browsing or email. -Use a Type-1 Hypervisor with separate guest VMs for AD admin management roles and any other roles. In either case, the higher integrity AD admin platform and the lower integrity platforms must be separate. The AD admin platform must be configured not to forward the AD admin credentials to other guest VMs or to make the AD admin credentials available to other guest VMs. Additionally, guest VMs for user and less critical admin activities must apply the security requirements from the applicable STIG, especially so that AD admin accounts are denied all logon types.
Fix:
Set 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.
Vuln ID:
V-36437
Rule ID:
SV-47843r2_rule
Group ID:
Block Internet Access for Dedicated Systems Used for Managing Active Directory
Version:
AD.0007
CCI:
CCI-001084
Severity:
Medium
Description:
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.ECSC-1
Check:
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.
Fix:
Block 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.
Vuln ID:
V-36438
Rule ID:
SV-47844r3_rule
Group ID:
Unique Passwords for all Local Administrator Accounts
Version:
AD.0008
CCI:
CCI-001941
Severity:
Medium
Description:
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.ECSC-1
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.
Check:
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. Microsoft's Local Administrator Password Solution (LAPS) provides an automated solution for maintaining and regularly changing the local administrator password for domain-joined systems. Other automated solutions that provide this capability may also be used. If LAPS has been installed and enabled in the domain, the following PowerShell query will return a list of systems that do not have a local administrator password managed by LAPS. (The LAPS PowerShell module requires PowerShell 2.0 or higher and .NET Framework 4.0.) Start PowerShell. If the LAPS PowerShell module has not been previously imported, execute the following first: "Import-Module AdmPwd.ps". Execute "Get-PwdAdmPassword -ComputerName * | Where-object {$_.password -eq $null}" If any systems are listed, this is a finding. Ignore computers with "OU=Domain Controllers" in the DistinguishedName field.
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. Microsoft's Local Administrator Password Solution (LAPS) provides an automated solution for maintaining and regularly changing a local administrator password for domain-joined systems. LAPS can manage a single local administrator account. The default is the built-in administrator account however it can be configured to manage an administrator account of a different name. If additional local administrator accounts exist across systems, the organization must have a process to require unique passwords on each system for the additional accounts. Other automated solutions that provide this capability may also be used. If LAPS has been installed and enabled in the domain, the following PowerShell query will return a list of systems that do not have a local administrator password managed by LAPS. (The LAPS PowerShell module requires PowerShell 2.0 or higher and .NET Framework 4.0.) Open "Windows PowerShell". If the LAPS PowerShell module has not been previously imported, execute the following first: "Import-Module AdmPwd.ps". Execute "Get-AdmPwdPassword -ComputerName * | Where-object {$_.password -eq $null}" Review the returned list for validity. Exclude computers with "OU=Domain Controllers" in the DistinguishedName field. Other possible exceptions include but are not limited to non-Windows computers in Active Directory. If any active/deployed Windows systems that are not managed by another process to ensure unique passwords for local administrator accounts are listed, this is a finding. If the query fails, the organization must demonstrate that passwords for local administrator accounts are properly managed to ensure unique passwords for each. If not, this is a finding.
Fix:
Set unique passwords for all local administrator accounts on domain systems. Microsoft's Local Administrator Password Solution (LAPS) provides an automated solution for maintaining and regularly changing the local administrator password for domain-joined systems. Other automated solutions that provide this capability may also be used. See Microsoft Security Advisory 3062591 for additional information and download of LAPS. https://technet.microsoft.com/en-us/library/security/3062591.aspx
Set unique passwords for all local administrator accounts on domain systems. Microsoft's Local Administrator Password Solution (LAPS) provides an automated solution for maintaining and regularly changing a local administrator password for domain-joined systems. If additional local administrator accounts exist across systems, the organization must have a process to require unique passwords on each system for the additional accounts. Other automated solutions that provide this capability may also be used. See Microsoft Security Advisory 3062591 for additional information and download of LAPS. https://technet.microsoft.com/en-us/library/security/3062591.aspx
Vuln ID:
V-43648
Rule ID:
SV-56469r2_rule
Group ID:
AD.0009
Version:
AD.0009
CCI:
CCI-000366
Severity:
Medium
Description:
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. IAIA-1
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. IAIA-1
Check:
Verify separate smart cards are used for EA and DA accounts from smart cards used for other accounts. EA and DA accounts may be on the same smart card but must be separate from any other accounts. If separate smart cards for EA and DA accounts from other accounts are not used, this is a finding.
Verify separate smart cards are used for EA and DA accounts from smart cards used for other accounts. EA and DA accounts may be on the same smart card but must be separate from any other accounts. If separate smart cards for EA and DA accounts from other accounts are not used, this is a finding.
Fix:
Use separate smart cards for EA and DA accounts from smart cards used for other accounts. EA and DA accounts may be on the same smart card but must be separate from any other accounts.
Use separate smart cards for EA and DA accounts from smart cards used for other accounts. EA and DA accounts may be on the same smart card but must be separate from any other accounts.
Vuln ID:
V-43649
Rule ID:
SV-56470r2_rule
Group ID:
AD.0010
Version:
AD.0010
CCI:
CCI-000199
Severity:
Medium
Description:
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 re-enabling the "Smart card is required for interactive logon" replaces the NT hash of the account with a newly randomized hash. Otherwise, the existing NT hash could be re-used for Pass-the-Hash in the future.IAIA-1
Check:
Verify "Smart card is required for interactive logon" is disabled and re-enabled for all smart card required EA and DA accounts at least every 60 days. If the setting "Smart card is required for interactive logon" is not disabled then re-enabled for all EA and DA accounts that require smart card logons at least every 60 days, this is a finding.
Fix:
Disable then re-enable "Smart card is required for interactive logon" for all smart card required EA and DA accounts at least every 60 days.
Vuln ID:
V-43650
Rule ID:
SV-56471r2_rule
Group ID:
AD.0011
Version:
AD.0011
CCI:
CCI-000199
Severity:
Medium
Description:
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 re-enabling the "Smart card is required for interactive logon" replaces the NT hash of the account with a newly randomized hash. Otherwise, the existing NT hash could be re-used for Pass-the-Hash in the future. Critical servers are any servers that provide functions that would significantly degrade mission effectiveness if disrupted, altered, or leaked. Examples include email, collaboration (e.g., SharePoint), virtualization, configuration management, file sharing, and backup servers. IAIA-1
Check:
Verify "Smart card is required for interactive logon" is disabled and re-enabled for all smart card required administrative accounts associated with critical servers at least every 60 days. If the setting "Smart card is required for interactive logon" is not disabled then re-enabled for all critical server administrative accounts that require smart card logons at least every 60 days, this is a finding.
Fix:
Disable then re-enable "Smart card is required for interactive logon" for all smart card required critical server administrative accounts at least every 60 days.
Vuln ID:
V-43651
Rule ID:
SV-56472r2_rule
Group ID:
AD.0012
Version:
AD.0012
CCI:
CCI-000199
Severity:
Medium
Description:
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 re-enabling the "Smart card is required for interactive logon" replaces the NT hash of the account with a newly randomized hash. Otherwise, the existing NT hash could be re-used for Pass-the-Hash in the future.IAIA-1
Check:
Verify "Smart card is required for interactive logon" is disabled and re-enabled for all smart card required other important accounts (VIPS and other administrators) at least every 60 days. If the setting "Smart card is required for interactive logon" is not disabled then re-enabled for other important accounts (VIPS and other administrators) that require smart card logons at least every 60 days, this is a finding.
Fix:
Disable then re-enable "Smart card is required for interactive logon" for all smart card required other important accounts (VIPS and other administrators) at least every 60 days.
Vuln ID:
V-43652
Rule ID:
SV-56473r2_rule
Group ID:
AD.0013
Version:
AD.0013
CCI:
CCI-000366
Severity:
Medium
Description:
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.IAIA-1
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.IAIA-1
Check:
If the domain does not have any public facing servers, this is NA. Review the local Administrators group on public facing servers. Only the appropriate administrator groups or accounts responsible for administration of the system may be members of the group. For public facing servers, the Domain Admins group must be replaced by a domain member server administrator group whose members are different from any used to manage internal servers. If any domain accounts or groups used to manage internal servers are members of the local administrators group, this is a finding.
If the domain does not have any public facing servers, this is NA. Review the local Administrators group on public facing servers. Only the appropriate administrator groups or accounts responsible for administration of the system may be members of the group. For public facing servers, the Domain Admins group must be replaced by a domain member server administrator group whose members are different from any used to manage internal servers. If any domain accounts or groups used to manage internal servers are members of the local administrators group, this is a finding.
Fix:
If the domain does not have any public facing servers, this is NA. Configure the system to include only administrator groups or accounts that are responsible for the system in the local Administrators group. For public facing servers, replace the Domain Admins group with a domain member server administrator group whose members are different from any used to manage internal servers.
If the domain does not have any public facing servers, this is NA. Configure the system to include only administrator groups or accounts that are responsible for the system in the local Administrators group. For public facing servers, replace the Domain Admins group with a domain member server administrator group whose members are different from any used to manage internal servers.
Vuln ID:
V-43710
Rule ID:
SV-56531r2_rule
Group ID:
AD.MP.0002
Version:
AD.MP.0002
CCI:
CCI-000366
Severity:
Medium
Description:
AD admin platforms are used for highly privileged activities. The later versions of Windows offer significant security improvements over earlier versions of Windows. Windows 8.1 and Windows Server 2012 R2, or later, are preferred as they offer even better credential protections.ECSC-1
Check:
Verify the operating system version on AD admin platforms is at least Windows 7, Windows Server 2008 R2, or later. If the operating system is an earlier version, this is a finding.
Fix:
Use Windows 7, Windows Server 2008 R2, or later as the operating system for all AD admin platforms.
Vuln ID:
V-43711
Rule ID:
SV-56532r2_rule
Group ID:
AD.MP.0003
Version:
AD.MP.0003
CCI:
CCI-000366
Severity:
Medium
Description:
AD admin platforms are used for highly privileged activities. The accounts that have administrative privileges on AD admin platforms must not be used on or used to manage any non-AD admin platforms. Otherwise, there would be a clear path for privilege escalation to EA/DA privileges. Where practicable, dedicated domain accounts that are used to manage AD admin platforms should be utilized, but otherwise Enterprise Admin (EA)/Domain Admin (DA) accounts may be used to manage AD admin platforms.ECPA-1
Check:
Review the local Administrators group of AD admin platforms. Verify separate domain administrative accounts are used to manage AD admin platforms from non-AD admin platforms. These should be dedicated domain accounts where practicable. Otherwise EA/DA accounts may be used. If accounts used to manage AD admin platforms are used for any non-AD admin platforms, this is a finding.
Fix:
Use separate domain administrative accounts to manage AD admin platforms from non-AD admin platforms. These should be dedicated domain accounts where practicable. Otherwise EA/DA accounts may be used.
Vuln ID:
V-43712
Rule ID:
SV-56533r3_rule
Group ID:
AD.AU.0001
Version:
AD.AU.0001
CCI:
CCI-000366
Severity:
Medium
Description:
Monitoring the usage of administrative accounts can alert on suspicious behavior and anomalous account usage that would be indicative of potential malicious credential reuse.ECAT-1
Monitoring the usage of administrative accounts can alert on suspicious behavior and anomalous account usage that would be indicative of potential malicious credential reuse.
Check:
Verify account usage events for administrative accounts are being monitored. This includes events related to approved administrative accounts as well as accounts being added to privileged groups such as Administrators, Domain and Enterprise Admins and other organization defined administrative groups. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below, at minimum. If these events are not monitored, this is a finding. Account Lockouts (Subcategory: User Account Management) 4740 - A user account is locked out. User Added to Privileged Group (Subcategory: Security Group Management) 4728 - A member was added to a security-enabled global group. 4732 - A member was added to a security-enabled local group. 4756 - A member was added to a security-enabled universal group. Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on. Account Login with Explicit Credentials (Subcategory: Logon) 4648 - A logon was attempted using explicit credentials.
Verify account usage events for administrative accounts are being monitored. This includes events related to approved administrative accounts as well as accounts being added to privileged groups such as Administrators, Domain and Enterprise Admins and other organization defined administrative groups. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below, at minimum. If these events are not monitored, this is a finding. Account Lockouts (Subcategory: User Account Management) 4740 - A user account is locked out. User Added to Privileged Group (Subcategory: Security Group Management) 4728 - A member was added to a security-enabled global group. 4732 - A member was added to a security-enabled local group. 4756 - A member was added to a security-enabled universal group. Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on. Account Login with Explicit Credentials (Subcategory: Logon) 4648 - A logon was attempted using explicit credentials.
Fix:
Monitor account usage events for administrative accounts. This includes events related to approved administrative accounts as well as accounts being added to privileged groups such as Administrators, Domain and Enterprise Admins and other organization defined administrative groups. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below, at minimum. Account Lockouts (Subcategory: User Account Management) 4740 - A user account is locked out. User Added to Privileged Group (Subcategory: Security Group Management) 4728 - A member was added to a security-enabled global group. 4732 - A member was added to a security-enabled local group. 4756 - A member was added to a security-enabled universal group. Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on. Account Login with Explicit Credentials (Subcategory: Logon) 4648 - A logon was attempted using explicit credentials. The "Account Usage" section of NSA's "Spotting the Adversary with Windows Event Log Monitoring" provides additional information. http://www.nsa.gov/ia/_files/app/Spotting_the_Adversary_with_Windows_Event_Log_Monitoring.pdf.
Monitor account usage events for administrative accounts. This includes events related to approved administrative accounts as well as accounts being added to privileged groups such as Administrators, Domain and Enterprise Admins and other organization defined administrative groups. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below, at minimum. Account Lockouts (Subcategory: User Account Management) 4740 - A user account is locked out. User Added to Privileged Group (Subcategory: Security Group Management) 4728 - A member was added to a security-enabled global group. 4732 - A member was added to a security-enabled local group. 4756 - A member was added to a security-enabled universal group. Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on. Account Login with Explicit Credentials (Subcategory: Logon) 4648 - A logon was attempted using explicit credentials. The "Account Usage" section of NSA's "Spotting the Adversary with Windows Event Log Monitoring" provides additional information. https://www.iad.gov/iad/library/reports/spotting-the-adversary-with-windows-event-log-monitoring.cfm.
Vuln ID:
V-43713
Rule ID:
SV-56534r3_rule
Group ID:
AD.AU.0002
Version:
AD.AU.0002
CCI:
CCI-000366
Severity:
Medium
Description:
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.ECAT-1
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.
Check:
Verify attempts to use local accounts to log on remotely from other systems are being monitored. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below. If these events are not monitored, this is a finding. More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 3 (Network) Authentication Package Name = NTLM Not a domain logon and not the ANONYMOUS LOGON account Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on.
Verify attempts to use local accounts to log on remotely from other systems are being monitored. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below. If these events are not monitored, this is a finding. More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 3 (Network) Authentication Package Name = NTLM Not a domain logon and not the ANONYMOUS LOGON account Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on.
Fix:
Monitor for attempts to use local accounts to log on remotely from other systems. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below. More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 3 (Network) Authentication Package Name = NTLM Not a domain logon and not the ANONYMOUS LOGON account Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on. The "Pass the Hash Detection" section of NSA's "Spotting the Adversary with Windows Event Log Monitoring" provides a sample query for filtering. http://www.nsa.gov/ia/_files/app/Spotting_the_Adversary_with_Windows_Event_Log_Monitoring.pdf.
Monitor for attempts to use local accounts to log on remotely from other systems. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below. More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 3 (Network) Authentication Package Name = NTLM Not a domain logon and not the ANONYMOUS LOGON account Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. Failed User Account Login (Subcategory: Logon) 4625 - An account failed to log on. The "Pass the Hash Detection" section of NSA's "Spotting the Adversary with Windows Event Log Monitoring" provides a sample query for filtering. https://www.iad.gov/iad/library/reports/spotting-the-adversary-with-windows-event-log-monitoring.cfm.
Vuln ID:
V-43714
Rule ID:
SV-56535r3_rule
Group ID:
AD.AU.0003
Version:
AD.AU.0003
CCI:
CCI-000366
Severity:
Medium
Description:
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.ECAT-1
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.
Check:
Verify Remote Desktop logins are being monitored. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below. If these events are not monitored, this is a finding. More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 10 (RemoteInteractive) Authentication Package Name = Negotiate Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on.
Verify Remote Desktop logins are being monitored. Event monitoring may be implemented through various methods including log aggregation and the use of monitoring tools. Monitor for the events listed below. If these events are not monitored, this is a finding. More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 10 (RemoteInteractive) Authentication Package Name = Negotiate Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on.
Fix:
More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 10 (RemoteInteractive) Authentication Package Name = Negotiate Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. The "Remote Desktop Logon Detection" section of NSA's "Spotting the Adversary with Windows Event Log Monitoring" provides a sample query for filtering. http://www.nsa.gov/ia/_files/app/Spotting_the_Adversary_with_Windows_Event_Log_Monitoring.pdf.
More advanced filtering is necessary to obtain the pertinent information than just looking for event IDs. Search for the event IDs listed with the following additional attributes: Logon Type = 10 (RemoteInteractive) Authentication Package Name = Negotiate Successful User Account Login (Subcategory: Logon) 4624 - An account was successfully logged on. The "Remote Desktop Logon Detection" section of NSA's "Spotting the Adversary with Windows Event Log Monitoring" provides a sample query for filtering. https://www.iad.gov/iad/library/reports/spotting-the-adversary-with-windows-event-log-monitoring.cfm.
Vuln ID:
V-44058
Rule ID:
SV-56888r2_rule
Group ID:
AD.MP.0004
Version:
AD.MP.0004
CCI:
CCI-001084
Severity:
Medium
Description:
AD admin platforms are used for highly privileged activities. Preventing communications to and from AD admin platforms, except with the domain controllers being managed, protects against an attacker's lateral movement from a compromised platform. Requirements in Firewall and Windows client STIGs restrict inbound communications, however outbound communications must be restricted as well to prevent inadvertent exposure of the privileged credentials used on these platforms.ECSC-1
Check:
Verify firewall rules prevent outbound communications from AD admin platforms, except for domain controllers being managed. If outbound communications are allowed between AD admin platforms and any other systems other than domain controllers, this is a finding.
Fix:
Maintain firewall rules to prevent outbound communications from AD admin platforms, except with domain controllers being managed.
Vuln ID:
V-44059
Rule ID:
SV-56889r2_rule
Group ID:
AD.0014
Version:
AD.0014
CCI:
CCI-000199
Severity:
Medium
Description:
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.IAIA-1
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.IAIA-1
Check:
If no Windows service \ application accounts with manually managed passwords have administrative privileges, this is NA. Verify Windows service \ application accounts with administrative privileges and manually managed passwords, have passwords changed at least every 60 days.
If no Windows service \ application accounts with manually managed passwords have administrative privileges, this is NA. Verify Windows service \ application accounts with administrative privileges and manually managed passwords, have passwords changed at least every 60 days.
Fix:
If no Windows service \ application accounts with manually managed passwords have administrative privileges, this is NA. Change passwords for Windows service \ application accounts with administrative privileges and manually managed passwords, at least every 60 days.
If no Windows service \ application accounts with manually managed passwords have administrative privileges, this is NA. Change passwords for Windows service \ application accounts with administrative privileges and manually managed passwords, at least every 60 days.
Vuln ID:
V-53727
Rule ID:
SV-67945r1_rule
Group ID:
AD.0015
Version:
AD.0015
CCI:
CCI-000366
Severity:
Medium
Description:
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.ECSC-1
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.ECSC-1
Check:
Verify domain controllers are blocked from Internet access. Various methods may be employed to accomplish this, such as restrictions at boundary firewalls, through proxy services, host based firewalls or IPsec. Review the Internet access restrictions with the administrator. If Internet access is not prevented, this is a finding. If a critical function requires Internet access, this must be documented and approved by the organization.
Verify domain controllers are blocked from Internet access. Various methods may be employed to accomplish this, such as restrictions at boundary firewalls, through proxy services, host based firewalls or IPsec. Review the Internet access restrictions with the administrator. If Internet access is not prevented, this is a finding. If a critical function requires Internet access, this must be documented and approved by the organization.
Fix:
Block domain controllers from internet access. This can be accomplished with various methods, such as restrictions at boundary firewalls, proxy services, host based firewalls, or IPsec. If a critical function requires Internet access, this must be documented and approved by the organization.
Block domain controllers from internet access. This can be accomplished with various methods, such as restrictions at boundary firewalls, proxy services, host based firewalls, or IPsec. If a critical function requires Internet access, this must be documented and approved by the organization.
Vuln ID:
V-72821
Rule ID:
SV-87467r1_rule
Group ID:
AD.0016
Version:
AD.0016
CCI:
CCI-000199
Severity:
Medium
Description:
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 re-enabling 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.
Check:
Windows Server 2016 with a domain functional level of Windows Server 2016: Open "Active Directory Administrative Center". Right-click on the domain name and select "Properties". If the "Domain functional level:" is not "Windows Server 2016", another method must be used to reset the NT hashes. See below for other options. If the "Domain functional level:" is "Windows Server 2016" and "Enable rolling of expiring NTLM secrets during sign on, for users who are required to use Microsoft Passport or smart card for interactive sign on" is not checked, this is a finding. Active Directory domains with a domain functional level below Windows Server 2016: Verify the organization rotates the NT hash for smart card-enforced accounts every 60 days. This can be accomplished with the use of scripts. DoD PKI-PKE has provided a script under PKI and PKE Tools at http://iase.disa.mil/pki-pke/Pages/tools.aspx. See the User Guide for additional information. NSA has also provided a PowerShell script with Pass-the-Hash guidance at https://github.com/iadgov/Pass-the-Hash-Guidance. Running the "Invoke-SmartcardHashRefresh" cmdlet in the "PtHTools" module will trigger a change of the underlying NT hash. See the site for additional information. Manually rolling the NT hash requires disabling and re-enabling the "Smart Card required for interactive logon" option for each smart card-enforced account, which is not practical for large groups of users. If NT hashes for smart card-enforced accounts are not rotated every 60 days, this is a finding.
Fix:
Windows Server 2016 with domain functional levels of Windows Server 2016: Open "Active Directory Administrative Center". Right-click on the domain name and select "Properties". Select "Enable rolling of expiring NTLM secrets during sign on, for users who are required to use Microsoft Passport or smart card for interactive sign on". Active Directory domains not at a Windows Server 2016 domain functional level: Rotate the NT hash for smart card-enforced accounts every 60 days. This can be accomplished with the use of scripts. DoD PKI-PKE has provided a script under PKI and PKE Tools at http://iase.disa.mil/pki-pke/Pages/tools.aspx. See the User Guide for additional information. NSA has also provided a PowerShell script with Pass-the-Hash guidance at https://github.com/iadgov/Pass-the-Hash-Guidance. Running the "Invoke-SmartcardHashRefresh" cmdlet in the "PtHTools" module will trigger a change of the underlying NT hash. See the site for additional information. Manually rolling the NT hash requires disabling and re-enabling the "Smart Card required for interactive logon" option for each smart card-enforced account, which is not practical for large groups of users.
Vuln ID:
V-78131
Rule ID:
SV-92837r3_rule
Group ID:
AD.0017
Version:
AD.0017
CCI:
CCI-000366
Severity:
Medium
Description:
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.
Check:
If the domain functional level is not at least Windows 2012 R2, this is NA. Open "Windows PowerShell". Enter "Get-ADDomain | FL DomainMode" to determine the domain functional level. Open "Active Directory Users and Computers" (available from various menus or run "dsa.msc"). Compare membership of the Protected Users group to membership of the following groups. By default, the groups are under the node referenced; however, it is possible to move those under "Users" to another location. Enterprise Admins (Users node) Domain Admins (Users node) Schema Admins (Users node) Administrators (Builtin node) Account Operators (Builtin node) Backup Operators (Builtin node) It is recommended that one account be excluded to ensure availability if there are issues with Kerberos. Excluding the account left out for availability, if all user accounts from the local domain that are members of the domain level groups above are not also members of the Protected Users group, this is a finding. (User accounts is referring to accounts for personnel, not service accounts.)
Fix:
Add user accounts from the local domain that are members of the domain level administrative groups listed below to the Protected Users group. One account may excluded to ensure availability if there are issues with Kerberos. Enterprise Admins (Users node) Domain Admins (Users node) Schema Admins (Users node) Administrators (Builtin node) Account Operators (Builtin node) Backup Operators (Builtin node) The use of the Protected Users group should be thoroughly tested before fully implementing.