{"stig":{"title":"Active Directory Forest Security Technical Implementation Guide","version":"3","release":"2"},"checks":[{"vulnId":"V-243502","ruleId":"SV-243502r1026198_rule","severity":"medium","ruleTitle":"Membership to the Schema Admins group must be limited.","description":"The Schema Admins group is a privileged group in a forest root domain. Members of the Schema Admins group can make changes to the schema, which is the framework for the Active Directory forest. Changes to the schema are not frequently required. This group only contains the Built-in Administrator account by default. Additional accounts must only be added when changes to the schema are necessary and then must be removed.","checkContent":"Open \"Active Directory Users and Computers\" on a domain controller in the forest root domain.\n\nNavigate to the \"Users\" container.\n\nRight-click on \"Schema Admins\" and select \"Properties\", and then select the \"Members\" tab.\n\nIf any accounts other than the built-in Administrators group are members, verify their necessity with the ISSO.\n\nIf any accounts are members of the group when schema changes are not being made, this is a finding.","fixText":"Limit membership in the Schema Admins group to only those accounts necessary during a schema update. Remove accounts when the updates are complete. Document accounts necessary during schema updates with the ISSO.","ccis":["CCI-000366"]},{"vulnId":"V-243503","ruleId":"SV-243503r1026201_rule","severity":"medium","ruleTitle":"Anonymous Access to AD forest data above the rootDSE level must be disabled.","description":"For Windows Server 2003 or above, the dsHeuristics option can be configured to override the default restriction on anonymous access to AD data above the rootDSE level. Anonymous access to AD data could provide valuable account or configuration information to an intruder trying to determine the most effective attack strategies.","checkContent":"1. At the command line prompt enter (on a single line): \ndsquery * \"cn=Directory Service,\ncn=Windows NT,cn=Services,cn=Configuration,dc=[forest-name]\" -scope base -attr * \n\n(Where dc=[forest-name] is the fully qualified LDAP name of the root of the domain being reviewed.)\n\nExample:\nThe following is an example of the dsquery command for the vcfn.ost.com forest.\n\ndsquery * \"cn=Directory Service,cn=Windows  NT,cn=Services,cn=Configuration,  dc=vcfn,dc=ost,dc=com -scope base -attr * \n\n2. If the dsHeuristics attribute is listed, note the assigned value.\n\n3. If the dsHeuristics attribute is defined and has a \"2\" as the 7th character, then this is a finding.\n\nExamples of values that would be a finding as follows:\n \"0000002\", \"0010002\", \"0000002000001\".\n(The 7th character controls anonymous access.)\n\nSupplementary Notes:\nDomain controllers have this option disabled by default. However, this check verifies that the option has not been enabled.\n\nThe dsHeuristics option can be configured with the Windows Support Tools Active Directory Service Interfaces Editor (ADSI Edit) console (adsiedit.msc).","fixText":"Disable anonymous access to AD forest data above the rootDSE level.","ccis":["CCI-000366"]},{"vulnId":"V-243504","ruleId":"SV-243504r1026204_rule","severity":"medium","ruleTitle":"The Windows Time Service on the forest root PDC Emulator must be configured to acquire its time from an external time source.","description":"When the Windows Time service is used to synchronize time on client computers (workstations and servers) throughout an AD forest, the forest root domain PDC Emulator is the normal default to provide the authoritative time source for the entire forest. To obtain an accurate time for itself, the forest root domain PDC Emulator acts as a client to an external time source.\n\nIf the Windows Time service on the forest root domain PDC Emulator is not configured to acquire the time from a proper source, it may cause time service clients throughout the forest to operate with the inaccurate time setting.\n\nWhen a Windows computer operates with an inaccurate time setting, access to resources on computers with the accurate time might be denied. This is notably true when Kerberos authentication is utilized. Operation with an inaccurate time setting can reduce the value of audit data and invalidate it as a source of forensic evidence in an incident investigation.","checkContent":"This applies to the domain controller with the PDC Emulator role in forest root domain; it is NA for other domain controllers in the forest.\n\nDetermine the domain controller with the PDC Emulator role in the forest root domain:\n\nWindows 2016 or later: \n\nOpen \"Windows PowerShell\".\n\nEnter \"Get-ADDomain -Identity [Forest Root Domain] | FT PDCEmulator\", where [Forest Root Domain] is the forest root domain name, such as \"example.mil\". (This can also be entered without the -Identity parameter if running within the forest root domain.)\n\nWindows 2016:\n\nOpen \"Active Directory Users and Computers\" from a domain controller in or connected to the forest root (available from various menus or run \"dsa.msc\").\n\nSelect \"Action\" in the menu, then All Tasks >> Operations Masters.\n\nSelect the \"PDC\" tab.\n\nOn the system with the PDC Emulator role, open \"Windows PowerShell\" or an elevated \"Command Prompt\" (run as administrator).\n\nEnter \"W32tm /query /configuration\".\n\nUnder the \"NtpClient\" section:\n\nIf the value for \"Type\" is not \"NTP\", this is a finding.\n\nIf the value for \"NtpServer\" is not an external DOD time source, this is a finding.\n\nIf an alternate time synchronization tool is used and is not enabled or not configured to a synchronize with an external DOD time source, this is a finding.\n\nThe US Naval Observatory operates stratum 1 time servers, identified at https://www.cnmoc.usff.navy.mil/Our-Commands/United-States-Naval-Observatory/Precise-Time-Department/Network-Time-Protocol-NTP/. Time synchronization will occur through a hierarchy of time servers down to the local level. Clients and lower-level servers will synchronize with an authorized time server in the hierarchy.","fixText":"Configure the forest root PDC Emulator to acquire its time from an external time source.\n\nThe Windows Time Service can be configured by setting the policy value for Computer Configuration >> Administrative Templates >> System >> Windows Time Service >> Time Providers >> \"Configure Windows NTP Client\" to \"Enabled\", and configuring the \"NtpServer\" field to point to an authorized time server.","ccis":["CCI-001891","CCI-004923"]},{"vulnId":"V-243505","ruleId":"SV-243505r1026206_rule","severity":"low","ruleTitle":"Changes to the AD schema must be subject to a documented configuration management process.","description":"Poorly planned or implemented changes to the AD schema could cause the applications that rely on AD (such as web and database servers) to operate incorrectly or not all.\n\nImproper changes to the schema could result in changes to AD objects that are incompatible with correct operation of the Windows domain controller and the domain clients. This could cause outages that prevent users from logging on or accessing Windows server resources across multiple hosts.","checkContent":"1. Interview the ISSO.\n\n2. Obtain a copy of the site's configuration management procedures documentation.\n\n3. Verify that there is a local policy that requires changes to the directory schema to be processed through a configuration management process. This applies to directory schema changes whether implemented in a database or other types of files. For AD, this refers to changes to the AD schema.\n\n4. If there is no policy that requires changes to the directory schema to be processed through a configuration management process, then this is a finding.","fixText":"Document and implement a policy to ensure that changes to the AD schema are subject to a configuration management process.","ccis":["CCI-000366"]},{"vulnId":"V-243506","ruleId":"SV-243506r1026208_rule","severity":"high","ruleTitle":"Update access to the directory schema must be restricted to appropriate accounts.","description":"A failure to control update access to the AD Schema object could result in the creation of invalid directory objects and attributes. Applications that rely on AD could fail as a result of invalid formats and values. The presence of invalid directory objects and attributes could cause failures in Windows AD client functions and improper resource access decisions.","checkContent":"Start a Schema management console. (See supplemental notes.)\nSelect and then right-click on the Active Directory Schema entry in the left pane.\nSelect Permissions.\n\nIf any of the permissions for the Schema object are not at least as restrictive as those below, this is a finding. \n\nThe permissions shown are at the summary level.  More detailed permissions can be viewed by selecting the Advanced button, selecting the desired entry, and the Edit button.\n\nAuthenticated Users:\nRead\nSpecial Permissions\nThe Special permissions for Authenticated Users are List and Read type.  If detailed permissions include any additional Permissions or Properties this is a finding.\n\nSystem:\nFull Control\n\nEnterprise Read-only Domain Controllers:\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\n\nSchema Admins:\nRead\nWrite\nCreate all child objects\nChange schema master\nManage replication topology\nMonitor active directory replication\nRead only replication secret synchronization\nReanimate tombstones\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\nReplication synchronization\nUpdate schema cache\nSpecial permissions\n(Special permissions = all except Full, Delete, and Delete subtree when detailed permissions viewed.)\n\nAdministrators:\nManage replication topology\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\nReplication Synchronization\n\nEnterprise Domain Controllers:\nManage replication topology\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\nReplication Synchronization\n\nSupplemental Notes:\nIf the Schema management console has not already been configured on the computer, create a console by using the following:\n\nThe steps for adding the snap-in may vary depending on the Windows version.\nRegister the required DLL module by typing the following at a command line \"regsvr32 schmmgmt.dll\".\nRun \"mmc.exe\" to start a Microsoft Management Console. \nSelect Add/Remove Snap-in from the File menu.\nFrom the Available Standalone Snap-ins list, select Active Directory Schema\nSelect the Add button.\nSelect the OK button.\n\nWhen done using the console, select Exit from the File (or Console) menu.\nSelect the No button to the Save console settings... prompt (unless the SA wishes to retain this console). If the console is retained, the recommended name is schmmgmt.msc and the recommended location is the [systemroot]\\system32 directory.","fixText":"Ensure the access control permissions for the AD Schema object conform to the required permissions as shown below.\n\nAuthenticated Users:\nRead\nSpecial Permissions\nThe Special permissions for Authenticated Users are List and Read type.  If detailed permissions include any additional Permissions or Properties this is a finding.\n\nSystem:\nFull Control\n\nEnterprise Read-only Domain Controllers:\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\n\nSchema Admins:\nRead\nWrite\nCreate all child objects\nChange schema master\nManage replication topology\nMonitor active directory replication\nRead only replication secret synchronization\nReanimate tombstones\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\nReplication synchronization\nUpdate schema cache\nSpecial permissions\n(Special permissions = all except Full, Delete, and Delete subtree when detailed permissions viewed.)\n\nAdministrators:\nManage replication topology\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\nReplication Synchronization\n\nEnterprise Domain Controllers:\nManage replication topology\nReplicating Directory Changes\nReplicating Directory Changes All\nReplicating Directory Changes In Filtered Set\nReplication Synchronization","ccis":["CCI-002235"]},{"vulnId":"V-269098","ruleId":"SV-269098r1106505_rule","severity":"high","ruleTitle":"Windows Server hosting Active Directory Certificate Services (AD CS) must enforce Certificate Authority (CA) certificate management approval for certificate requests.","description":"When users are requesting new certificates through AD CS, there must be management approval and awareness for these requests. Without this, a user or bad actor could request certificates they should not have or should not have access to.","checkContent":"Certificate templates with the following extended key usages AND that allow a requestor to supply the subject name in the request require manual approval. In the AD CS web server properties, select \"VulnerableCertTemplate\" properties. Verify that \"Subject Name\" and \"Supply in the request\" are selected.\n\nIf \"Subject Name\" AND \"Supply in the request\" are selected and if manual approval is not required, this is a finding. \n\nIf the \"Supply in Request\" is NOT selected, and the Enroll Permissions for the template have been limited to a select group of users/administrators, this is not a finding.","fixText":"In the AD CS web server properties, select \"VulnerableCertTemplate\" properties and then select \"Subject Name\" and \"Supply in the request\".\n\nCertificate templates with the following extended key usages must require manual approval in all cases:\n  i. Smart Card Logon (1.3.6.1.4.1.311.20.2.2).\n ii. Any Purpose EKU (2.5.29.37.0).\niii. No EKU set. i.e., this is a (subordinate) CA certificate.\n\nCertificate templates with the following extended key usages AND that allow a requestor to supply the subject name in the request must require manual approval:\n  i. Client Authentication (1.3.6.1.5.5.7.3.2).\n ii. PKINIT Client Authentication (1.3.6.1.5.2.3.4).\niii. Supply in request\" setting:  VulnerableCertTemplate Properties.","ccis":["CCI-000366"]},{"vulnId":"V-269099","ruleId":"SV-269099r1026184_rule","severity":"high","ruleTitle":"Windows Server running Active Directory Certificate Services (AD CS) must be managed by a PAW tier 0.","description":"Verify that a site has set aside one or more PAWs for remote management of AD CS.","checkContent":"Verify that a site has set aside one or more PAWs for remote management of AD CS. \n\nA dedicated AD CS/CA Admin account that is only usable on tier 0 PAW or the ADCS server must be used to manage the certificate authority and approve requests.\n\nReview any available site documentation.\n\nVerify that any PAW used to manage high-value IT resources of a specific tier are used exclusively for managing high-value IT resources assigned to only one tier.\n\nIf the site has not set aside one or more PAWs for remote management of AD CS, this is a finding.","fixText":"Configure and set aside one or more PAWs for configuration and management of AD CS. \n\nFor AD, multiple configuration items could enable anonymous access.\n\nSet aside one or more PAWs for remote management of high-value IT resources assigned to a specific tier. For example, using the Microsoft Tier 0-2 model, each PAW would be assigned to manage Tier 0, Tier 1, or Tier 2 high-value IT resources.","ccis":["CCI-000366"]}]}