Ldap auth failing for bind user

Problem:
LDAP auth settings in GUI are saved but GUI also shows 0 LDAP auth sources
Expected outcome:
GUI will show 1 LDAP auth source when setup properly after an LDAP user has authenticated
Foreman and Proxy versions:
3.4.0
Foreman and Proxy plugin versions:

Distribution and version:
Rocky 8.6
Other relevant data:
We are authenticating against an AD server that has STIG settings applied. I am sure that I am providing correct values when authentication is setup in the GUI. This setup was previously working in our old domain. I only needed to change the IP for the AD server. In the new domain I believe STIG settings are preventing the bind user from authenticating properly. To test this I ran the following command:

ldapsearch -x -b "dc=gsil,dc=smil" -H ldap://x.x.x.x -D "cn=satda,ou=GSIL Service Accounts,dc=gsil,dc=smil" -W (where x.x.x.x is the ip of my ldap server.)

The old domain does return search results when using that command.

The new domain gives me an error when running the same command.

ldap_bind: Strong(er) authentication required (8) additional info: 00002028 LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4563

Where are the connection settings stored in the CLI? What changes do I need to make to have my server conform with our new AD auth setup?

Just found this:

Even though the KB is for JBOSS I presume it is applicable here?

Ok, I am getting closer on this.

I found this article which seems to be relevant but a bit outdated. The concepts are at least the same.

Step 10 says Copy over the exported CA Certificate file to the Red Hat Satellite 6.3 or later server and execute the following commands:
openssl x509 -inform DER -in EXAMPLE-CA.cer -out example.crt
install example.crt /etc/pki/tls/certs/
ln -s example.crt /etc/pki/tls/certs/$(openssl x509 -noout -hash -in /etc/pki/tls/certs/example.crt).0

The first command is wrong. It doesn’t work. The screen shot in step #6 shows the cert being exported as a base 64 cert NOT der format. (so -inform DER will not work here)
Anyway, I was able to get this command to work ok: openssl s_client -connect <FQDN_AD>:389 -CAfile example.crt -showcerts -state The system tells me:

Verify return code: 0 (ok)

I dropped my root cert in /etc/pki/ca-trust/source/anchors/ and ran update-ca-trust followed by foreman-maintain service restart. I logged out from the admin account and tried logging in as an AD user. Still no luck. :thinking:

Am I putting my cert in the correct location? Any further advice on troubleshooting this? I did confirm with our AD System Administrator that the source of this issue is related to STIG settings and these two articles.

This article has been helpful confirming that my LDAP Bind is failing from a CLI perspective.

In this section:

Testing if this is one valid user on AD conn.valid_user?(’’)

conn.valid_user?('jtourville.sa')

returns the message

(Could not bind to ActiveDirectory user satda)

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.
What caught my eye first is this in your troubleshooting:

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 (which is in the majority of online documentation I found in a quick google search), the default port for that would be 636. If you are unsure, check that with your AD administrator.

The other thing I noticed is

man update-ca-trust tells me one should run update-ca-trust extract instead of only update-ca-trust to extract the certs to a directly for legacy/old applications, which (according to the same man page) seems to be where openssl searches for CA certs, too. I got into the habit of just always running both when updating system certs to be sure.

Thank you for your assistance! :grinning:

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.

Here is the output of the command:

[root@gsil-satellite ~]# openssl s_client -connect gsil-pdc.gsil.smil:389 -CAfile gsil-root-ca.pem -showcerts -state
CONNECTED(00000003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:error in SSLv3/TLS write client hello
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 313 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Connecting to AD, your command string should be:
openssl s_client -connect :389 -starttls ldap

ok, ran it with the options you specified:

[root@gsil-satellite ~]# openssl s_client -connect gsil-pdc.gsil.smil:389 -starttls ldap -CAfile gsil-root-ca.pem -showcerts -state
CONNECTED(00000003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS read server hello
depth=1 DC = smil, DC = gsil, CN = GSIL-CA
verify return:1
depth=0 
verify return:1
SSL_connect:SSLv3/TLS read server certificate
SSL_connect:SSLv3/TLS read server key exchange
SSL_connect:SSLv3/TLS read server certificate request
SSL_connect:SSLv3/TLS read server done
SSL_connect:SSLv3/TLS write client certificate
SSL_connect:SSLv3/TLS write client key exchange
SSL_connect:SSLv3/TLS write change cipher spec
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSLv3/TLS read change cipher spec
SSL_connect:SSLv3/TLS read finished
---
Certificate chain
 0 s:
   i:DC = smil, DC = gsil, CN = GSIL-CA
-----BEGIN CERTIFICATE-----
MIIGXTCCBEWgAwIBAgITbwAAABwSHcv93bEX/QAAAAAAHDANBgkqhkiG9w0BAQsF
ADA+MRQwEgYKCZImiZPyLGQBGRYEc21pbDEUMBIGCgmSJomT8ixkARkWBGdzaWwx
EDAOBgNVBAMTB0dTSUwtQ0EwHhcNMjMwMTA5MjIwNzM1WhcNMjQwMTA5MjIwNzM1
WjAAMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0sAdJdAR0aZyKsWa
+lsBWCoul27KCJ51oXaD0sItqLQTkN5i+bpZpZ9ePCXMKuBNpNQRcQ6dgm8zTaLl
ZnZ/m/mm7oihLtx0gnxj3V6WBj2Js+kQ8AVyI5VQWX1p490yjc9OZODmC4a6NsVf
PfHqMMRK/NA8vpOp+90smSTGiPTAx2kKI2+zhqeeBw0RRKDMsPMqO7oPr2FfPlnH
/BEpSba6+Ulo8F2w1Rrmrmwgyx9rJYC0R2gu1LyvAqk9r5bA5XVonWbFzcJGSjf+
j/JK7st/O7SqgATOeMfKI0qJJceAaMeNevAQJIGzO8DKzQOdtXIhLm3Sg2rFdiLN
+KxxqQIDAQABo4ICkDCCAowwNgYJKwYBBAGCNxUHBCkwJwYfKwYBBAGCNxUIgsKb
NYX/oA2B3Ycdg8Tbc5yVSlEBHAIBbgIBADApBgNVHSUEIjAgBggrBgEFBQcDAgYI
KwYBBQUHAwEGCisGAQQBgjcUAgIwDgYDVR0PAQH/BAQDAgWgMDUGCSsGAQQBgjcV
CgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwEwDAYKKwYBBAGCNxQCAjAdBgNV
HQ4EFgQUjlLWWZ4VznapyVhW7JyDUw/eas4wHwYDVR0jBBgwFoAUBWCUg8BvsBb5
WEiRjwQiLa0QXZUwgcMGA1UdHwSBuzCBuDCBtaCBsqCBr4aBrGxkYXA6Ly8vQ049
R1NJTC1DQSxDTj1nc2lsLWNhLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2
aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWdzaWwsREM9c21p
bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM
RGlzdHJpYnV0aW9uUG9pbnQwgbcGCCsGAQUFBwEBBIGqMIGnMIGkBggrBgEFBQcw
AoaBl2xkYXA6Ly8vQ049R1NJTC1DQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIw
U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1nc2lsLERD
PXNtaWw/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRp
b25BdXRob3JpdHkwIAYDVR0RAQH/BBYwFIISZ3NpbC1wZGMuZ3NpbC5zbWlsMA0G
CSqGSIb3DQEBCwUAA4ICAQChpjwtvE9f0NS79yDlE3EvVSHiAXuBvjzsPbfHBz8u
nlXGlEyn4dnX4veumVRmvc81wV5S7tp5UoJ39ta4wbVv9gwmmW7/dqfvTDQ+N7R0
tSUODIdfuwgEK4ugYNAhVCw43nVWB5WuD0o127NqeGHaZIjCJxaJ9kd6pMhWcqUo
ARoeJCdrzSKiVIYrjE5VWerTVPvDzAVjDm9YEQkKks01sByAZckoBeXXhVoIYmO1
Wew8q9Vas8Vc2zO9Q5PdgtRgFZCByJi7W4c0TspBRSNupAPO8Sy2i1lyow9ZFDtU
f5ropGP7ndLc9b5lBzfy8oZzxCBiPAkRw3lbd/pppH1VDe6r2mGaa74tc9su+cBt
6UNJWvBobCySuI1DjmKs6nTDAK0Ky3EkLCsCUF2XqEQXAdYMvEFXCSYLl8Yct7NE
cLkMAxr7isZXiSj3phHxFkLksUepDL6jYVWlaehGNOxoMbnKipkI6mMJjsuz+A5M
A5VJqLPrRs1SKGpurxbWo7DU3W+t3qPoahme/JYDUBP0o6MW3FVlm2oJ3xsdrH0v
/lCnviGfpuzL8PlrE02oCvnHgqa04sYlzgOj3a1SYMPuqkWj4Q5KMYdzs1nENply
l+QO4e0nveVi8IACeFRFPvtBS7MBOyaa1XKvSSN3nWY28ldRL9LnSTf8BYRNYgS3
rA==
-----END CERTIFICATE-----
---
Server certificate
subject=

issuer=DC = smil, DC = gsil, CN = GSIL-CA

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 2223 bytes and written 514 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 940C0000FBD061C0E76221894E233F22AE1FE7BD15D789594EAEC65A88F43697
    Session-ID-ctx: 
    Master-Key: 669398180256FD2131DBAD84A25B7F9EC3F3F911E7F7F62732668EAC7E44F3C90286BADB6DFB5A9522D35FFA6D2953E0
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1674760637
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
read:errno=104

I also presume that the RH KB 1498773 is not directly applicable as it states:

Resolution

This solution is for creating a certificate in Active Directory, which can then be installed on the Satellite Servers base system, to enable secure LDAP (LDAPS).

So, assuming my certificates are working properly, I presume I should research the process to use starttls with foreman?

That’s what we use and it works well. We are having some problems in Azure, but that’s par for the course. STARTTLS works fine with our premise AD.

Ok, but how do I get starttls to work with foreman? My setup is not working based on the settings I have in the GUI.

Here are the first three screens, This is what we found necessary. Make sure that your location and organization are in “Selected items” under their respective tabs. Note that ad-onprem refers to all three of our on-prem DCs.



Ok, that seems to track what I have done with the exception of the Groups base DN. My understanding is, that field is not strictly necessary My location and organization are “Selected Items” as you suggest.

What happens when you click the “Test Connection” button?

I get the message “Test connection to LDAP server was successful”. I suspect that button in the GUI only does a basic ping test to the server, not check if the bind account is working as expected. As a further test I removed the info from Account Username, Account Password and Base DN fields on the second page. I hit the test button again and the message is still the same. (Success)

Also, I am aware of this KB but it does not explicitly state Satellite/Foreman.

Can any of the RH Developers chime in here?

I have taken a peek at the code and it looks like starttls is actually not supported by the codebase:

I am not a dev, so I might miss something here and since @poulterer stated it works fine in their environment, I’ll assume I overlooked something here.

What I did find though is that Foreman uses GitHub - theforeman/ldap_fluff: An LDAP gem for querying LDAP in various styles: Active Directory, FreeIPA & POSIX for connections to any type of LDAP server, and it mentions here in the README that bind users need to be formated as “addomain/username” (maybe also “addomain\username” like in the sceenshot in Ldap auth failing for bind user - #12 by poulterer this reply from @poulterer.

From your screenshot in Ldap auth failing for bind user - #11 by JeremyTourville it looks like you do not have the domain specified for your bind user. Have you tried adding that?

Yes, StartTLS is not supported by Foreman, there was an issue open for this which I found closed because of inactivity: Bug #7016: Make Foreman support StartTLS - Foreman

I remember to “fixed” this somewhere at a customer by changing simple_tls to start_tls, but of course this is not update save.

@areyus
I have tried specifying the domain for my bind user. It makes no difference. Also, in one of my earlier posts I referred to LDAP Auth Troubleshooting via foreman-rake. I believe that is the same info as the ldap_fluff you are referrring to.

That article has you perform several steps:

Accessing foreman rake console = works as expected
Command to see all Sources created on Red Hat Satellite Server. = works as expected
Attributing the query output to source_now = works as expected
Creating the connection = seems to work, I do get some output
Testing if this is one valid user on AD conn.valid_user?(’’) = does not work. returns the message

(Could not bind to ActiveDirectory user satda)

I acknowledge that poulterer says starttls is working but I was unable to tell if his environment is exactly the same as mine. I agree we are both doing starttls but does he have all three settings the same in his AD setup? I think that is part of the issue. Mine is a somewhat narrow use case, but one that many of us who work in a Gov’t sector face.

@Dirk Thanks for confirming that functionality does not exist. As I previously stated Red Hat / MS Security Advisory ADV190023 does not list Satellite or Foreman explicitly. Is this an issue that can be added to the codebase? The ability to have an LDAP auth source when AD uses channel binding is important for me (and many other folks in Gov’t)

I created an issue for this: Feature #36026: Make Foreman support StartTLS - Foreman
I think it is easy to add for someone who has experience with the frontend, so unfortunately not me.