Настройка ldap windows server 2012 r2

Обновлено: 05.07.2024

В последнее время, из-за потребностей проекта, нам нужно настроить сервер LDAP для тестирования и записать его.

Установка: Это относительно просто, далее весь порт по умолчанию - 389, секретный пароль сервера по умолчанию для LDAP, база данных фонового механизма - BDB (Berkeley DataBase);

Учетная запись администратора LDAP. Эта учетная запись может использоваться для добавления, удаления и изменения записей в LDAP. Это более важно и является независимо настроенным файлом. Найдите файл slapd.conf в каталоге установки OpenLDAP и измените

Суффикс является префиксом DN, и все записи LDAP, добавленные после него, должны принадлежать этому пути.

Rootdn указывает администратора, а имя администратора - Manager, который также должен следовать по полному пути, аналогичному имени пакета JAVA.

Windows поддерживает два метода запуска: сервис и CLI. Для отладки и просмотра выходных данных журнала мы используем метод CLI для запуска, сначала останавливаем службу LDAP, которая была запущена в службе Windows, а затем используем slapd для запуска каталога LDAP. Другие статьи в Интернете могут быть запущены без указания файла slapd.conf. Не проверено, команда, которую я могу запустить здесь:

-F указывает информацию, считанную в slapd.conf, а -d относится к уровню отладки. После запуска интерфейса:

После успешного запуска это пустой LDAP. Нам нужно импортировать некоторые тестовые данные. LDAP может импортировать дерево каталогов через файл LDIF. Команда import для нашей версии Windows - через команду slapadd.

Что мне нужно, так это группа, и в ней есть несколько пользовательских структур. Файл LDIF этой структуры выглядит следующим образом:

Вставьте и сохраните вышеуказанное содержимое в файл user3.ldif и импортируйте его через slapadd -v -l ./user3.ldif:

Редактировать файл ldif вручную сложно. Мы можем управлять LDAP графически с помощью стороннего инструмента ldapadmin.

После установки войдите на наш сервер LDAP, интерфейс настройки выглядит следующим образом:

Последние очень просты, добавьте их графически.

Класс Object хранит имена DN каждого пользователя в атрибутах groupOfNames, memeber.

Эта статья взята из " Чжу Кунронг "Блог, пожалуйста, держите этот источник

В этой статье описывается, как включить подписание LDAP в Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 и Windows 10.

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 — все выпуски
Исходный номер КБ: 935834

Сводка

Вы можете значительно повысить безопасность сервера каталогов, настроив сервер для отказа от привязки LDAP простой проверки подлинности и безопасности (SASL), которые не запрашивают подписи (проверка целостности) или отклонить простые привязки LDAP, выполняемые на понятном текстовом (не-SSL/TLS-зашифрованном) соединении. Привязки SASL могут включать такие протоколы, как Negotiate, Kerberos, NTLM и Digest.

Неподписаный сетевой трафик подвержен атакам повторного воспроизведения. В таких атаках злоумышленник перехватывает попытку проверки подлинности и выдачу билета. Злоумышленник может повторно использовать билет, чтобы выдать себя за законного пользователя. Кроме того, неподписавшийся сетевой трафик подвержен атакам "человек в центре" (MIM), в результате которых злоумышленник захватывает пакеты между клиентом и сервером, изменяет пакеты и затем передает их на сервер. Если это происходит на сервере LDAP, злоумышленник может заставить сервер принимать решения, основанные на поддельных запросах клиента LDAP.

Обнаружение клиентов, которые не используют параметр Обязательное подписание

После изменения конфигурации клиенты, которые полагаются на неподписаемые SASL (Negotiate, Kerberos, NTLM или Digest), привязывает LDAP или просто связывается с подключением, не относящемся к SSL/TLS, перестают работать. Чтобы помочь определить этих клиентов, сервер каталогов служб домена Active Directory (AD DS) или Lightweight Directory Server (LDS) регистрирует сводный ИД события 2887 один раз в 24 часа, чтобы указать, сколько таких связей произошло. Мы рекомендуем настроить этих клиентов, чтобы не использовать такие привязки. После того, как такие события не наблюдаются в течение длительного периода времени, рекомендуется настроить сервер, чтобы отклонить такие привязки.

Если для идентификации таких клиентов необходимо иметь дополнительные сведения, можно настроить сервер каталогов для предоставления более подробных журналов. Этот дополнительный журнал будет входить в журнал Event ID 2889, когда клиент пытается сделать неподписавую привязку LDAP. Запись журнала отображает IP-адрес клиента и удостоверение, которое клиент пытался использовать для проверки подлинности. Этот дополнительный журнал можно включить, установив диагностический параметр 16 событий интерфейса LDAP до 2 (Basic). Дополнительные сведения о том, как изменить параметры диагностики, см. в рубке How to configure Active Directory and LDS diagnostic event logging.

Если сервер каталогов настроен на отказ от неподписаных связей LDAP SASL или простого привязки LDAP по подключению, не подключенным к SSL/TLS, сервер каталога регистрирует сводный ИД события 2888 один раз в 24 часа при таких попытках привязки.

Настройка каталога для необходимости подписания сервера LDAP для AD DS

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

Аномалия журнала событий 2889

Приложения, которые используют сторонние клиенты LDAP, Windows создавать неправильные записи event ID 2889. Это происходит при журнале событий интерфейса LDAP и при LDAPServerIntegrity равном 2. Использование уплотнения (шифрования) удовлетворяет защиту от MIM атаки, но Windows журналы Event ID 2889.

Это происходит, когда клиенты LDAP используют только герметику вместе с SASL. Мы видели это в поле в связи с сторонними клиентами LDAP.

Если подключение не использует как подписание, так и герметику, проверка требований к безопасности подключения использует флаги правильно и отключается. Проверка создает ошибку 8232 (ERROR_DS_STRONG_AUTH_REQUIRED).

Использование групповой политики

Настройка требования к подписи сервера LDAP

Как установить требование подписи клиента LDAP с помощью локальной компьютерной политики

Как установить требование подписи клиента LDAP с помощью объекта групповой политики домена

Как установить требование подписи клиента LDAP с помощью ключей реестра

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

По умолчанию для служб легкого каталога Active Directory (AD LDS) ключ реестра недодоступн. Поэтому необходимо создать запись реестра типа REG_DWORD в следующем подкайке LDAPServerIntegrity реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ <*InstanceName> *\Параметры

Местообладатель представляет имя экземпляра <InstanceName> AD LDS, который необходимо изменить.

Проверка изменений конфигурации

Во входе на компьютер с установленными средствами администрирования AD DS.

Выберите > запуск, введитеldp.exe, а затем выберите ОК.

Выберите подключение > Подключение.

В Сервере и в порту введите имя сервера и не-SSL/TLS-порт сервера каталогов, а затем выберите ОК.

Для контроллера домена Active Directory применимый порт — 389.

После подключения выберите привязку > подключения.

В типе Bind выберите Простое связывать.

Введите имя пользователя и пароль, а затем выберите ОК.

Ldap_simple_bind_s() не удалось: требуется сильная проверка подлинности

ПРИМЕЧАНИЕ. Следующие шаги аналогичны для Windows Server 2008, 2012, 2012 R2, 2016. В этой статье мы будем использовать Windows Server 2012 R2.

Создайте виртуальную машину Windows Server в Azure

Создайте виртуальную машину с именем «ldapstest» Windows Server 2012 R2 Datacenter Standard DS12, следуя инструкциям здесь: Создание виртуальной машины Windows с порталом Azure
Подключитесь к ldapstest виртуальной машины с помощью подключения к удаленному рабочему столу.

Настройка LDAP с использованием AD LDS

Отметьте службы Active Directory облегченного доступа к каталогам из списка ролей и нажмите Далее.

Нажмите «Установить», чтобы начать установку.

Выберите уникальный экземпляр, так как мы настраиваем его впервые.

Введите «CONTOSO» в поле «Имя экземпляра» и нажмите «Далее».

Выбор учетной записи сетевой службы для запуска службы AD LDS.

Вы получите быстрое предупреждение о репликации данных. Поскольку мы используем один сервер LDAP, мы можем нажать Да.

Убедитесь, что все выбраны правильно, а затем нажмите Далее, чтобы подтвердить установку..

После успешной настройки экземпляра нажмите Готово.

Теперь давайте попробуем подключиться к экземпляру AD LDS CONTOSO с помощью ADSI Edit.
Щелкните Пуск -> Найдите «Редактор ADSI» и откройте его.
Щелкните правой кнопкой мыши папку редактирования ADSI (на левой панели) и выберите «Подключиться к ..». Заполните следующие значения и нажмите OK.

Если соединение установлено успешно, мы сможем просматривать каталог CN = MRS, DC = CONTOSO, DC = COM:

Настройка LDAPS (LDAP через SSL)

Сертификат, который будет использоваться для LDAPS, должен удовлетворять следующим трем требованиям:
• Сертификат должен быть действительным для целей аутентификации сервера. Это означает, что он также должен содержать идентификатор объекта аутентификации сервера (OID): 1.3.6.1.5.5.7.3.1
• Имя субъекта или имя в альтернативном имени субъекта (SAN) должно соответствовать полному Полное доменное имя (FQDN) хост-компьютера, например Subject: CN = contosoldaps. Для получения дополнительной информации см. Как добавить альтернативное имя субъекта к защищенному сертификату LDAP.
• Учетная запись хост-компьютера должна иметь доступ к закрытому ключу.

Теперь давайте воспользуемся службами сертификации Active Directory, чтобы создать сертификат, который будет использоваться для LDAPS. Если у вас уже есть сертификат, отвечающий вышеуказанным требованиям, вы можете пропустить этот шаг.

Выберите «Службы сертификации Active Directory» из списка ролей и нажмите «Далее».

Ничего не выбирайте из списка функций и нажмите Далее.

Отметьте «Центр сертификации» в списке ролей и нажмите «Далее».

Нажмите «Установить», чтобы подтвердить установку.

Выбрав корневой ЦС в качестве типа ЦС, нажмите Далее.

ОБНОВЛЕНИЕ: рекомендуется выбрать самый последний алгоритм хеширования с момента обратного отсчета устаревания SHA-1

Имя CA должен соответствовать имени хоста (требование номер 2). Введите «LDAPSTEST» и нажмите «Далее».

После успешной/полной настройки. Щелкните Close.

Теперь давайте просмотрим сгенерированный сертификат.

Нажмите «Пуск», выберите «Поиск» «Управление сертификатами компьютеров» и откройте его.

Щелкните «Личные сертификаты» и убедитесь, что сертификат «LDAPSTEST» присутствует:

Теперь выполните третий требование, позвольте нам убедиться, что учетная запись хост-машины имеет доступ к закрытому ключу. С помощью служебной программы Certutil найдите уникальное имя контейнера. Откройте командную строку в режиме администратора и выполните следующую команду: certutil -verifystore MY

Закрытый ключ будет находиться в следующем месте C: ProgramData Microsoft Crypto Keys

Нам нужно импортировать этот сертификат в хранилище ключей JRE, поскольку наш сертификат CN = LDAPSTEST не подписан ни одним доверенным центром сертификации (CA ), который настроен в вашем хранилище ключей JRE, например, Verisign, Thwate, goDaddy или entrust и т. д. Чтобы импортировать этот сертификат с помощью утилиты keytool, давайте сначала экспортируем этот сертификат как .CER из хранилища сертификатов машины:

Нажмите Пуск -> Найдите «Управление сертификатами компьютеров» и откройте его. Откройте личное, щелкните правой кнопкой мыши сертификат LDAPSTEST и нажмите «Экспорт».

Нажмите Готово, чтобы завершить экспорт сертификата.

Сертификат теперь успешно экспортирован в «C: Users azureuser Desktop ldapstest.cer».

Теперь мы должны импортировать его в JRE Keystore, используя команду keytool, находящуюся в этом месте:

C: Program Files Java jre1.8.0_92 bin keytool.exe.

Введите «да» в запрос «Доверять этому сертификату» .

После успешного добавления сертификата в хранилище ключей JRE мы можем подключиться к серверу LDAP через SSL.

Теперь давайте попробуем подключиться к серверу LDAP (с SSL и без него) с помощью инструмента ldp.exe.

Строки подключения для

LDAP: \ ldapstest: 389

LDAPS: \ ldapstest: 636

Нажмите Пуск -> Поиск ldp.exe -> Подключение, введите следующие параметры и нажмите ОК для подключения:

Чтобы подключиться к LDAPS (LDAP через SSL), используйте порт 636 и отметьте SSL. Нажмите ОК, чтобы подключиться.

ССЫЛКИ

Отличное руководство! Спасибо!

Я не понимаю, почему он импортирует сертификат в java truststore. Инструмент ldp.exe использует java?

@zhongyi_yang Я тоже хотел бы знать об этом.

Доверенное хранилище java немного странно, если учесть Java. Есть ли другой способ импортировать это?

Как я могу найти сервер LDAP в DNS в Windows?

Для Linux эта команда должна возвращать запись DNS для сервера LDAP

(найдено в разделе «Аутентификация с Java (Linux) в Active Directory с использованием LDAP БЕЗ имени сервера»)

Как я могу получить то же самое в командной строке Windows с помощью nslookup?

Россия

размер шрифта уменьшить размер шрифтаувеличить размер шрифта
Печать
Эл. почта
Станьте первым комментатором!

Microsoft Active Directory поддерживает протокол LDAPv3. С его помощью можно авторизовать пользователей из сторонних приложений. Чтобы обеспечить безопасность при передаче учетной информации серверу необходимо использовать LDAPS (SSL). В этой статье мы рассмотрим настройку контролера доме, для обеспечения поддержки SSL.

Для того, чтобы SSL нормально функционировал нам потребуются сертификат.

Проверяем наличие сертификата

Для начала будет полезно проверить наличие сертификата в вашем домене, для этого запустим на нашем ПК утилиту ldp.exe.

Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.

Нажмите Подключение - подключить, заполните окно аналогично рисунку.

Используйте имя домена, не сервера - тогда сервер для подключения будет выбран автоматически.

Это означает, что либо недоступен ни один контролер домена, либо неправильно настроен DNS, либо ПК не является членом домена, либо не установлен SSL сертификат на контролере домена.

Это значит, что SSL сертификат уже установлен посредством Службы сертификатов Active Directory и дальнейших действий не потребуется.

Установка OpenSSL

В этой статье я буду использовать виртуальный сервер, созданный для цикла статей.

Имя домена - altununvv.local

Имя контролера домена – addc1.altuninvv.local

Виртуальная организация - Altunin Soft

Я рекомендую все команды выполнять сразу на сервере, но вы можете так же работать и на вашем ПК, если используете MSYS2.

Те, кто использует, как и я, MSYS2, могут ввести в консоли:

Создаем локальный центр сертификации

Создадим папку и назовем её CA.

Создадим в ней файл ca.conf с содержимым:

Сгенерируем приватный ключ для CA

Укажите пароль для ключа, в нашем случае это будет Pa$$w0rd :

Создадим сертификат для нашего CA:

Просто нажимайте Enter все поля будут заполнены автоматически!

Теперь нужно импортировать созданный сертификат в хранилище доверенных CA на нашем контролере домена.

Скопируем файл ca.crt на контролер домена. Откроем PowerShell от имени администратора, перейдем в папку с файлом ca.cert и введем команду:

Сертификат успешно добавлен.

Теперь пришло время создать запрос на клиентский сертификат, который будет использовать контролер домена.

На контролере домена создадим текстовый файл - req.txt

Выполним запрос на сертификат:

Скопируем созданный файл на свой ПК в папку нашего CA

В папке CA создадим файл v3ext.txt с содержимым:

Сгенерируем сертификат для addc1

Введите пароль закрытого ключа: Pa$$w0rd

Скопируем файл с сертификатом addc1-server.crt обратно на контролер домена addc1 и применим сертификат:

Из PowerShell проверим наличие сертификата:

Теперь вы должны перегрузить контролер домена, чтобы все настройки вступили в силу.

Обратите внимание, чтобы подключиться к серверу вы должны указать его полное доменное имя, в нашем случае:

Если ПК входит в состав домена altuninvv.local, вы можете использовать для подключение его имя:

Тогда контролер домена для подключения будет выбран автоматически из списка доступных, возможно, это будет работать только, при наличии Службы сертификатов на одном из серверов в AD!

Так как мой ПК не входит в домен altuninvv.local и не использует его DNS-сервера, я прописал в файле