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! 
Just to confirm, it looks like once I have the debugging turned on I can simply run foreman-tail and it will output all the logs I need.
It looks like I see info there that shows the auth failure and it all points back to the ldap_fluff testing.
So, I think at this point we have probably exhausted all testing and confirmed the correct settings. I guess I will just have to wait for RFE to be completed.
1 Like
I have another suggestion that you can try, it sucks from a security perspective - but if it helpsâŚ
I have my Foreman instance authenticating against Active Directory, but I am using straight up LDAP/S over 636/tcp. What might work for you is changing the line in auth_source_ldap.rb from OpenSSL::SSL::VERIFY_PEER to OpenSSL::SSL::VERIFY_NONE
I had to change this because we authenticate to Active Directory through a load balancer, and the SSL certificates were getting presented from each of the AD Domain Controllers and confusing the heck out of Foreman which was expecting one name, but getting different ones.
I appreciate that. Yeah, we had considered other ways to make authentication work such as using IdM/FreeIPA. Our focus was to use AD LDAP as much as possible. Our IdM is AD integrated anyhow so all our users live in AD. I was sort of surprised to find out Satelllite/Foreman didnât support this feature, after all the RH OS supports start_tls and the issue has been know about for a while now. Anyway⌠not bashing anyone, just not what I expected.
Do yourself a favor and donât use IdM/FreeIPA combined with an Active Directory trust⌠it works fine initially, but when the CA certificate expires turns into a nightmare. We ended up going with a native FreeIPA/IdM (No AD Trust) implementation but are now migrating everything to straight up native AD through SSSD.
I appreciate the suggestion but many security settings are mandated to us. See the STIG stuff at the top of the thread.