Назад | Перейти на главную страницу

Microsoft ADV190023: как принудительно включить LDAPS на RHEL 7?

Я работаю в компании, которая работает с доменом Active Directory, работающим на Win Server 2016. У меня есть несколько серверов Linux (RHEL6) AD, интегрированных с Samba. Я читал, что Microsoft скоро выпустит обновление Microsoft ADV190023, и я работаю с RHEL 7 (8 еще не утверждены), чтобы работать с контроллерами AD только через LDAPS.

Я хочу, чтобы мой Linux-клиент разговаривал только с DC на целевом порту 636. Я попытался просмотреть несколько форумов, но я немного потерялся между различными конфигурациями (realmd, krb5, sssd, pam, ldap.conf).

Я знаю, что есть несколько способов присоединиться к домену AD. Последнее, что я пробовал, это область, которая автоматически настраивает sssd и krb5. это работает успешно, но я бы хотел только на 636. более того, мне нужно было бы немного обновить вышеупомянутое, мне интересно, в чем разница между присоединением Linux к AD через net ads join -U administrator и realm join mydomain.com ?

Есть ли способ заставить мой Linux-клиент разговаривать только с DC через порт 636? Нужно ли мне создавать сертификаты на моем клиенте Linux и утверждать его в нашем центре сертификации? Я уже импортировал сертификаты DC + корневой CA.

Спасибо за вашу помощь, С уважением

Realmd позволяет настроить AD и интеграцию клиента LDAP на вашем хосте Linux. В бэкэнде он создаст все необходимые файлы конфигурации (SSSD, krb5, PAM) и присоединится к домену.

На данный момент realmd можно использовать только для настройки AD и LDAP. Вы также можете использовать SSSD с LDAPS, но это потребует некоторой ручной и немного сложной настройки самостоятельно.

Проверьте Влияние рекомендаций Microsoft по безопасности ADV190023 | Привязка каналов LDAP и подписание LDAP при интеграции RHEL и AD. Red Hat заявила, что:

  • Они проверили, принудительно применяя привязку канала LDAP и подписывая LDAP в домене Active Directory Domain 2016 с различными сценариями, и не обнаружили никакого влияния на функциональность клиентских систем Red Hat Enterprise Linux 6, 7 и 8.
  • Конфигурация по умолчанию может привести к событию с ID 2889 на контроллере домена, но это выглядит как ложное / положительное событие журнала, которое в настоящее время исследуется.
  • Они работают над SSSD /adcli расширение, которое позволяет использовать протокол LDAPS с поставщиком активного каталога SSSD. Это позволит нам настроить интеграцию AD, как вы привыкли (realmd), но с LDAPS в бэкэнде. Этот тип конфигурации не является обязательным и необходим только в средах, где порт LDAP по умолчанию 389 закрыт. Вышеупомянутые RFE также установят GSS-SPNEGO в качестве механизма SASL по умолчанию в adcli. В настоящее время GSSAPI жестко запрограммирован в adcli и изменить нельзя.

Обновить: Вчера Red Hat выпустила RHEL 7.8 с новым adcli особенность на борту. Проверьте adcli страницы руководства Больше подробностей. В настоящее время вроде нет realm интеграция, поэтому, если вы хотите перейти на «полный LDAPS» (на порт 636), вам придется объединить adcli с ручной настройкой LDAPS в SSSD.

Нет необходимости переключаться на связь на основе TLS, когда рекомендации ADV190023 применяются на стороне AD. Демон клиента RHEL SSSD по умолчанию использует SASL при взаимодействии с серверной частью AD. SASL также может подписывать и опечатывать соединение, поэтому нет необходимости использовать TLS. В настоящее время библиотека SASL, поставляемая в RHEL, не поддерживает токены привязки каналов (работа уже завершена в восходящем направлении, и вскоре она появится в RHEL), так что вы даже столкнетесь с проблемами при переходе с SASL на порт LDAP по умолчанию 389 на порт 636 и полагаетесь на ТЛС для пломбирования и подписи соединения. Токены связывания каналов требуются только при использовании TLS.