Microsoft ADV190023: Как принудительно включить LDAPS на RHEL 7?
Я работаю в компании, которая работает с доменом Active Directory, работающим на Win Server 2016. У меня есть несколько серверов Linux (RHEL6) AD, интегрированных с Samba. Я читал, что Microsoft скоро выпустит обновление Microsoft ADV190023, и я работаю с RHEL 7 (8 еще не утверждены), чтобы работать с контроллерами AD только через LDAPS.
Я хочу, чтобы мой клиент Linux разговаривал только с контроллером домена на целевом порту 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 страницах руководства . В настоящее время, похоже, нет интеграции области , поэтому, если вы хотите перейти на «полный LDAPS» (на порт 636), вам придется объединить adcli с ручной настройкой LDAPS в SSSD.
Нет необходимости переключаться на связь на основе TLS, если рекомендации ADV190023 применяются на стороне AD. Демон клиента RHEL SSSD использует SASL по умолчанию при общении с серверной частью AD. SASL также может подписывать и запечатывать соединение, чтобы не было необходимости использовать TLS. В настоящее время библиотека SASL, поставляемая в RHEL, не поддерживает токены привязки канала (хотя работа уже завершена в восходящем направлении и вскоре появится в RHEL), так что вы даже столкнетесь с проблемами при переходе с SASL на порт LDAP по умолчанию 389 на порт 636 и полагаться по TLS для опечатывания и подписи соединения. Токены привязки канала требуются только при использовании TLS.