не нужно?

керба уже всё сделала и эффективнее любой кривой(ладно, асиметричной) криптографии. Зачем ещё раз? лдапс не нужен – лдап умеет в старттлс.

порты, защищенный сертификатом ldaps

Кажется, что проще добавлять в доверенные ещё один самоподписанный сертификат, чем каждый раз генерировать keytab

Если машина в AD, то кейтаб у тебя по-любому есть. Зачем еще с какими-то сертификатами возиться?

Если машна не в AD - то используй SSSD-провайдер ldap вместо ad со своим любимым TLS, кто же тебе мешает.

А шифровать повторно то, что уже зашифровано, смысла не имеет. Более того, это не поддерживает сам AD.

Виндовые клиенты, кстати, тоже используют GSSAPI для шифрования, а не TLS.

Обычно используется STARTTLS по 336 для этого, а конкретно 636 порт оставлен для совместимости с хз чем.

Потому что в дремучем легаси лесов AD, которые развернуты еще на 2003 вендах, ldaps(точнее в 2003 его вроде как и нет еще, он с 2008 появился) по умолчанию выключен и его надо отдельно включать(о чем в логах на венде соответствующий warning имеется). И нет, простым повышением уровня домена/леса оно само не включается. Включен ли он по умолчанию в новых лесах на базе 2019 венды - без понятия, у меня тут кругом легаси.

интересно, ёщё уточнения

Если машина в AD, то кейтаб у тебя по-любому есть. Зачем еще с какими-то сертификатами возиться?

Он генерится при realm join /adcli? Или каждый раз, когда кто-то обращается к домену? Например, логинится, а кэш уже протух.

Если машна не в AD - то используй SSSD-провайдер ldap вместо ad со своим любимым TLS, кто же тебе мешает.

Мешает мне неумение отключить keytab/Kerberos-шифрование и вместо него включить LDAPS/TLS-шифрование

А шифровать повторно то, что уже зашифровано, смысла не имеет. Более того, это не поддерживает сам AD.

В документации https://www.mankier.com/8/adcli#--use-ldaps

LDAPS should only be used if the LDAP port is not accessible due to firewalls or other reasons.

Виндовые клиенты, кстати, тоже используют GSSAPI для шифрования, а не TLS.

А как убедиться в этом? Вроде было какое-то обновление?! ADV190023 https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/ldap-session-security-settings-requirements-adv190023 но я вообще ничего не понимаю из написанного там!

STARTTLS по 336 без 636

Обычно используется STARTTLS по 336 для этого, а конкретно 636 порт оставлен для совместимости с хз чем.

Где используется? В sssd? ADFS? winbind/samba?

ADFS 2019

У меня все домены новые (2016+) и я хочу чтобы всё работало безотказно, безопасно и с использованием нужных новых фишек.

Мне непонятно почему Red Hat/Fedora выбрали именно такую реализацию (ldap+Kerberos вместо TLS LDAPS)

Understanding LDAP Channel Binding and LDAP Signing in 2020

А как убедиться в этом? Вроде было какое-то обновление?! ADV190023 https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/ldap-session-security-settings-requirements-adv190023 но я вообще ничего не понимаю из написанного там!

https://www.altaro.com/vmware/understanding-ldap-binding-signing/

Он генерится при realm join /adcli? Или каждый раз, когда кто-то обращается к домену? Например, логинится, а кэш уже протух.

При вводе в домен (realm join/adcli). Кэш тут ни при чем.

Мешает мне неумение отключить keytab/Kerberos-шифрование и вместо него включить LDAPS/TLS-шифрование

Зачем? Kerberos-шифрование работает из коробки, с TLS надо подпрыгивать (сертификаты генерить там всякие и добавлять в довереннные).

В документации https://www.mankier.com/8/adcli#--use-ldaps

Под «не поддерживается» я имел ввиду Kerberos over TLS или TLS over Kerberos.

А как убедиться в этом?

Можно запустить WireShark на винде и посмотреть.

Еще случай был - виндовая команда забыла обновить сертификаты на домен-контроллерах. Виндовым клиентам пофиг, они этого даже не заметили. А все юникса накрыло (использовали тогда провайдер ldap вместо ad без ввода в домен).

В ad. Как то нужно было дебагить соединения с контролером домена,заметил что даже винда конектится по 336 порту а только потом старттлс.