What changed in Active Directory Domain STIG V3R8V3R8 changes

Check text

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 EnterpriseEA 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 administratorhighly privileged groups, includingsuch as the Domain Admins, groupSchema Admins, domain member server administrators groups (i.e., Backup Operators and Server Operators), or domainlocal workstation administratorsadministrator delegation groups, this is a finding.

Fix text

Create the necessary documentation that identifies the members of the Enterprise Admins group. Ensure that Isolate eachEnterprise memberAdmin hasaccounts aby separaterestricting uniquethem accountfrom thatconcurrent canmembership onlyin beother usedprivileged toor manageadministrative thegroups. Active Ensure Directoryadministrators Forest. Removeuse anya Enterpriseseparate, Admindedicated, accountsand fromunique otheraccount administratorreserved groupsstrictly for Active Directory Forest management.

Discussion

The Enterprise Admins (EA) group is a highly privileged group. Personnel whoTo areprevent forest-wide credential theft, Active Directory system administrators must logstrictly onadhere to Activethe Directoryprinciples systemsof onlyseparation usingof accountsduties withand theleast levelprivilege. ofEA authoritygroup necessary.membership Onlymust systembe administratorrestricted to dedicated accounts used exclusivelysolely tofor manageforest-level themanagement. ActiveAuthenticating DirectoryEA Forestcredentials mayon bestandard membersworkstations ofor themember Enterpriseservers Adminsexposes groupthem to harvesting attacks, which can lead to complete forest compromise. AIsolating separationadministrative ofroles administratorand responsibilitiesrestricting helpsEA mitigateaccount theusage riskdirectly ofmitigates privilegethese escalationlateral resultingmovement fromand credentialprivilege theftescalation attacksrisks.

V-243466 in V3R8

Check text

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. DODDoW PKI-PKE has provided a script under PKI and PKE Tools at https://cyber.mil/pki-pke/tools-configuration-files/. Refer to the User Guide for additional information. NSA has also provided a PowerShell script with Pass-the-Hash guidance at https://github.com/nsacyber/Pass-the-Hash-Guidance. Running the "Invoke-SmartcardHashRefresh" cmdlet in the "PtHTools" module will trigger a change of the underlying NT hash. Refer to the site for additional information. Manually rolling the NT hash requires disabling and reenabling 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 text

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. DODDoW PKI-PKE has provided a script under PKI and PKE Tools at https://cyber.mil/pki-pke/tools-configuration-files/. Refer to the User Guide for additional information. NSA has also provided a PowerShell script with Pass-the-Hash guidance at https://github.com/nsacyber/Pass-the-Hash-Guidance. Running the "Invoke-SmartcardHashRefresh" cmdlet in the "PtHTools" module will trigger a change of the underlying NT hash. Refer to the site for additional information. Manually rolling the NT hash requires disabling and reenabling the "Smart Card required for interactive logon" option for each smart card-enforced account, which is not practical for large groups of users.

V-243476 in V3R8

Title

Interconnections between DoDDoW directory services of different classification levels must use a cross-domain solution that is approved for use with inter-classification trusts.

Check text

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 DoDDoW 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 text

Delete the trust relationship that is defined between entities with resources at different DoDW classification levels.

Discussion

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 DODDoW- 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-DoDDoW organizations since these trusts are examined in a previous check.)

V-243482 in V3R8

Title

A controlled interface must have interconnections among DoDW information systems operating between DoDW and non-DoDW systems or networks.

Check text

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-DoDDoW 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 DoDDoW 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 IAO1NSO for compliance with the Network Infrastructure STIG. 5. If any trust is defined with a non-DoDDoW 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.

Discussion

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 DoDDoW organization and a non-DoDDoW organization, the security posture of the two organizations might be significantly different. If the non-DoDDoW organization maintained a less secure environment and that environment were compromised, the presence of the AD trust might allow the DoDDoW environment to be compromised also.

V-243483 in V3R8

Check text

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 that are installed. In particular, request details of Active DiretoryDirectory 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 text

Implement a VPN or other network protection solution in accordance with the Network Infrastructure STIG that protects AD data in transit across DoDDoW enclave boundaries.

Discussion

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. DoDDoW 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 DoDDoW 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.

V-243495 in V3R8