0

I am working in a company who works with an Active Directory domain, running on Win Server 2016. I have some Linux servers (RHEL6) AD integrated with Samba. I've read Microsoft will release soon an update Microsoft ADV190023, and I am working with RHEL 7 (8 not approved yet), in order to work with AD controllers only via LDAPS.

I want my Linux client to speak only to DC on target port 636. I tried to look at several forums but I am a little bit lost between the different configs (realmd, krb5, sssd, pam, ldap.conf).

I know there are several ways to join an AD Domain. The last I tried was the realm who configured automatically sssd and krb5. that works successfully but I would like only on 636. moreover, I would need a little refresh on the above, I am wondering what is the difference between join a Linux to AD via the net ads join -U administrator and realm join mydomain.com ?

Is there a way to force my linux client to speak only to DC on port 636 ? Do I need to generate certificates on my Linux client and make it approve by our certification authority ? I already imported the DC certificates + the root CA.

Thanks for your help, Regards

MatMatOuk
  • 3
  • 1
  • 2
  • Hi, Does this provide you with enough information? You basically need to trust the AD/DC CA certificate on the client (in this case the RHEL server if I understand correctly) in order to make it work: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Administration_Guide/Managing_SSL-Configuring_LDAP_Clients_to_Use_SSL.html cheers – Totalcontrol Mar 03 '20 at 11:02

2 Answers2

2

Realmd allows you to configure AD an LDAP client integration on your Linux host. In the backend it will create all needed configuration files (SSSD, krb5, PAM) and join the domain.

At this moment realmd can be used to configure AD and LDAP only. You can use SSSD with LDAPS too but that will need some manual and slightly complicated configuration yourself.

Check Impact of Microsoft Security Advisory ADV190023 | LDAP Channel Binding and LDAP Signing on RHEL and AD integration. Red Hat stated that:

  • They have verified by enforcing LDAP channel binding and LDAP signing on Active Directory Domain domain 2016 with various scenarios and observed no impact on Red Hat Enterprise Linux 6, 7 and 8 client systems functionality.
  • The default configuration can result in an event with ID 2889 on the domain controller, but this looks like a false/positive log event which is currently under investigation.
  • They are working on an SSSD/adcli enhancement that allows the use of LDAPS protocol with the SSSD active directory provider. This will allow us to configure AD integration as you are used to (realmd) but with LDAPS in the backend. This type of configuration is optional and only needed in environments where the default LDAP port 389 is closed. The aforementioned RFE's will also set GSS-SPNEGO as default SASL mechanism in adcli. Currently GSSAPI is hardcoded in adcli and can not be changed.

Update: Red Hat released RHEL 7.8 yesterday which has the new adcli feature aboard. Check adcli man pages for more details. Currently there seems to be no realm integration, so if you want to go "full LDAPS" (on port 636) you will have to combine adcli with manual LDAPS configuration in SSSD.

user34515
  • 36
  • 2
0

There is no need to switch to TLS-based communication when ADV190023 recommendations are enforced on AD side. The RHEL client daemon SSSD uses SASL by default when talking to an AD backend. SASL can also sign and seal the connection so that there is no need to use TLS. Currently the SASL library shipped in RHEL does not support Channel Binding Tokens (work is already completed upstream though and will come to RHEL shortly) so that you would even run into problems when you move from SASL on default LDAP port 389 to port 636 and rely on TLS for the sealing and signing of the connection. Channel Bindung Tokens are only required when TLS is used.

Thorsten Scherf
  • 126
  • 3