настройка ldap windows server 2019

How to enable LDAP signing in Windows Server

This article describes how to enable LDAP signing in Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and Windows 10.

Summary

You can significantly improve the security of a directory server by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification), or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASL binds may include protocols such as Negotiate, Kerberos, NTLM, and Digest.

Unsigned network traffic is susceptible to replay attacks. In such attacks, an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle (MIM) attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on an LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.

How to discover clients that do not use the Require signing option

After you make this configuration change, clients that rely on unsigned SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds or on LDAP simple binds over a non-SSL/TLS connection stop working. To help identify these clients, the directory server of Active Directory Domain Services (AD DS) or Lightweight Directory Server (LDS) logs a summary Event ID 2887 one time every 24 hours to indicate how many such binds occurred. We recommend that you configure these clients not to use such binds. After no such events are observed for an extended period, we recommend that you configure the server to reject such binds.

If you must have more information to identify such clients, you can configure the directory server to provide more detailed logs. This additional logging will log an Event ID 2889 when a client tries to make an unsigned LDAP bind. The log entry displays the IP address of the client and the identity that the client tried to use to authenticate. You can enable this additional logging by setting the 16 LDAP Interface Events diagnostic setting to 2 (Basic). For more information about how to change the diagnostic settings, see How to configure Active Directory and LDS diagnostic event logging.

If the directory server is configured to reject unsigned SASL LDAP binds or LDAP simple binds over a non-SSL/TLS connection, the directory server logs a summary Event ID 2888 one time every 24 hours when such bind attempts occur.

How to configure the directory to require LDAP server signing for AD DS

Logging anomaly of Event ID 2889

Applications that use third-party LDAP clients may cause Windows to generate incorrect Event ID 2889 entries. This occurs when you log of LDAP interface events and if LDAPServerIntegrity is equal to 2. The use of sealing (encryption) satisfies the protection against the MIM attack, but Windows logs Event ID 2889 anyway.

This happens when LDAP clients use only sealing together with SASL. We have seen this in the field in association with third-party LDAP clients.

When a connection does not use both signing and sealing, the connection security requirements check uses the flags correctly and disconnect. The check generates Error 8232 (ERROR_DS_STRONG_AUTH_REQUIRED).

Using Group Policy

How to set the server LDAP signing requirement

How to set the client LDAP signing requirement by using local computer policy

How to set the client LDAP signing requirement by using a domain Group Policy Object

How to set the client LDAP signing requirement by using registry keys

Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

By default, for Active Directory Lightweight Directory Services (AD LDS), the registry key is not available. Therefore, you must create a LDAPServerIntegrity registry entry of the REG_DWORD type under the following registry subkey:

The placeholder represents the name of the AD LDS instance that you want to change.

How to verify configuration changes

Sign in to a computer that has the AD DS Admin Tools installed.

Select Start > Run, type ldp.exe, and then select OK.

Select Connection > Connect.

In Server and in Port, type the server name and the non-SSL/TLS port of your directory server, and then select OK.

For an Active Directory Domain Controller, the applicable port is 389.

After a connection is established, select Connection > Bind.

Under Bind type, select Simple bind.

Type the user name and password, and then select OK.

If you receive the following error message, you have successfully configured your directory server:

Ldap_simple_bind_s() failed: Strong Authentication Required

Источник

question

How can I get LDAP to work on Windows Server 2019 with internal CA certificate or with comodo certificate

I have spent many months on this issue, but recently on a new Windows Server 2019, I have the same issue:

I would think that the internal Windows 2019 certificates would be fine for LDAPS, not sure if it is a matter of trust, or a configuration issue. I have looked at many documents on the internet, but none seem to help me get beyon this LDAPS issue. My goal is to use a Windows 2019 ldaps certificate so other applications can authenticate and retrieve ldap data.

I have installed Windows Server 2019 and I installed the Certification Authority and I see port 389 and 636 in a listen mode, but when I attempt to use port 636 I have errors. Port 389 is fine. When I use the openssl connect command on port 443 I have no errors.

I have spent hours searching for solution that work in www.google.com. This has not worked.

I have used a JXplorer ldap browser i can login to port 389 and see active directory objects fine, but when I use port 636 it fails immediately with the error «Error opening connection: LDAP connection has been closed». The details on the error are: javax.naming.NamingException: LDAP connect has been closed».

When I do this command, I get a response as shown below that :

CONNECTED(00000003) depth=0 CN = LAB.FicticiousServerName.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = LAB.FicticiousServerName.com verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/CN=LAB.FicticiousServerName.com i:/DC=com/DC=FicticiousServerName/CN=FicticiousServerName.com

Use Windows 2019 ldp.exe to test ldap and port 636, IT LOOKS FINE. :

How can I use the existing ldap certificate in Windows 2019 and not get errors when
doing :

Источник

Включить LDAP над SSL с помощью сторонного органа сертификации

В этой статье описывается, как включить протокол легкого доступа к каталогам (LDAP) над защищенным слоем sockets (SSL) с помощью сторонних органов сертификации.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 321051

Сводка

LDAP используется для чтения и записи в Active Directory. По умолчанию трафик LDAP передается необеспеченным. Вы можете сделать трафик LDAP конфиденциальным и безопасным с помощью технологии SSL/Transport Layer Security (TLS). Вы можете включить LDAP над SSL (LDAPS) путем установки правильно отформатированный сертификат из сертификационного органа Майкрософт (CA) или не-Microsoft CA в соответствии с рекомендациями в этой статье.

Нет пользовательского интерфейса для настройки LDAPS. Установка допустимого сертификата на контроллере домена позволяет службе LDAP прослушивать И автоматически принимать подключения SSL как для LDAP, так и для глобального трафика каталогов.

Требования к сертификату LDAPS

Чтобы включить LDAPS, необходимо установить сертификат, отвечающий следующим требованиям:

Сертификат LDAPS расположен в хранилище персональных сертификатов локального компьютера (программным образом известном как хранилище сертификатов MY компьютера).

Закрытый ключ, который соответствует сертификату, присутствует в магазине локального компьютера и правильно связан с сертификатом. Закрытый ключ не должен иметь сильной защиты частных ключей включен.

Расширение использования ключей включает идентификатор проверки подлинности сервера (1.3.3.6.1.5.5.7.3.1) (также известный как OID).

Полное доменное имя контроллера домена Active Directory (например, dc01.contoso.com) должно отображаться в одном из следующих мест:

Сертификат был выдан ЦС, который доверяет контроллеру домена и клиентам LDAPS. Доверие устанавливается путем настройки клиентов и сервера для доверия корневому ЦС, к которому цепи выпуска ЦС.

Для создания ключа используйте поставщика криптографических служб Schannel (CSP).

Создание запроса сертификата

Любая утилита или приложение, создающая допустимый запрос #10 PKCS, может использоваться для формирования запроса сертификата SSL. Для формирования запроса используйте Certreq.

Чтобы запросить сертификат проверки подлинности сервера, подходящий для LDAPS, выполните следующие действия:

Subject = «CN=»; замените на FQDN dc
KeySpec = 1
KeyLength = 1024
; Может быть 1024, 2048, 4096, 8192 или 16384.
; Более крупные размеры ключей являются более безопасными, но имеют
; более сильное влияние на производительность.
Экспортируемый = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

OID=1.3.6.1.5.5.7.3.1; это для проверки подлинности сервера

Вырезать и ввести пример файла в новый текстовый файл с именем Request.inf. В запросе у вас есть полное DNS-имя контроллера домена.

Некоторые сторонние органы сертификации могут требовать дополнительных сведений в параметре Subject. Такие сведения включают адрес электронной почты (E), организационный блок (OU), организацию (O), локальность или город (L), состояние или провинцию (S) и страну или регион (C). Эту информацию можно в файле Request.inf приметь к имени субъекта (CN). Например:

Создайте файл запроса, создав следующую команду в командной подсказке:

Создается новый файл request.req. Это файл запроса с кодом base64.

Отправка запроса в ЦС. Запрос можно отправить в ЦС Майкрософт или в сторонний ЦС.

Извлеките выданный сертификат и сохраните сертификат Certnew.cer в той же папке, что и файл запроса, следуя следующим шагам:

Сохраненный сертификат должен быть закодирован как base64. Некоторые сторонние ЦС возвращают выданный сертификат запрашиваемой стороне в виде текста с базовым кодом в сообщении электронной почты.

Примите выданный сертификат, выдав следующую команду в командной подсказке:

Убедитесь, что сертификат установлен в личном хранилище компьютера, следуя следующим шагам:

Перезапустите контроллер домена.

Дополнительные сведения о создании запроса сертификата см. в следующем документе о регистрации и управлении расширенными сертификатами. Чтобы просмотреть этот документ, см. в статье Advanced Certificate Enrollment and Management.

Проверка подключения LDAPS

После установки сертификата выполните следующие действия, чтобы убедиться, что LDAPS включен:

Запустите средство администрирования Active Directory (Ldp.exe).

В меню Подключения нажмите кнопку Подключение.

Введите имя контроллера домена, к которому необходимо подключиться.

Введите 636 в качестве номера порта.

Нажмите кнопку ОК.

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

Возможные проблемы

Запуск расширенного запроса TLS

LDAPS-связь происходит через порт TCP 636. Связь LDAPS с глобальным сервером каталогов происходит в TCP 3269. При подключении к портам 636 или 3269 для обмена трафиком LDAP ведется согласование SSL/TLS.

Несколько сертификатов SSL

Поставщик Schannel, поставщик SSL Майкрософт, выбирает первый действительный сертификат, который он находит в локальном хранилище компьютеров. Если в локальном магазине компьютеров имеется несколько действительных сертификатов, Schannel может не выбрать правильный сертификат.

Проблема кэшинга сертификата SSL до SP3

Если существующий сертификат LDAPS заменяется другим сертификатом либо в процессе обновления, либо из-за изменения ЦС выдачи, сервер должен быть перезапущен для Schannel для использования нового сертификата.

Улучшения

AD DS преимущественно ищет сертификаты в этом магазине в магазине локальной машины. Это упрощает настройку AD DS для использования сертификата, который вы хотите использовать. Это потому, что в личном магазине локальных машин может быть несколько сертификатов, и трудно предсказать, какой из них выбран.

AD DS обнаруживает, когда новый сертификат сброшен в хранилище сертификатов, а затем запускает обновление сертификата SSL без перезапуска AD DS или перезапуска контроллера домена.

Новая операция rootDse с именем renewServerCertificate может использоваться для ручного запуска AD DS для обновления SSL-сертификатов без перезапуска AD DS или перезапуска контроллера домена. Этот атрибут можно обновить с помощью adsiedit.msc или импортировать изменение в формате обмена LDAP Directory (LDIF) с помощью ldifde.exe. Дополнительные сведения об использовании LDIF для обновления этого атрибута см. в сайте renewServerCertificate.

Наконец, если Windows Server 2008 или контроллер домена более поздней версии находит несколько сертификатов в своем магазине, он автоматически выбирает сертификат, срок действия которого будет самым дальним в будущем. Затем, если текущий сертификат приближается к дате истечения срока действия, вы можете отказаться от сертификата замены в магазине, и AD DS автоматически переключается на его использование.

Все это работает для Windows 2008 AD DS и для служб легкого каталога Active Directory 2008 (AD LDS). Для AD LDS поместите сертификаты в хранилище персональных сертификатов для службы, соответствующей экземпляру AD LDS, а не службе NTDS.

Источник

Как включить регистрацию LDAP в Windows Server

В этой статье описывается, как включить подписание 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 реестра:

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

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

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

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

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

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

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

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

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

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

Если вы получили следующее сообщение об ошибке, вы успешно настроили сервер каталогов:

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

Источник

Руководство по настройке защищенного протокола LDAP для управляемого домена доменных служб Azure AD

Для взаимодействия с управляемым доменом доменных служб (DS) Azure AD используется протокол LDAP. По умолчанию трафик LDAP не шифруется, что создает проблему безопасности во многих средах.

С помощью доменных служб Azure AD вы можете настроить для управляемого домена протокол LDAPS. При использовании защищенного протокола LDAP трафик шифруется. Защищенный протокол LDAP также называется «LDAP через SSL или TLS».

В этом учебнике показано, как настроить протокол LDAPS для управляемого домена Azure AD DS.

В этом руководстве описано следующее:

Если у вас еще нет подписки Azure, создайте учетную запись Azure, прежде чем начинать работу.

Предварительные требования

Для работы с этим учебником требуются следующие ресурсы и разрешения:

Вход на портал Azure

В этом руководстве объясняется, как настроить защищенный протокол LDAP для управляемого домена с помощью портала Azure. Чтобы начать работу, войдите на портал Azure.

Создание сертификата для защищенного протокола LDAP

Чтобы использовать защищенный протокол LDAP, нужен цифровой сертификат для шифрования при обмене данными. Этот цифровой сертификат применяется к управляемому домену и позволяет таким средствам, как LDP.exe, использовать безопасное зашифрованное соединение при отправке запросов к данным. У вас есть два способа создать сертификат для доступа управляемому домену через защищенный протокол LDAP.

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

Существует несколько средств для создания самозаверяющего сертификата, например OpenSSL, Keytool, MakeCert, командлет New-SelfSignedCertificate и т. д.

Для целей этого руководства мы создадим самозаверяющий сертификат для защищенного протокола LDAP, используя командлет New-SelfSignedCertificate.

Откройте окно PowerShell с правами администратора и выполните приведенные ниже команды. Замените переменную $dnsName DNS-именем, которое используется для управляемого домена, например aaddscontoso.com:

В этом примере выходных данных сообщается, что сертификат успешно создан и сохранен в локальном хранилище сертификатов (LocalMachine\MY):

Выбор и экспорт нужных сертификатов

Для защищенного протокола LDAP сетевой трафик шифруется с использованием инфраструктуры открытых ключей (PKI).

Эта пара закрытого и открытого ключей гарантирует, что взаимодействие будет возможно только между теми компьютерами, для которых вы его настроите. Если вы используете общедоступный ЦС или ЦС предприятия, вам будет выдан сертификат с закрытым ключом, который можно применить к управляемому домену. Открытый ключ должен быть известен клиентским компьютерам и настроен на них как доверенный.

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

Экспорт сертификата для Azure AD DS

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

Откройте диалоговое окно Выполнить, нажав клавиши Windows + R.

Откройте консоль управления (MMC), введя команду mmc в диалоговом окне Выполнить, а затем щелкните ОК.

В окне Контроль учетных записей пользователей щелкните Да, чтобы запустить MMC от имени администратора.

В мастере Оснастка диспетчера сертификатов выберите Учетная запись компьютера и щелкните Далее.

На странице Выбор компьютера выберите Локальный компьютер (на котором выполняется консоль) и щелкните Готово.

В диалоговом окне Добавление и удаление оснасток нажмите кнопку ОК, чтобы добавить оснастку «Сертификаты» в MMC.

Здесь вы увидите самозаверяющий сертификат, созданный на предыдущем шаге, например aaddscontoso.com. Щелкните этот сертификат правой кнопкой мыши и выберите Все задачи > Экспорт.

В мастере экспорта сертификатов щелкните Далее.

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

На странице Экспорт закрытого ключа выберите Да, экспортировать закрытый ключ и щелкните Далее.

Управляемые домены поддерживают для файла сертификата только формат PFX, который содержит закрытый ключ. Не экспортируйте сертификат в формате CER-файла, который не содержит закрытого ключа.

Так как этот сертификат используется для шифровки данных, необходимо тщательно контролировать доступ к нему. Для защиты закрытого ключа сертификата можно использовать пароль. Без правильного пароля сертификат не удастся применить к службе.

На странице Безопасность выберите вариант Пароль для защиты PFX-файла сертификата. Для шифрования необходимо использовать алгоритм TripleDES-SHA1. Введите и подтвердите пароль, а затем щелкните Далее. Этот пароль вы примените при работе со следующим разделом, чтобы включить защищенный протокол LDAP для управляемого домена.

При экспорте с помощью командлета PowerShell Export-PfxCertificate необходимо передать флаг -CryptoAlgorithmOption с TripleDES_SHA1.

На странице Файл для экспорта укажите имя и расположение файла, в который вы будете экспортировать сертификат, например C:\Users\accountname\azure-ad-ds.pfx. Запомните пароль и расположение PFX-файла, так как эти сведения потребуются при дальнейшей работе.

На следующей странице щелкните Готово, чтобы экспортировать сертификат в PFX-файл. После успешного экспорта сертификата появится диалоговое окно с подтверждением.

Не закрывайте окно MMC, которое пригодится нам в следующем разделе.

Экспорт сертификата для клиентских компьютеров

На клиентских компьютерах необходимо настроить доверие к издателю сертификата для защищенного протокола LDAP, чтобы подключаться к управляемому домену по протоколу LDAPS. Клиентским компьютерам требуется сертификат для успешного шифрования данных, которые будут расшифровываться в Azure AD DS. Если вы используете общедоступный ЦС, компьютер будет автоматически доверять издателям сертификатов и иметь соответствующий сертификат.

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

Вернитесь в консоль MMC и откройте хранилище Сертификаты (локальный компьютер) > Личные > Сертификаты. Здесь вы увидите самозаверяющий сертификат, созданный на предыдущем шаге, например aaddscontoso.com. Щелкните этот сертификат правой кнопкой мыши и выберите Все задачи > Экспорт.

В мастере экспорта сертификатов щелкните Далее.

Поскольку для клиентов закрытый ключ не требуется, на странице Экспорт закрытого ключа выберите Нет, не экспортировать закрытый ключ и щелкните Далее.

На странице Формат экспортируемого файла для экспортируемого сертификата выберите Файлы X.509 (.CER) в кодировке Base-64.

На странице Файл для экспорта укажите имя и расположение файла, в который вы будете экспортировать сертификат, например C:\Users\accountname\azure-ad-ds-client.cer.

На следующей странице щелкните Готово, чтобы экспортировать сертификат в CER-файл. После успешного экспорта сертификата появится диалоговое окно с подтверждением.

Теперь сертификат в формате CER-файла можно распространять на клиентские компьютеры, которые должны доверять защищенному подключению LDAP к управляемому домену. Давайте установим сертификат на локальном компьютере.

Откройте проводник и перейдите к расположению, в котором вы сохранили файла сертификата в формате CER, например C:\Users\accountname\azure-ad-ds-client.cer.

Щелкните CER-файл сертификата правой кнопкой мыши, а затем выберите Установить сертификат.

В мастере импорта сертификатов выберите вариант для сохранения сертификата на локальном компьютере, а затем щелкните Далее.

При появлении запроса выберите Да, чтобы разрешить компьютеру вносить изменения.

Выберите Автоматически выбрать хранилище на основе типа сертификата, а затем щелкните Далее.

На следующей странице щелкните Готово, чтобы импортировать CER-файл сертификата. После успешного импорта сертификата появится диалоговое окно с подтверждением.

Включение защищенного протокола LDAP для доменных служб Azure AD DS.

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

На портале Azure введите доменные службы в поле Поиск ресурсов. В списке результатов выберите Доменные службы Azure AD.

Выберите нужный управляемый домен, например aaddscontoso.com

В левой части окна Azure AD DS выберите Защищенный протокол LDAP.

По умолчанию защищенный доступ LDAP к управляемому домену отключен. Измените значение параметра Защищенный протокол LDAP на Включено.

По умолчанию доступ к управляемому домену через Интернет по защищенному протоколу LDAP отключен. Включая доступ по защищенному протоколу LDAP через Интернет, вы сделаете домен уязвимым к атакам из Интернета методом подбора пароля. На следующем шаге мы настроим группу безопасности сети, чтобы ограничить доступ только из определенного диапазона IP-адресов.

Переведите переключатель Разрешить доступ по защищенному протоколу LDAP через Интернет в положение Включено.

Щелкните значок папки рядом с полем PFX-файл с сертификатом защищенного протокола LDAP. Перейдите в папку, где расположен PFX-файл, а затем выберите созданный на предыдущем шаге сертификат, который содержит закрытый ключ.

Как отмечалось в предыдущем разделе о требованиях к сертификатам, вы не можете использовать сертификат общедоступного ЦС с доменом .onmicrosoft.com, который настроен по умолчанию. Домен .onmicrosoft.com принадлежит корпорации Майкрософт, поэтому общедоступный ЦС не будет выдавать для него сертификаты.

Убедитесь, что сертификат имеет правильный формат. В противном случае платформа Azure выдаст ошибку проверки сертификата при включении защищенного протокола LDAP.

Введите пароль для расшифровки PFX-файла, который вы настроили на предыдущем шаге при экспорте сертификата в PFX-файл.

Щелкните Сохранить, чтобы включить защищенный протокол LDAP.

Появится уведомление о том, что выполняется настройка защищенного протокола LDAP для управляемого домена. Вы не сможете изменить другие параметры управляемого домена, пока не завершится эта операция.

Включение защищенного протокола LDAP для управляемого домена займет несколько минут. Если предоставленный сертификат защищенного протокола LDAP не соответствует требуемому критерию, действие по включению защищенного протокола LDAP для управляемого домена завершается сбоем.

Типичные примеры ошибок: указано неправильное доменное имя, для шифрования сертификата используется алгоритм, отличный от TripleDES-SHA1, срок действия сертификата истек или истекает в ближайшее время. Вы можете повторно создать сертификат с правильными параметрами и включить защищенный протокол LDAP с указанием обновленного сертификата.

Замена сертификата с истекающим сроком действия

Блокировка доступа по защищенному протокол LDAP через Интернет

Предоставление доступа к управляемому домену по защищенному протоколу LDAP через Интернет создает угрозу безопасности. Управляемый домен доступен из Интернета через порт 636. Мы рекомендуем ограничить доступ к управляемому домену только из определенных IP-адресов, имеющих отношение к конкретной среде. Для ограничения доступа по защищенному протоколу LDAP можно использовать правило группы безопасности сети Azure.

Давайте создадим правило, которое разрешит входящий доступ по защищенному протоколу LDAP через TCP-порт 636 только для указанного набора IP-адресов. Правило DenyAll с низким приоритетом по умолчанию применяется ко всему остальному входящему трафику из Интернета, а значит доступ к управляемому домену по защищенному протоколу LDAP можно будет получить только с указанных адресов.

На портале Azure выберите Группы ресурсов в панели навигации слева.

Выберите группу ресурсов, например myResourceGroup, а затем выберите группу безопасности сети, например aaads-nsg.

Отобразится список существующих правил безопасности для входящих и исходящих подключений. В левой части окна свойств для группы безопасности сети выберите Параметры > Правила безопасности для входящего трафика.

Щелкните Добавить и создайте правило, открывающее TCP-порт 636. Для повышения безопасности выберите IP-адреса в качестве источника и укажите допустимый IP-адрес или диапазон адресов, принадлежащих вашей организации.

Когда все будет готово, щелкните Добавить, чтобы сохранить и применить это правило.

Настройка зоны DNS для внешнего доступа

Разрешив доступ через Интернет по защищенному протоколу LDAP, измените параметры зоны DNS, чтобы клиентские компьютеры могли найти этот управляемый домен. Внешний IP-адрес защищенного протокола LDAP указан на вкладке Свойства для управляемого домена.

В настройках внешнего поставщика DNS создайте запись, разрешающую имя узла (например, ldaps), в этот внешний IP-адрес. Чтобы проверить работу на локальном компьютере, вы можете сначала создать такую запись в файле hosts системы Windows. Чтобы изменить файл hosts на локальном компьютере, откройте Блокнот от имени администратора и откройте файл C:\Windows\System32\drivers\etc\hosts.

В следующем примере представлена DNS-запись, созданная во внешнем поставщике DNS или в локальном файле hosts, которая направляет трафик для ldaps.aaddscontoso.com к внешнему IP-адресу 168.62.205.103:

Проверка запросов к управляемому домену

Чтобы подключиться к управляемому домену, создать привязку к нему и выполнить поиск по протоколу LDAP, используйте средство LDP.exe. Оно входит в пакет средств удаленного администрирования сервера (RSAT). Дополнительные сведения см. в статье об установке средств удаленного администрирования сервера.

Затем выполните привязку к управляемому домену. Пользователи (и учетные записи служб) не могут выполнять простые привязки LDAP, если вы отключили синхронизацию хэшей паролей NTLM для управляемого домена. См. сведения об отключении синхронизации хэшей паролей NTLM в статье Отключение слабых шифров и синхронизации хэшей паролей для защиты управляемого домена доменных служб Azure AD.

Чтобы просмотреть объекты, сохраненные в управляемом домене, сделайте следующее:

Выберите пункт меню Представление и щелкните Дерево.

Оставьте поле BaseDN пустым и щелкните OК.

Выберите контейнер, например Пользователи AADDC, щелкните его правой кнопкой мыши и выберите пункт Поиск.

Сохраните все автоматически заполненные значения и щелкните Запуск. Результаты запроса отображаются в окне справа, как показано в следующем примере выходных данных:

Чтобы выполнить прямой запрос к конкретному контейнеру, выберите пункт меню Представление > Дерево, затем укажите значение BaseDN, например OU=AADDC Users,DC=AADDSCONTOSO,DC=COM или OU=AADDC Computers,DC=AADDSCONTOSO,DC=COM. Дополнительные сведения о форматировании и создании запросов см. в статье с основными сведениями о запросах LDAP.

Если используется самозаверяющий сертификат, добавленный в Доверенные корневые центры сертификации для LDAPS, убедитесь, что он работает с LDP.exe.

Очистка ресурсов

Если ранее в рамках этого руководства вы добавляли запись DNS в файл hosts на локальном компьютере для проверки подключения, удалите эту запись и добавьте запись в основную зону DNS. Чтобы удалить запись из локального файла hosts, сделайте следующее:

Устранение неполадок

Если произойдет ошибка и отобразится сообщение о том, что LDAP.exe не удалось подключиться, попробуйте решить эту проблему, проверив различные элементы подключения:

Чтобы сопоставить имя субъекта сертификата, контроллер домена будет использовать доменное имя Azure ADDS (не доменное имя Azure AD) для поиска сертификата в хранилище сертификатов. Например, из-за опечаток контроллер домена не сможет выбрать правильный сертификат.

Клиент попытается установить TLS-подключение, используя указанное вами имя. При том трафик должен проходить весь путь. Контроллер домена отправляет открытый ключ для сертификата аутентификации сервера. Нужно правильно настроить использование сертификата. Имя, зарегистрированное как имя субъекта, должно быть совместимым, чтобы клиент доверял тому, что сервер соответствует DNS-имени, к которому вы подключаетесь (то есть можно указать подстановочный знак без опечаток), и клиент должен доверять издателю. Вы можете проверить наличие проблем в этой цепочке в системном журнале в компоненте «Просмотр событий» и отфильтровать события, где указан источник SChannel. Вместе все эти компоненты образуют сеансовый ключ.

Дополнительные сведения см. в статье Подтверждение протокола TLS.

Дальнейшие действия

В этом руководстве вы узнали, как выполнять следующие задачи:

Источник