[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)
---
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?
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.
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.
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.
@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)
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
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.
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.