Thank you for your assistance! 
I am not 100% sure what exactly you or your AD admin assume the issue is, here. I donât know much about AD or STIG settings, but from what you wrote Iâll assume you are searching the issue on the SSL/TLS end of things.
Your assumption is correct. I think we have a SSL/TLS issue because of required STIG settings. First, let me give you the required settings that we have already confirmed are set in AD. Also see the MS articles I referenced above for more general info.
#1 Vul ID : V-205820
**Rule Title** : Windows Server 2019 domain controllers must require LDAP access signing.
**Discussion**: Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client and modifies them before forwarding them to the client. In the case of an LDAP server, this means that an attacker could cause a client to make decisions based on false records from the LDAP directory. The risk of an attacker pulling this off can be decreased by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) authentication header mode (AH), which performs mutual authentication and packet integrity for Internet Protocol (IP) traffic, can make all types of man-in-the-middle attacks extremely difficult.
Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188
**Check Text**: This applies to domain controllers. It is NA for other systems.
If the following registry value does not exist or is not configured as specified, this is a finding:
Registry Hive: HKEY_LOCAL_MACHINE
Registry Path: \SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Value Name: LDAPServerIntegrity
Value Type: REG_DWORD
Value: 0x00000002 (2)
**Fix Text**: Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Domain controller: LDAP server signing requirements" to "Require signing".
#2 Vul ID : V-205875
**Rule Title** : Windows Server 2019 directory data (outside the root DSE) of a non-public directory must be configured to prevent anonymous access.
**Discussion**: To the extent that anonymous access to directory data (outside the root DSE) is permitted, read access control of the data is effectively disabled. If other means of controlling access (such as network restrictions) are compromised, there may be nothing else to protect the confidentiality of sensitive directory data.
**Check Text**: This applies to domain controllers. It is NA for other systems.
Open "Command Prompt" (not elevated).
Run "ldp.exe".
From the "Connection menu", select "Bind".
Clear the User, Password, and Domain fields.
Select "Simple bind" for the Bind type and click "OK".
Confirmation of anonymous access will be displayed at the end:
res = ldap_simple_bind_s
Authenticated as: 'NT AUTHORITY\ANONYMOUS LOGON'
From the "Browse" menu, select "Search".
In the Search dialog, enter the DN of the domain naming context (generally something like "dc=disaost,dc=mil") in the Base DN field.
Clear the Attributes field and select "Run".
Error messages should display related to Bind and user not authenticated.
If attribute data is displayed, anonymous access is enabled to the domain naming context and this is a finding.
The following network controls allow the finding severity to be downgraded to a CAT II since these measures lower the risk associated with anonymous access.
Network hardware ports at the site are subject to 802.1x authentication or MAC address restrictions.
Premise firewall or host restrictions prevent access to ports 389, 636, 3268, and 3269 from client hosts not explicitly identified by domain (.mil) or IP address.
**Fix Text**: Configure directory data (outside the root DSE) of a non-public directory to prevent anonymous access.
For AD, there are multiple configuration items that could enable anonymous access.
Changing the access permissions on the domain naming context object (from the secure defaults) could enable anonymous access. If the check procedures indicate this is the cause, the process that was used to change the permissions should be reversed. This could have been through the Windows Support Tools ADSI Edit console (adsiedit.msc).
The dsHeuristics option is used. This is addressed in check V-8555 in the AD Forest STIG.
#3 Vul ID: V-205920
**Rule Title** : Windows Server 2019 must be configured to at least negotiate signing for LDAP client signing.
**Discussion**: This setting controls the signing requirements for LDAP clients. This must be set to "Negotiate signing" or "Require signing", depending on the environment and type of LDAP server in use.
**Check Text**: If the following registry value does not exist or is not configured as specified, this is a finding:
Registry Hive: HKEY_LOCAL_MACHINE
Registry Path: \SYSTEM\CurrentControlSet\Services\LDAP\
Value Name: LDAPClientIntegrity
Value Type: REG_DWORD
Value: 0x00000001 (1)
**Fix Text**: Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: LDAP client signing requirements" to "Negotiate signing" at a minimum.
Next, let me address your questions further to provide better clarity
Is your AD server using STARTTLS to do SSL/TLS? Do you actually see certificate validation in the output? If not, you are connecting to a plain text port which always passes certificate validation. In case your AD is configured to use LDAPS instead
I am not 100% positive if we are using STARTTLS. Based on the fact that I ran netstat on the LDAP server and see port 389 open, I think I can safely assume we are not using LDAPS (636). 636 was definitely missing from the output. I did also see port 3268 but that is the global catalog port and is coming from our IDM server. (BTW, I know we could also choose to use IPA for an LDAP auth source but decided Active Directory was a better choice as it is âmore nativeâ.
I am sorry if my description of the openssl s_client failed to show the actual output. The system is Govât air-gapped, high security and getting approval for logs is somewhat cumbersome. It can be done but not without some effort. That is why I attempted to describe the issue as best I could. Let me follow up with getting you the actual output from the openssl s_client command. For now Iâll address your other questions and follow up ASAP with some logs.
update-ca-trust tells me one should run update-ca-trust extract insteadâŚ
Acutally, I had done that but I couldnât go back and edit by the time I realized my mistake in typing this up in the forum.
I followed KB article 1498773 that I referenced earlier. I actually dropped the cert in two locations:
#1 /etc/pki/tls/certs where the cert was appended to the bundle as listed in step 13 AND
#2 /etc/pki/ca-trust/source/anchors/
Then I ran:
update-ca-trust extract
update-ca-trust
foreman-maintain service restart --only httpd,foreman
As a side note, I did figure out why the old domain works and the new domain does not. Vul ID : V-205820 is not set in the old domain, thus allowing the ldap connection to work. It is also part of the reason why I am getting the message (Could not bind to ActiveDirectory user satda) because it IS set in the new domain.
Vul ID** : V-205875 is loosely applicable but not directly. We are not doing an anonymous bind, we are using satda (an AD service account ) to perform the bind.
To sum up:
STIG #1 Vul ID : V-205820 and #3 Vul ID: V-205920 are the most applicable. I think that is the issue preventing me from connecting.
My assumption is that RH KB 1498773 is still applicable. I think I have performed the steps in that article correctly but understand we should verify that with more logs. More logs to follow so you can see the actual output I am getting.
