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.
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
#L100
{ :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:
:logging:
:level: debug
and for LDAP:
:loggers:
: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! 