none
Размышления о LDAP Channel Binding and LDAP Signing Requirements RRS feed

  • Общие обсуждения

  • Коллеги, приветствую.

    В последние дни активно популяризируется вопрос LDAP Channel Binding and LDAP Signing Requirements в интернете. Однако, всё больше убеждаюсь в том, что вопрос скорее не понятен, чем понятен. Чудо эксперты в профилированных телеграм-чатах и сайтах-блогах умолкают, как только появляется вопрос, отстоящий от общей рекомендации MS.

    Знаю, что technet помимо грамотных людей, бывают mvp и прочие уважаемые личности, потому, попробую задать свои вопросы здесь.

    Вводная. Отталкиваюсь от рекомендаций - https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536

    Здесь всё понятно. Включаем расширенный debug level и начинаем ловить события.

    В моём случае, в логи по event id 2889 я вижу лишь сторонние неMICRISOFT сервисы (их даже упоминать не буду, лишнее).

    Ни одного события от серверов и пользовательских станциях в событиях не вижу. К слову, сервера - только линейка 2012r2и 2016. АРМ - преимущественно Windows10. Есть 7ки, но их порядка десятка.

    Следую дальше рекомендациям и смотрю политики, которые рекомендуется заранее применить до получения исправления (для клиентов и контроллеров).

    Сходу натыкаюсь на "Сетевая безопасность: Требование цифровой подписи LDAP клиента". В самом описании политики дано описание значения по умолчанию:

    Значение по умолчанию: "Согласование цифровой подписи".
    Т.е. верно ли я понимаю, что уже априори все объекты доменной среды (Компьютеры и Серверы) делают запрос к ldap с подписью? Т.е. изменение политики принудительного требования подписи со стороны контроллера доменов на авторизацию компьютеров (в моём случае) не скажется? Можно ли это как-то отдельно проверить , какие станции ходят с подписью? Возможно, используя какой-то расширенный лог?

    С политикой безопасности контроллеров всё понятно. Можно только включить принудительное требование подписи.

    4 февраля 2020 г. 4:59

Все ответы

  • Почитайте здесь.

    Всё доступно написано.

    4 февраля 2020 г. 6:46
  • Почитайте здесь.

    Всё доступно написано.

    Доступно, но алгоритм я не понимаю.

    На данный момент на контроллерах отключена требование цифровой подписи ("нет").

    На клиентах установлена - "Согласование цифровой подписи".

    По регламенту предлагается следующее (до получения мартовских обновлений):

    - На контроллерах отключить требование цифровой подписи (она и так отключена)

    - На клиентах отключить требование цифровой подписи.

     LDAP Channel Binding = 1 - что это за параметр?

    Отключения требований не поломают систему взаимодействия.

    Март:

    - Политика на контроллерах включится с обновлением.

    - Почему мы ничего не включаем для клиентов? Если обновление клиентских ОС должно включить это параметр, то нужно как-то сначала обеспечить всех клиентов обновой, проследить за этим.

    В противном случае доверительные отношения поломаются. Почему тогда предварительно не включить параметр для клиентов?

    Вот если честно, я логики в этом алгоритме не вижу.

    Поясните, пожалуйста, если для вас она прозрачна.

    4 февраля 2020 г. 7:44
  • Почитайте здесь.

    Всё доступно написано.

    действительно, не понимаю панику... ну включится LDAPS принудительно, ну и что? А вы (не конкретно Вы, Алексей) всё ещё используете LDAP? несекурно...

    - Почему мы ничего не включаем для клиентов?

    потому что в последних Windows уже всё включено - согласование. Если контроллер не требует подписи - значит будет использован LDAP, если контроллер требует подпись - LDAPS.

    Хотя я вот тут подумал, ладно с Windows понятно, но что делать с не-MS продуктами? Кроме как ручного выпуска сертификата другого решения я не вижу.

    4 февраля 2020 г. 9:11
    Модератор
  • Почитайте здесь.

    Всё доступно написано.

    действительно, не понимаю панику... ну включится LDAPS принудительно, ну и что? А вы (не конкретно Вы, Алексей) всё ещё используете LDAP? несекурно...

    - Почему мы ничего не включаем для клиентов?

    потому что в последних Windows уже всё включено - согласование. Если контроллер не требует подписи - значит будет использован LDAP, если контроллер требует подпись - LDAPS.

    Хотя я вот тут подумал, ладно с Windows понятно, но что делать с не-MS продуктами? Кроме как ручного выпуска сертификата другого решения я не вижу.

    Стоп-стоп)

    Вы разницу между LDAPs и цифровой подписью ощущаете?)

    LDAPs у меня есть, он чудестно работает и отвечает по 636 порту. Параллельно работает LDAP.

    Здесь речь идёт о включении "требования цифровой подписи для LDAP-сервера"

    Даю прям описание из политики.

    "Этот параметр безопасности определяет, будет ли LDAP-сервер требовать согласовывать подписывание с LDAP-клиентами следующим образом:

    Нет: для привязки к серверу подписывание данных не требуется. Если клиент запросит подписывание данных, сервер его поддержит.
    Требовать подпись: если не используется TLS\SSL, параметр подписывания данных LDAP должен быть согласован.
    По умолчанию: параметр не определен, это имеет тот же эффект, что и "Нет".

    Внимание!
    Если сервер настроен на "Требовать подпись", соответственно должен быть настроен и клиент. Если клиент не настроен, связь с сервером будет утеряна."

    В последних Windows включено согласование цифровой подписи, верно. Но нужно включить требование. Опять же, даю справку:

    Этот параметр безопасности определяет уровень подписи данных, который запрашивается от имени клиентов, отправляющих запросы LDAP BIND, следующим образом.

    Нет: запрос LDAP BIND отправляется с параметрами, указанными вызывающей стороной.
    Согласование цифровой подписи: если службы TLS и SSL не запущены, запрос LDAP BIND создается с набором параметров подписи данных LDAP в добавление к параметрам, указанным вызывающей стороной. Если службы TLS и SSL запущены, запрос LDAP BIND создается с параметрами, указанными вызывающей стороной.
    "Требовать подпись": то же, что и "Согласование цифровой подписи". Однако если промежуточный ответ saslBindInProgress LDAP-сервера не показывает, что требуется подпись трафика LDAP, вызывающая сторона получает сообщение о том, что запрос команды LDAP BIND завершился с ошибкой.

    Внимание

    Если на сервере задано значение "Требовать подпись", на клиенте значение должно быть таким же. Если на клиенте не задано такое же значение, это приведет к потере подключения к серверу.

    Примечание. Этот параметр не оказывает влияния на ldap_simple_bind или ldap_simple_bind_s. Клиенты Microsoft LDAP в составе Windows XP Professional не используют ldap_simple_bind или ldap_simple_bind_s для взаимодействия с контроллером домена.

    Значение по умолчанию: "Согласование цифровой подписи".
    Если верить регламенту, то всё это нужно включить (ну либо получить с обновами). Иначе, если, например, сервер имеет настройку, а клиент нет (пк был выключен, в отпуске), то он теряет доверительные отношения.

    Да, со сторонними продуктами полная беда. Пока я логами поймал сервисы с ldap авторизацией - squid, dokuwiki, bitrix.

    4 февраля 2020 г. 9:25
  • Стоп-стоп)

    Вы разницу между LDAPs и цифровой подписью ощущаете?)

    сложный вопрос... Но в обоих случаях используются доверенные сертификаты. И на клиенте такой сертификат, я думаю, будет из шаблона "Компьютер", который во многих компаниях распространяется на клиентах автоматически.
    В последних Windows включено согласование цифровой подписи, верно. Но нужно включить требование. Опять же, даю справку
    требование включается на сервере, чтобы он не принимал неподписанные запросы.
    Да, со сторонними продуктами полная беда. Пока я логами поймал сервисы с ldap авторизацией - squid, dokuwiki, bitrix.
    Я отправил ссылку нашему ИБ. Пусть развлекаются со своим прокси на шлюзе )))
    4 февраля 2020 г. 9:46
    Модератор
  • сложный вопрос... Но в обоих случаях используются доверенные сертификаты. И на клиенте такой сертификат, я думаю, будет из шаблона "Компьютер", который во многих компаниях распространяется на клиентах автоматически.

    Всё верно. В моём случае, как и в общем почти у всех - сертификат CA раздаётся внутри домена - доверенным ЦС.

    В последних Windows включено согласование цифровой подписи, верно. Но нужно включить требование. Опять же, даю справку

    Судя по алгоритмам, на клиентах тоже нужно включать. Если следовать по статье, которую дали выше.

    требование включается на сервере, чтобы он не принимал неподписанные запросы.

    Тоже вариант. Но я это к тому, что бездумно всё подряд включать не стоит, потому что можно лишиться сервисов.

    По сути, так никто и не сказал, что бы что-то сделали и что-то заработало. Потому, вопрос открыт.

    4 февраля 2020 г. 9:58
  • действительно, не понимаю панику... ну включится LDAPS принудительно, ну и что? А вы (не конкретно Вы, Алексей) всё ещё используете LDAP? несекурно...

    Странно, что вы не понимаете. Для LDAPS требуются сертификаты КД - а сами они в сети ниоткуда не возьмутся. Для получения сертификатов нужно либо разворачивать где-то в сети AD CS в режиме Enterprise (тогда КД запросят нужные сертификаты сами, и доверие клиентов будет автоматически обеспечено) - а это ресурсы, либо брать откуда-то сертификаты для КД и обеспечивать к ним доверие клиентов (со всем вытекающим гемороем в виде обеспечения доверия и доступа к спискам отзыва).

    Короче, Microsoft тут действует как тот пионер-тимуровец из советского анекдота, который помог перейти бабушке через улицу, хотя она туда совсем не хотела. Потому что риск этих атак в типичной "купи-продай" фирмочке - он реально нулевой, как и последствия атаки  - если хоть чуть-чуть приложить голову и для доступа к LDAP в сторонних продуктах не использовать аутентификацию под обычнм пользователем, а не админом домена.

       

    Слава России!



    • Изменено M.V.V. _ 4 февраля 2020 г. 11:29
    4 февраля 2020 г. 11:06
  • Как мне кажется, я знаю способ сделать так, чтобы это "повышение безопасности ничего не сломало". Копирую свой комментарий с другого ресурса по этому поводу:

    Меняется всего лишь поведение по умолчанию, которое можно
    переопределить. Microsoft, конечно, не хочет обращать на это внимание — и
    в результате появляется совершенно невнятная рекомендация по
    безопасности ADV190023
    — но возможность отказаться от этой, типа, заботы о нас (заботы типа
    «помог перейти старушке через улицу, хотя этой ей туда совсем не надо
    было») таки существует: достаточно внимательно прочитать статьи MS KB по
    ссылкам в рекомендации — 1 и 2 а также статью из блога, касающуюся этого обновления

    Для этого нужно установить два значения типа DWORD в реестре (привожу
    для AD DS, для AD LDS нужно вместо NTDS подставить имя экземпляра):

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding=0
    — чтобы отключить требование Channel Binding

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity=0
    — чтобы отключить требование LDAP Signing

    Если этих значений нет — надо их создать. Второе значение для AD DS
    контролируется ещё и групповой политикой Computer Configuration\Windows
    Settings\Security Settings\Local Policies\Security Options\Domain
    controller: LDAP server signing requirements, и сейчас там (по крайней
    мере — в свежем домене на Win2012 R2) по умолчанию в Default Domain
    Controller Policy стоит отключение требования, что выливается в значение
    ключа =1, из-за чего после обновления требование LDAP Signing реально
    будет применяться. Однако, согласно статье в блоге, установка указанного
    параметра в 0 приведет к тому, что этого после обновления требования
    LDAP Signing не будет. Как это будет реализовано — я таки не понял.
    Потому думаю, что на всякий случай, этот параметр политики надо
    поставить в положение Отключено а нужное (=0) значение — установить
    напрямую в реестре на всех КД.

    Думаю однако, что после появления обновления всё это надо будет, на всякий случай, протестировать на стенде.


    Слава России!

    4 февраля 2020 г. 11:09
  • Странно, что вы не понимаете. Для получения сертификатов нужно либо разворачивать где-то в сетиAD CSв режиме Enterprise 

    И в чём проблема развернуть свой собственный CA? Это что, какой-то архи-сложный и требовательный сервис? Вот чего мы не понимем, что люди боятся СА как огня, что он их покусает.
    4 февраля 2020 г. 11:20
    Модератор

  • И в чём проблема развернуть свой собственный CA? Это что, какой-то архи-сложный и требовательный сервис? Вот чего мы не понимем, что люди боятся СА как огня, что он их покусает.
    Вы слишком далеки от простых админов из российской глубинки: для них даже порой "домен" - это нечто запредельно сложное. 

    Слава России!

    4 февраля 2020 г. 11:28

  • И в чём проблема развернуть свой собственный CA? Это что, какой-то архи-сложный и требовательный сервис? Вот чего мы не понимем, что люди боятся СА как огня, что он их покусает.

    Вы слишком далеки от простых админов из российской глубинки: для них даже порой "домен" - это нечто запредельно сложное. 
    понимаю...
    4 февраля 2020 г. 11:33
    Модератор
  • И в чём проблема развернуть свой собственный CA? Это что, какой-то архи-сложный и требовательный сервис? Вот чего мы не понимем, что люди боятся СА как огня, что он их покусает.

    Не шумите) CA есть. Раздаётся в доверенные станциям домена. В этом проблем нет. Сам LDAPs работает.

    Суть лишь в том, что до конца не понятно, решает ли использование LDAPs всю описанную проблему.

    Как мне кажется, я знаю способ сделать так, чтобы это "повышение безопасности ничего не сломало". Копирую свой комментарий с другого ресурса по этому поводу:
    Спасибо за рекомендацию. Действительно нужно тестировать и смотреть как это скажется на систему, но уже в свете того, как на стенды можно будет загрузить новые обновления (собственно, март)

    4 февраля 2020 г. 11:33
  • Суть лишь в том, что до конца не понятно, решает ли использование LDAPs всю описанную проблему.
    Обычно такие критические обновления тестируются, например на виртуальных машинах. Если там всё работает - устанавливается на рабочие сервера.
    4 февраля 2020 г. 11:36
    Модератор
  • Обычно такие критические обновления тестируются, например на виртуальных машинах. Если там всё работает - устанавливается на рабочие сервера.

    Само собой разумеется. Но не плохо вообще быть готовыми и понимать суть вопроса.

    Пока же, я вижу, что описательная часть такого "критического" обновления описана крайне скудно.

    4 февраля 2020 г. 11:47
  • Исключительно для теста в лаборатории, состоящей из DC (1шт) и PC (1 шт) выполняю следующее:

    1. Включают требование подписи на DC;

    2. Отдельной gpo для PC ставлю "нет" в требовании цифровой подписи для LDAP.

    Так же на DC LdapEnforceChannelBinding=1 в реестре, согласно https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

    Само собой перезапускаю обе станции.

    Полагал, что будет имитироваться ситуация, когда компьютер не сможет авторизоваться в AD.

    Однако, авторизация проходит без проблем, лишь в расширенный лог приходит событие о привязке без запроса подписи.

    Собственно, тогда не понимаю, почему оно не сломалось?


    • Изменено DmitryG_ 5 февраля 2020 г. 10:10
    5 февраля 2020 г. 8:54
  • Никто у себя так и не проверял в тестовой среде?
    10 февраля 2020 г. 3:59
  • Дела сие ещё лет пять назад, но всё пришлось вернуть в зад из-за клиентов/серверов не умеющих LDAPS

    Компы и сервера не отваливались.

    12 февраля 2020 г. 12:02
  • Дела сие ещё лет пять назад, но всё пришлось вернуть в зад из-за клиентов/серверов не умеющих LDAPS

    Компы и сервера не отваливались.

    Тогда не сильно с документацией сходится. (
    17 февраля 2020 г. 8:04
  • FAQ

    LDAP clients that connect over SSL/TLS, but do not provide CBT, will fail if the server requires CBT.
    1 марта 2020 г. 0:08
    Модератор