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

LDAPS

(LDAP over SSL)

The guide is split into 3 sections :

1. Create a Windows Server VM in Azure
2. Setup LDAP using AD LDS (Active Directory Lightweight Directory Services)
3. Setup LDAPS (LDAP over SSL)

NOTE : The following steps are similar for Windows Server 2008, 2012, 2012 R2 , 2016. In this article, we will use Windows Server 2012 R2.

Create a Windows Server VM in Azure

Create a VM named “ldapstest” Windows Server 2012 R2 Datacenter Standard DS12 using the instructions here:

Create a Windows virtual machine with the Azure portal

Connect to the VM ldapstest using Remote Desktop Connection.

Setup LDAP using AD LDS

Choose Role-based or feature-based installation. Click Next.

Select ldapstest server from the server pool. Click Next.

Mark Active Directory Lightweight Directory Services from the list of roles and click Next.

From the list of features, choose nothing – just click Next.

Click Next.

Click Install to start installation.

Once installation is complete, click Close.

Now we have successfully set up AD LDS Role. Let us create a new AD LDS Instance “CONTOSO” using the wizard. Click the “Run the Active Directory Lightweight Directory Services Setup Wizard” in the above screen. And then Click Close.

Choose Unique Instance since we are setting it up for the first time.

Type “CONTOSO” in Instance Name and click Next.

By Default, LDAP Port is 389 and LDAPS port is 636, let us choose the default values — click Next.

Create a new Application Directory Partition named “CN=MRS,DC=CONTOSO,DC=COM”. Click Next.

Using the default values for storage location of ADLDS files- Click Next.

Choosing Network Service Account for running the AD LDS Service.

You will receive a prompt warning about data replication. Since we are using a single LDAP Server, we can click Yes.

Choosing the currently logged on user as an administrator for the AD LDS Instance. Click Next.

Mark all the required LDIF files to import (Here we are marking all files). Click Next.

Verify that all the selections are right and then Click Next to confirm Installation.

Once the instance is setup successfully, click Finish.

If the connection is successful, we will be able to browse the Directory CN=MRS,DC=CONTOSO,DC=COM :

Setup LDAPS (LDAP over SSL)

Now, let’s use Active Directory Certificate Services to create a certificate to be used for LDAPS. If you already have a certificate satisfying the above requirements, you can skip this step.

Click on Start —> Server Manager —> Add Roles and Features. Click Next.

Choose Role-based or feature-based installation. Click Next.

Select ldapstest server from the server pool. Click Next.

Choose Active Directory Certificate Services from the list of roles and click Next.

Choose nothing from the list of features and click Next.

Click Next.

Mark “Certificate Authority” from the list of roles and click Next.

Click Install to confirm installation.

Once installation is complete, Click Close.

Now let’s create a certificate using AD CS Configuration Wizard. To open the wizard, click on “Configure Active Directory Certificate Services on the destination server” in the above screen. And then click Close. We can use the currently logged on user azureuser to configure role services since it belongs to the local Administrators group. Click Next.

Choose Certification Authority from the list of roles. Click Next.

Since this is a local box setup without a domain, we are going to choose a Standalone CA. Click Next.

Choosing Root CA as the type of CA, click Next.

Since we do not possess a private key – let’s create a new one. Click Next.

Choosing SHA1 as the Hash algorithm. Click Next.

UPDATE : Recommended to select the most recent hashing algorithm since

SHA-1 deprecation countdown

The name of the CA must match the Hostname (requirement number 2). Enter “LDAPSTEST” and Click Next.

Specifying validity period of the certificate. Choosing Default 5 years. Click Next.

Choosing default database locations, click Next.

Click Configure to confirm.

Once the configuration is successful/complete. Click Close.

Now let us view the generated certificate.

Click on Start à Search “Manage Computer Certificates” and open it.

Click on Personal Certificates and verify that the certificate “LDAPSTEST” is present:

Now to fulfill the third requirement, let us ensure host machine account has access to the private key. Using the Certutil utility, find the Unique Container Name. Open Command Prompt in Administrator mode and run the following command: certutil -verifystore MY

The private key will be present in the following location C:ProgramDataMicrosoftCryptoKeys<UniqueContainerName>

Right Click C:ProgramDataMicrosoftCryptoKeys874cb49a696726e9f435c1888b69f317_d3e61130-4cd8-4288-a344-7784647ff8c4 and click properties —> Security and add read permissions for NETWORK SERVICE.

We need to import this certificate into JRE key store since our certificate “CN=LDAPSTEST” is not signed by any by any trusted Certification Authority(CA) which is configured in you JRE keystore e.g Verisign, Thwate, goDaddy or entrust etc. In order to import this certificate using the keytool utility, let us first export this cert as a .CER from the machine certificate store:

Click Start —> Search “Manage Computer Certificates” and open it. Open personal, right click LDAPSTEST cert and click “Export”.

This opens the Certificate Export Wizard. Click Next.

Do not export the private key. Click Next.

Choose Base-64 encoded X .509 file format. Click Next.

Exporting the .CER to Desktop. Click Next.

Click Finish to complete the certificate export.

Certificate is now successfully exported to “C:UsersazureuserDesktopldapstest.cer”.

Now we shall import it to JRE Keystore using the keytool command present in this location:

C:Program FilesJavajre1.8.0_92binkeytool.exe.

Type “yes” in the Trust this certificate prompt.

Once certificate is successfully added to the JRE keystore, we can connect to the LDAP server over SSL.

Now let us try to connect to LDAP Server (with and without SSL) using the ldp.exe tool.

Connection strings for

LDAP:\ldapstest:389

LDAPS:\ldapstest:636

Click on Start —> Search ldp.exe —> Connection and fill in the following parameters and click OK to connect:

If Connection is successful, you will see the following message in the ldp.exe tool:

To Connect to LDAPS (LDAP over SSL), use port 636 and mark SSL. Click OK to connect.

If connection is successful, you will see the following message in the ldp.exe tool:

REFERENCES

https://technet.microsoft.com/en-us/library/cc770639(v=ws.10)

https://technet.microsoft.com/en-us/library/cc725767(v=ws.10).aspx

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate….

https://blogs.technet.microsoft.com/askds/2008/03/13/troubleshooting-ldap-over-ssl/

http://javarevisited.blogspot.com/2011/11/ldap-authentication-active-directory.html

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.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 — all editions
Original KB number: В 935834

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

1. Select Start >Run, type mmc.exe, and then select OK.
2. Select File >Add/Remove Snap-in, select Group Policy Management Editor, and then select Add.
3. Select Group Policy Object >Browse.
4. In the Browse for a Group Policy Object dialog box, select Default Domain Controller Policy under the Domains, OUs, and linked Group Policy Objects area, and then select OK.
5. Select Finish.
6. Select OK.
7. Select Default Domain Controller Policy >Computer Configuration >Policies >Windows Settings >Security Settings >Local Policies, and then select Security Options.
8. Right-click Domain controller: LDAP server signing requirements, and then select Properties.
9. In the Domain controller: LDAP server signing requirements Properties dialog box, enable Define this policy setting, select Require signing in the Define this policy setting list, and then select OK.
10. In the Confirm Setting Change dialog box, select Yes.

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

1. Select Start >Run, type mmc.exe, and then select OK.
2. Select File >Add/Remove Snap-in.
3. In the Add or Remove Snap-ins dialog box, select Group Policy Object Editor, and then select Add.
4. Select Finish.
5. Select OK.
6. Select Local Computer Policy >Computer Configuration >Policies >Windows Settings >Security Settings >Local Policies, and then select Security Options.
7. Right-click Network security: LDAP client signing requirements, and then select Properties.
8. In the Network security: LDAP client signing requirements Properties dialog box, select Require signing in the list, and then select OK.
9. In the Confirm Setting Change dialog box, select Yes.

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

1. Select Start >Run, type mmc.exe, and then select OK.
2. Select File >Add/Remove Snap-in.
3. In the Add or Remove Snap-ins dialog box, select Group Policy Object Editor, and then select Add.
4. Select Browse, and then select Default Domain Policy (or the Group Policy Object for which you want to enable client LDAP signing).
5. Select OK.
6. Select Finish.
7. Select Close.
8. Select OK.
9. Select Default Domain Policy >Computer Configuration >Windows Settings >Security Settings >Local Policies, and then select Security Options.
10. In the Network security: LDAP client signing requirements Properties dialog box, select Require signing in the list, and then select OK.
11. In the Confirm Setting Change dialog box, select Yes.

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

В этой статье описывается, как включить подпись 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 или простой привязки LDAP через подключение, не относяющееся к SSL/TLS, перестают работать. Чтобы помочь определить этих клиентов, сервер каталогов доменных служб Active Directory (AD DS) или сервер облегченного доступного каталога (LDS) регистрирует сводный ИД события 2887 один раз каждые 24 часа, чтобы указать, сколько таких привязок произошло. Мы рекомендуем не использовать такие привязки для этих клиентов. После того как такие события не происходят в течение длительного периода, рекомендуется настроить сервер на отклонение таких привязок.

Если для идентификации таких клиентов необходимо получить дополнительные сведения, можно настроить сервер каталогов для предоставления более подробных журналов. В этом дополнительном окне занося в журнал событие с ид 2889, когда клиент пытается сделать неподписаную привязку LDAP. В записи журнала отображается IP-адрес клиента и удостоверение, которое клиент попытался использовать для проверки подлинности. Вы можете включить это дополнительное ведение журнала, установив для диагностического параметра «16 событий интерфейса LDAP» 2 (базовый). Дополнительные сведения об изменении параметров диагностики см. в сведениях о настройке ведения журнала событий диагностики Active Directory и LDS.

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

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

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

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

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

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

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

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

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

1. Выберите >«Запустить»,введитеmmc.exe и выберите «ОК».
2. Выберите >«Добавить или удалить оснастку»,«Редактор управления групповыми политиками» и «Добавить».
3. Выберите «Обзор объекта групповой >политики».
4. В диалоговом окне «Обзор объекта групповой политики» выберите политику контроллера домена по умолчанию в области «Домены», «OUS» и «Связанные объекты групповой политики», а затем выберите «ОК».
5. Нажмите кнопку Готово.
6. Нажмите OK.
7. Выберите «Политики конфигурации компьютера контроллера домена по умолчанию» «Параметры безопасности параметров Windows» и выберите > > > > >«Параметры безопасности».
8. Щелкните правой кнопкой мыши контроллер домена: требования к подписи сервера LDAP и выберите «Свойства».
9. В контроллере домена: диалоговое окно «Свойства для подписи сервера LDAP» в поле «Определение этого параметра политики» выберите «Требовать подпись» в списке «Определение этого параметра политики» и затем выберите «ОК».
10. В диалоговом окне «Подтверждение изменения параметра» выберите «Да».

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

1. Выберите >«Запустить»,введитеmmc.exe и выберите «ОК».
2. Select File >Add/Remove Snap-in.
3. В диалоговом окне «Добавление и удаление оснастки» выберите редактор объектов групповой политики и выберите «Добавить».
4. Нажмите кнопку Готово.
5. Нажмите OK.
6. Выберите локальные политики >компьютерной конфигурации >конфигурации windows >Settings Security > Settings Local Policies, > а затем выберите параметры безопасности.
7. Щелкните правой кнопкой мыши сетевую безопасность: требования подписи клиента LDAP и выберите «Свойства».
8. В диалоговом окне «Безопасность сети: свойства для подписи клиента LDAP» выберите «Требовать подпись в списке» и затем выберите «ОК».
9. В диалоговом окне «Подтверждение изменения параметра» выберите «Да».

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

1. Выберите >«Запустить»,введитеmmc.exe и выберите «ОК».
2. Select File >Add/Remove Snap-in.
3. В диалоговом окне «Добавление и удаление оснастки» выберите редактор объектов групповой политики и выберите «Добавить».
4. Выберите «Обзор», а затем выберите политику домена по умолчанию (или объект групповой политики, для которого нужно включить подпись LDAP клиента).
5. Нажмите OK.
6. Нажмите кнопку Готово.
7. Нажмите Закрыть.
8. Нажмите OK.
9. Выберите локализованные параметры безопасности параметров безопасности конфигурации компьютера с политикой домена по умолчанию, а затем > > > > выберите «Параметры безопасности».
10. В диалоговом окне «Безопасность сети: требования к подписи клиента LDAP: свойства» выберите «Требовать регистрацию в списке» и затем выберите «ОК».
11. В диалоговом окне «Подтверждение изменения параметра» выберите «Да».

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

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

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

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

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

Во sign in to a computer that has the AD DS Admin Tools installed.

Выберите > «Запустить», введитеldp.exe и выберите «ОК».

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

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

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

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

В области «Тип привязки» выберите «Простая привязка».

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

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

Ldap_simple_bind_s() failed: Strong Authentication Required

Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers.

$ openssl genrsa -aes256 -out ca.key 4096
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Cookie Preferences

Important Info:
The scheduled update (ADV190023), regarding LDAP Signing and Channel Binding for new and existing domain controllers, scheduled for March 10, 2020, has been postponed to the second half of calendar year 2020. The March 2020 update will only provide additional auditing capabilities to identify and configure LDAP systems before they become inaccessible with the later update.

The later update results in no more connections to the domain controller, via unsigned / Clear Text LDAP on port 389. Then it is only possible to use either LDAPS via port 636 or Signed LDAP (StartTLS) on port 389.

Affected Domain Controller Versions

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP 1
• Windows Server 2008 SP 2

Affected LDAP Clients

The topic concerns not only the Microsoft environment, but all systems that serve as LDAP client and send LDAP requests. The following is a small list of systems that occurred to me.

• Citrix Gateway
• Citrix AAA
• Citrix LoadBalancer for LDAP
• Citrix Endpoint Management
• VPN (e.g. Sophos)
• Igel UMS Console
• Ticket Systems (e.g. Remedy or Helpdesk)
• ERP /CRM Systems (e.g. SAP)
• Database Systems (e.g. Oracle)
• Webserver (e.g. TomCat or Apache)
• Security Components (Firewall or Proxy)
• Backup / Storage Repository

Some manufacturers, e.g. Igel, have already reacted and it is now possible to switch the connection to LDAPS via the GUI of the UMS console.

How can I check if unsigned LDAP is used?

LDAP signing events

Following are the event logs regarding LDAP signing.

If event 2886 is present on a domain controller, this indicates that signed LDAP is not forced by the DCs and it is possible to perform a simple (Clear Text) LDAP binding over an unencrypted connection. The security option “Domain controller: LDAP server signing requirements” is then configured to “None“.

The next checkpoint is event 2887, this event ID occurs every 24 hours and reports how many unsigned and clear text connections to the DC have occurred.

If the Active Directory servers are configured to reject unsigned or simple LDAP connections over a non-SSL/TLS connection, the Active Directory servers log these attempts and write a summary to the event log every 24 hours under event ID 2888.

Changes with March Update

Important:
The March 10, 2020 updates do not change the default policies for LDAP signing or LDAP channel binding on new or existing Active Directory domain controllers.

It only adds the following functions:

• New events are logged in the Event Log in combination with the LDAP Channel Bindings.
• A new GPO setting “Domain controller: LDAP server channel binding token requirements” to configure LDAP channel binding on supported devices. Possible settings are None, When Supported or Always. Event ID 3039 is only created if this setting is not set to None.

LDAP Channel Binding events

Following are the new events that will be released with the March update.

Activation LDAP Event Diagnostic Logging

With the event IDs mentioned above we only get the information that we still receive Clear Text LDAP requests to the domain controller, but not who is sending them. To change this we can increase the log level on our domain controller to see who requested the Clear Text LDAP connection (Event ID 2889).

Enable LDAP Event Diagnostic Logging

Copy the bottom line into a REG file and execute it on the DC. No restart is required.

Disable LDAP Event Diagnostic Logging

Copy the bottom line into a REG file and execute it on the DC to disable it again.

Note:
It may be necessary to replace the double quotation marks after copying and pasting.

After activation of the extended log level, an event with the ID 2889 is created for each access via Clear Text LDAP (under Applications and Services Logs / Directory Service). These events contain which IP addresses and which user accounts have established this connection.

PowerShell script for testing the DCs

To make it easier to check the environment, I have adapted the following PowerShell scripts by Arne Tiedemann to the Microsoft March Updates.

• Connect to a domain controller
• Go to this link and download the two scripts
  (Further instructions are stored in the README.md file)
• Run the script ActiveDirectory-DCLDAPEvents.ps1 to search your domain controllers for event ID 2887 & 3040

• The script then create a CSV file (InsecureLDAPCount.csv) with the displayed information

Only the event entries are counted and you will not get any further information from this file!

To get more information, like user account or IP address of the LDAP client, you have to execute the script ActiveDirectory-LDAPInterfaceEventLogging.ps1

• Start the script on the domain controller

The script will detect if you have run one of the two available scripts in the last 15 minutes and would not search all DCs for the known events again.

If the increased log level should not run for 30 minutes, the time can be adjusted with the following parameters.

Action plan for ADV190023

1. Install the March Windows Updates
2. Check environment automatically via script or with the following manual steps
   • Configure LDAP Event Diagnostic Logging to 2 or higher
   • Monitor the event log under Applications and Services Logs / Directory Service on all domain controllers
     • LDAP Signing failure event 2887
     • LDAP Channel Binding failure event 3040

       Note:
       Event 3039 can only be generated if Channel Binding is set to When Supported or Always.

3. Identify the devices for each IP address named at Event 2887 (unsigned LDAP) or Event 3039 (no LDAP Channel Binding)
4. Enable LDAPS on domain controller (Signed LDAP is always accepted and should not be set to Required in the phase)
5. Enable LDAPS or Signed LDAP (StartTLS) on the mentioned devices

Activation LDAPS & Signed LDAP (StartTLS) on DC

Short guide to enable LDAPS & Signed LDAP (StartTLS) on your domain controllers.

Method 1

Method 2

In most cases a certificate is used where the root CA is not located on a DC. So the second method is to simply put a certificate (Server Authentication enabled) on each DC.

Important:
Remember that regardless of which CA is used to obtain this certificate, both the DCs and the systems running the LDAP client application must trust this certificate.

Note:
For a Windows Server 2008 / R2 / 2012 DC, the certificate must be imported into the AD DS Personal Store (NTDSPersonal).
For older servers (older than 2003 R2) the certificate must be imported into the Computer Personal Store.
For Windows Server 2016 & 2019 both methods work.

Requirements

• Installed & Activated CA

Publication of a compatible Certificate Template

We need a certificate template that supports Server Authentication and has an Exportable private key.

• Connect to your server that has the AD CA role installed
• Open the Certificate Console via Start > Run and the command certsrv.msc

• Expand the display, by double clicking on the name of your CA
• Now click with the right mouse button on Certificate Templates and then on Manage

• In the Certificate Template Console, right-click on Web Server and select Duplicate Template

It is not necessary to use the Web Server template. You can create your own template or use one of the other existing templates that have server authentication as their purpose.

• In the window that appear, the duplicated template is edited. Change the following under General
  • Change the Template display name
  • Change the Validity period and Renewal period to your security parameters

• Under Request Handling click on Allow private key to be exported

• Under Subject Name select DNS name and Service principal Name (SPN)

Note:
If the certificate template is to be used for wildcards, Supply in the request must be selected here

• Under Security click Add

• In the following window click on Locations…

• Select Computers and confirm with OK

• Enter your DCs and confirm this with Check Names and OK

• Under Security click on your newly added DCs and extend the Allow permissions with Read, Write & Enroll

• Under Extensions, check again that Server Authentication is also selected as the Application Policies. Confirm the entries with OK.

• Close the Certificate Template Console
• Go back to the Certificate Console and right click in the details area of Certificate Templates
• Click here on New and then on Certificate Template to be Issue

• In the window Enable Certificate Templates select the newly created template (here Server Authentication) and click on OK

Requesting a Server Authentication Certificate

For LDAPS we can use either a SAN certificate or a Wildcard certificate. Both types of certificates must be created with Server Authentication permission. Follow these instruction for either SAN certificate or Wildcard certificate.

Request SAN Certificate

• Connect to the first DC
• Open a console there via Start > Run with the command mmc

• In the MMC console click on File and on Add/Remove Snap-in…

• In the following window select Certificates on the left side and click on Add

• In the Certificate Snap-in window, select Computer account and click Next

• Under Select Computer, select Local Computer and click Finish
• Extend the console to the folder Certificates (Local Computer) > Personal > Certificates
• Right-click on the folder and click on All Tasks and Request New Certificate

• Click the first two windows with Next through
• In the window Request Certificates select your newly created certificate template (here Server Authentication)
• Click on Enroll

• If the creation was successful, this is displayed under Status. Confirm this with Finish

• Double-click the new certificate in the results area to open the Certificate Properties dialog box

• Click on the Details tab and select the Enhanced Key Usage option. Check that Server Authentication (1.3.6.1.5.5.7.3.1) has been added

Perform these steps for each domain controller.

Request Wildcard Certificate

If a load balancer (e.g. Citrix ADC) is used in front of the domain controllers, not every DC has to receive its own certificate. Only the load balancer needs a certificate (e.g. Wildcard certificate), which is then imported and accepted on all DCs.

• Connect to the first DC
• Open a console there via Start > Run with the command mmc

• In the MMC console click on File and on Add/Remove Snap-in…

• In the following window select Certificates on the left side and click on Add

• In the Certificate Snap-in window, select Computer account and click Next

• Under Select Computer, select Local Computer and click Finish
• Extend the console to the folder Certificates (Local Computer) > Personal > Certificates
• Right-click on the folder and click on All Tasks and Request New Certificate

• Click the first two windows with Next through
• In the window Request Certificates select your newly created certificate template (here Server Authentication)
• Click on the warning notice More information is required to enroll for this certificate…

  Note:
  If you do not see this warning, the certificate template is not defined with Supply in the request under Subject Name in the template

• In the Certificate Properties window under the Subject tab enter the following
  • Type (Common name)
  • Value (Your domain for the Wildcard, e.g. *.deyda.local)
• Click on Add

• In the tab General enter the display name of the certificate under Friendly name (e.g. *.deyda.local)

• Check in the tab Extensions that both Digital signature & Key encipherment is selected

• Check in the Private Key tab that Make private key exportable is selected and confirm this with OK

• When all requirements are filled out click on Enroll

• If the creation was successful, this is displayed under Status. Confirm this with Finish

• Double-click the new certificate in the results area to open the Certificate Properties dialog box

• Click on the Details tab and select the Enhanced Key Usage option. Check that Server Authentication (1.3.6.1.5.5.7.3.1) has been added

This only need to be done once for all DCs.

Export the LDAPS certificate

The following steps show how to export an LDAPS-enabled certificate from the local certificate store of a domain controller. The following steps apply to Wildcard and SAN certificates.

• Connect to the first DC
• Open a console there via Start > Run with the command mmc

• In the MMC console click on File and on Add/Remove Snap-in…

• In the following window select Certificates on the left side and click on Add

• In the Certificate Snap-in window, select Computer account and click Next

• Under Select Computer, select Local Computer and click Finish
• Extend the console to the folder Certificates (Local Computer) > Personal > Certificates
• Click with the right mouse button on the previously created certificate (here DC01.deyda.net, you can recognize it by the column Certificate Template) and click on All Tasks and Export

• Click Next on the Welcome Screen of the Certificate Export Wizard
• In the Export Private Key window, select Yes, export private key and confirm with Next
  • If it is not possible to export the private key, then the wrong certificate template was selected or it was created incorrectly

• In the Export File Format window, Export all extended properties should be selected. Confirm this with Continue.
• The other selection options are optional.

• On the Security window, enter a Password to use for importing the certificate. Then click Next

• Select a path in the File to Export window via Browse and define a file name. Then click on Next

• Confirm the settings by clicking on Finish

• This is followed by a pop-up message indicating that The export was successful. Click OK.

Import for use with AD DS

• Connect to the first DC
• Open a console there via Start > Run with the command mmc

• In the MMC console click on File and on Add/Remove Snap-in…

• In the following window select Certificates on the left side and click on Add

• In the Certificates snap-in window, select Service account and click Next

• Under Select Computer, select Local Computer and click Next
• Select Active Directory Domain Services and confirm with Finish

• Expand the console to the folder Certificates – Service (Active Directory Domain Services) > NTDSPersonal
• Right click on the NTDSPersonal folder and click on All Tasks and Import

• At the Certificate Import Wizard window click Next
• Click the Browse button in the File to Import window and then browse to the previously exported certificate file
  • Ensure that Personal Information Exchange (pfx, .p12) is selected as the file type

• Confirm the selection with Next

• In the following Private key protection window, enter the Password for the certificate and click Next

• On the Certificate Store page, make sure the Place all certificates in the following store option is selected and the certificate store is NTDSPersonal.
• Confirm this with Next

• Confirm the settings with a click on Finish

• A message should then appear that The import was successful. Click on OK

• Check the successful import. Expands the navigation area under NTDSPersonal > Certificates. Here you should see the imported certificate

Checking the connections

After installing a certificate, perform the following steps to verify that LDAPS and Signed LDAP (StartTLS) are working.

• Connect to the first DC
• Open a console there via Start > Run with the command mmc
• Start the Active Directory Administration Tool (Ldp.exe)
  • For non-domain controllers, the Remote server administration tools must be installed

• Click on Connection and then on Connect

• Enter the name of the LDAPS server (e.g. Domain Controller or LDAP Load Balancer) you want to test
• Change the port to 636 and check the box SSL to test LDAPS
• Start the test with OK

• Successful connection via LDAPS

• Change the port to 389 and uncheck the SSL box to test signed LDAP (StartTLS)
• Start the test with OK

• The LDAP connection is established

• Now click on Options > TLS > StartTLS to start Signed LDAP (StartTLS)

• Signed LDAP (StartTLS) could establish connection

Check without certificate

For test cases you can delete the imported certificate from the DC again or connect against a DC without certificate. There you can try to establish the same connections.

• LDAPS connection (Port 636 SSL) not successful

• LDAP connection (Port 389) still works

• But the switch to Signed LDAP (StartTLS) no longer works

Configure Citrix ADC

As mentioned above, the Citrix ADC with its DC connections may be affected by the upcoming change. Therefore here is a short instruction to change the required settings in the Citrix ADC.

Requirements

• The domain controller has bound a certificate (Server Authentication) for LDAPS or Signed LDAP (StartTLS) (e.g. Wildcard Certificate)
• If LDAPS is to be used, the affected firewalls must still be adapted (Port change from 389 to 636)

Authentication LDAPS Server

• Connect to the Management IP of the affected system

• Go in the navigantion panel to System > Authentication > Basic Policies > LDAP

• Switch to the Servers tab

• Open your existing LDAP server (here 10.0.0.4_LDAP)

• Change the Security Type to SSL, which directly change the Port to 636

• Now you can test this change directly with Test LDAP Reachability. This can be found under Connection Settings

Another advantage of switching to LDAPS is that the user can change his password independently.

• Activate the item Allow Password Change under Other Settings

CLI Command

Example:

Authentication Signed LDAP (StartTLS) Server

• Connect to the Management IP of the affected system

• Go to System > Authentication > Basic Policies > LDAP in the Navigation Menu

• Switch to the Servers tab

• Open your existing LDAP server (here 10.0.0.4_LDAP)

If the firewalls are not to be adjusted, Signed LDAP (StartTLS) can also be used in the Citrix ADC.

• Change the Security Type to TLS, the Port remains at 389

• Now you can test this change directly with Test LDAP Reachability. This can be found under Connection Settings

CLI Command

Example:

Load Balanced LDAPS Server

TCP or SSL_TCP can be selected as Load Balancing Protocol for LDAPS. SSL_TCP is recommended for higher compatibility (e.g. with Linux appliances) (SSL termination is done on the Citrix ADC).

For existing LDAP load balancing, the following must be recreated for LDAPS:

• Load Balancing Monitor
• Load Balancing Service Groups
• Load Balancing vServer

• Connect to the Management IP of the affected system

Configuration LDAPS Monitor

• Go to Traffic Management > Load Balancing > Monitors in the Navigation Menu

• Now click on Add, if you do not have an existing LDAPS monitor

• Configure the new Monitor
  • Name (Name of the Monitor, e.g. LDAPS)
  • Type (Type of the Monitor, LDAP)
  • Password (The password of the Service Account stored under Bind DN)
  • Base DN (Domain names in LDAP format, e.g. dc=deyda, dc=local)
  • Bind DN (Service Account for communication with the AD, e.g. service_ldap@deyda.local)
  • Filter (Restriction of search results, cn=builtin)
  • Secure (Activate the Secure checkbox)
• Confirm the entry with Create

CLI Command

Example:

Configuration of the LDAPS Service Group

• Go to Traffic Management > Load Balancing > Service Groups in the Navigation Menu

• Now click on Add to create a new Service Group for LDAPS

• Configure the new Service Group for LDAPS
  • Name (Name of the Service Group, e.g. LDAPS-svc_group)
  • Protocol (Protocol, SSL_TCP)
• Confirm the entry with OK

• Click on No Service Group Member in the following window to include the existing DCs for LDAPS

• Change the server methode to Server Based and click on Click to select if existing servers are to be included. If new servers are to be included, click Add

• Select the DCs that are configured for LDAPS and add them via Select

• Configure the required port (636) and confirm the entry with Create

• In the following Load Balancing Service Group window, select Monitors on the right side

• Now click on No Service Group to Monitor Binding to bind the previously created LDAPS Monitor

• Now select the Monitor (here LDAPS) and confirm this with Select

• Confirm the integration of the Monitor by clicking on Bind

• Confirm the entries with Done. The Effective State must be displayed as Up

CLI Command

Example:

Configuration of the LDAPS virtual Server

• Go to Traffic Management > Load Balancing > Virtual Servers in the Navigation Menu

• Now click on Add to create a new Virtual Server for LDAPS

• Configure the new Virtual Server for LDAPS
  • Name (Name of the Virtual Servers, e.g. LDAPS-LB)
  • Protocol (Protocol, SSL_TCP)
  • IP Address Type (IP Address)
  • IP Address (IP Address of the Virtual Server, e.g. 10.0.0.200)
  • Port (LDAPS Port, 636)
• Confirm the entries with OK

• Click No Load Balancing Virtual Server ServiceGroup Binding in the following window to bind the newly created Service Group

• Click on Click to select to get to the selection list of Service Groups

• Select the previously configured Service Group (LDAPS-svc_group) and add it via Select
• Click Continue after binding

• Click under Certificate on No Server Certificate

• Now select a suitable certificate for this load balancer. Select a Wildcard certificate of the local domain (Wildcard-deyda-local) and confirm with Select

• Now click on Continue and then on Done

CLI Command

Example:

Configuration of the LDAPS Authentication Server

• Go to System > Authentication > Basic Policies > LDAP in the Navigation Menu

• Switch to the Servers tab

• Open the existing LDAP server (here 10.0.0.4_LDAP) or create a new one

• Change the following settings of the existing Authentication Server
  • IP Address (IP Address of the LB Virtual Server, 10.0.0.200)
  • Security Type (Type of the connection, SSL)
  • Port (Port of the connection, 636)

    The port is automatically changed when SSL is selected under Security Type.

• Now you can test this change directly with Test LDAP Reachability. This can be found under Connection Settings

Another advantage of switching to LDAPS is that the user can change his password independently.

• Activate the item Allow Password Change under Other Settings

CLI Command

Example:

Load Balanced Signed LDAP (StartTLS)

If the firewalls should not be changed, Signed LDAP (StartTLS) should be used in the Citrix ADC. Nothing need to be adjusted in the load balancing chain for this, because port 389 is still used.

• Connect to the Management IP of the affected system

• Go to System > Authentication > Basic Policies > LDAP in the Nagivation Menu

• Switch to the Servers tab

• Open the existing LDAP server (here 10.0.0.4_LDAP) or create a new one

• Change the Security Type to TLS, the port remain at 389

• Now you can test this change directly with Test LDAP Reachability. This can be found under Connection Settings

CLI Command

Example:

I’ve got a configuration issue with my test domain controller (Server 2019) where I can’t connect via 636 using LDP. (using the full domain name)

On 2008 and 2012 I didn’t have to do any additional configuration; it just worked.

However, in 2019 is may appear that I need to manually configure an SSL cert for this to work. I found this article on MS: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority and it appears that I need to get a public certificate for each domain that I will be connecting to (which will be a lot). If this is true, those certs would expire and I’m not sure what the effect will be (will it still work or fail?). If it will fail, how do I watch the certs and fix ahead of time?

But this doesn’t make sense to me since 2008 and 2012 both work «out of the box» with 636.

When I check the 2019 server with:
certutil -v -urlfetch -verify serverssl.cer > output.txt

I get:

DecodeFile returned The system cannot find the file specified 0x80070002 (Win32: 2 ERROR_FILE_NOT_FOUND)
LoadCert(Cert) returned The system cannot find the file specified 0x80070002 (Win32: 2 ERROR_FILE_NOT_FOUND)
CertUtil -verify command FAILED: 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)
CertUtil: The system cannot find the file specified.

So that’s telling me the cert does not exist.

Each of the domains I will be connecting to, the computer connecting to them will not be in the same domain. In that above article it was referring to having a cert that can be trusted by both devices.

From the testdomain I can run LDP and connect back into the 2008 or 2012 domain with zero issues on 636 using the builtin configured certificate… But this is a new version and it appears to be different.

Has anyone run into this on 2019 and can share a little more information of what I’m encountering?