По-умолчанию в Active Directory трафик по протоколу LDAP между контроллерами домена и клиентами не шифруется, т.е. данные по сети передаются в открытом виде. Потенциально это означает, что злоумышленник с помощью снифера пакетов может прочитать эти данные. Для стандартной среды Windows среды это в общем-то не критично, но ограничивает возможности разработчиков сторонних приложений, которые используют LDAP.
Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.
Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.
В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).
Отметим, что LDAPS преимущественно используется сторонними приложениями (имеются в виде не-Microsoft клиенты) в целях защиты передаваемых по сети данных (обеспечить невозможности перехвата имена и паролей пользователей и других приватных данных).
Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.
На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage. 
Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template. 
На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory). 
На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.
На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.
Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.
На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).
В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).
Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.
Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
certutil -ca.cert ca_name.cer
А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).
certmgr.exe -add C:\ca_name.cer -s -r localMachine ROOT
Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.
Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.
А как активировать на Windows 2008R2 ? Я делал по оф. статье с сайта Microsoft, однако порт ldap 389 по-прежнему доступен. (если проверять утилитой LDP) По 636 правда тоже авторизует, однако в статье говорится о том, что после выполнения настройки должно пускать только по 636.
На самом деле при настройке SSL сертификата, большая часть LDAP трафика продолжает бегать по 389 порту. Однако при выполнении ряда LDAP-запросов, критичных с точки зрения конфиденциальности, используется безопасное шифрованное соединение по 636 порту.
Хм, я ожидал, что весь трафик будет шифрованным.
«Однако при выполнении ряда LDAP-запросов, критичных с точки зрения конфиденциальности, используется безопасное шифрованное соединение по 636 порту.» — Я надеюсь авторизация под это правило подпадает? Мне главное чтобы учетные данные в открытом виде не передавались.
Спасибо за ответ 🙂
C Win7 и Win2008 проблем не будет?
Какие требования к внедрения, «подводные камни»?
Особых проблем быть не должно. Главное — корректно настроить корпоративный CA и доверие к нему со стороны клиентов (импортировать корневой сертфикат)
доброго дня, спасибо большое за статью.
Она актуальна для 2008r2?
Windows XP будут работать в домене 2008r2 после этих действий?
Еще, если на КД развернуть CA то домен потом уже не переименуешь?
«На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).»
Проделать нуно на всех DC?
Да, сертфикат нужно будет установить на каждом DC, где вы хотите использовать LDAPS
Огромное спасибо!
На AD2016 все заработало, необходимо было c недоменных linux машин управлять юзерами через ldaputils
Можно уточнить — для чего нужно делать ключ шаблона экспортируемым?
Тут все зависит от постановки задачи. Если вам не нужно экспортировать сертификаты, вы можете указать это в шаблоне.
Здравствуйте,
Сертификат авторити стоит на ДК 2016 на нем же применил ваше руководство, после на Windows 10 который не в домене , скопировал сертификат. По телнету порт 636 открывается но программа ldp выдает ошибку » Не удается открыть подключение»
ld = ldap_sslinit(«10.0.38.169», 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error:
Error : Fail to connect to 10.0.38.169.
Подскажите пожалуйста
Спасибо
DC перезагружали? Пробовали через ldp.exe подключиться на 636 порт локально с самого контроллера домена (может бытьу вас firewall блокирует доступ?.
DC перегружал. Пробовал через ldap.exe на порт 636 ssl не отработало. Файрвол выключен.
Затем ввел Win10 в домен, ldp.exe 636 сработал. Получается ldaps правильно настроен, значит сертификата не хватает или еще чего то когда Win10 не в домене.
Когда комп не в домене, доменный центр сертификации для него не доверенный. Судя по поведению вин10 вы не установили на ней серты СА, а без них серт контроллера не пройдёт проверку и SSL не установиться.
Если соединение с DC по 636 через ldp.exe устанавливается, а с веб интерфейса принтера при переключении с 389 на 636 тест перестаёт работать, значит ли это что с сертификатом всё ок, или наоборот проблема в нём?
Тут скорее всего загвоздка в том, что принтер не доверяет вашему SSL сертификату.
И как с этим бороться?
утилита ldp после проделанного по инструкции подключается и по ssl 636, и по незашифрованному 389. А возможно ли использовать ssl для некоторых серверов (на linux), а windows клиенты пусть по незашифрованному? можно ли просто не устанавливать корневой сертификат на win-клиентах?
Добрый день, на шаге
нет в списке сертификата LDAPoverSSL, подскажите, пожалуйста что не так?
У меня тоже самое.
Здесь написано что защищённое соединение должно проходить по 636 Port. Но IIS продолжает ходить по 389 порту, при том что на контроллере стоит запрет на не защищённую авторизацию. При этом ldp по 389 не проходит.
Статья правильная, но с ошибками. Практически ничего из этого делать не нужно. Достаточно на всех DC выпустить сертификат по шаблону «Kerberos Authentication». Он по-умолчанию на автопродлении, поэтому DC будут сами его продлевать в дальнейшем. Делать будликат шаблона, разрешать публикацию сертификата в AD и экспорт приватного ключа абсолютно не нужно. Я так понимаю, что исходную информацию вы взяли отсюда — https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx. Там делается дубль шаблона свозможностью экспорта ключа, чтобы на одном DC выпустить сертификат, а после выгрузив его в pfx импортировать по остальным. В их статье это имеет смысл, в вашей потеряло.
Вы абсолютно права. Не то что бы практически ничего, а вообще ничего из этой статьи делать не нужно. Ну разве только проверить и убедиться что LDAP over SSL и так уже работает.
Вводите людей в заблуждение.
Для контроллера домена надо сделать серт по шаблону Domain Controller Authentication (Kerberos). Ибо по умолчанию у него будет только серт обычного сервера, LDAPS с таким работать не будет.
Экспортируемый или нет — на свой вкус. Учитывая что к АД будет коннектиться всё что ни попадя, нам полезно, иб все системы требует научить ssl при работе с каталогом.
Я правильно понимаю, что сделать, что бы вся сеть работала только по LDAPS невозможно? Так и так часть трафика будет идти по LDAP?
И если я буду коннектиться на другой сервер, к примеур WSUS, там будет использоваться LDAPS, который я раскрутил на DC?
для учётных данных будет использован ssl. Большинство трафика просто лдап.
Хотите шифровать весь трафик, всю сеть — поднимайте IPsec, бессмысленное занятие с сильной утилизацией ресурсов.
Важное замечание для тех, кто проверяет локально , с контроллера домена. Т.к. оснастка ldap.exe запускает под пользователем — сгенерированный сертификат необходимо поместить в хранилище пользователя, это касается команды выше