Ldap auth failing for bind user

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
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
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
Server certificate

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
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 940C0000FBD061C0E76221894E233F22AE1FE7BD15D789594EAEC65A88F43697
    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

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


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.

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.


Do you recall how you did this? I reviewed the code you referred to and I already modified /usr/share/foreman/app/models/auth_sources/auth_source_ldap.rb


{ :method => :simple_tls, :tls_options => { :verify_mode => OpenSSL::SSL::VERIFY_PEER } }
was changed to
{ :method => :start_tls, :tls_options => { :verify_mode => OpenSSL::SSL::VERIFY_PEER } }

After this I restarted the server and attempted to login. The login still fails.

I would be very happy if I could make this work at the CLI level. I fully understand incorporating it into the GUI is a much larger effort. I greatly appreciate the feature request you submitted!

As far as I remember this was everything I did change and of course the port in the settings. From my understanding of ldap_fluff this should also be the only thing.

The port in the settings? Wouldn’t that be 389? netstat shows that 389 is the listening port on the AD server. (not 636)

Yes, StartTLS is upgrading the normal session, so it should be 389 (or 3268 for the AD global catalog) instead of 636 (or 3269).

I am wondering if there is something more required? It seems we both agree that I have the auth_source_ldap.rb set correctly and AD is definitely doing start_tls. Is there a way I can validate what cert is being presented to AD? The command we used to test for the presence of start_tls used the root CA cert. What happens when AD is server is domain.com and Satellite is idm.domain.com?

It only verifies the certificate of the AD server, so trusting the AD CA should be enough. If I remember correctly this was done at the customer using the system’s CA trust. So for EL systems this should be placing the certificate in /etc/pki/ca-trust/source/anchors/ and running update-ca-trust, but you can switch of verification for testing if this is the problem at all.

Does anything land in the logs? Very likely you need to increase the loglevel and enable the ldap logger.

This is in /etc/foreman/settings.yaml:

  :level: debug

and for LDAP:

    :enabled: true

Perfect, you addressed the question of where to put the cert. I was wondering that and couldn’t update my reply before I could see you were typing up a response. Anyhow, I’ll turn on some logging as you suggest and see what happens. More to follow… Thanks! :grinning: