Как включить ldap в ad windows 2016

This article is based on best practice which we need to follow during the implementation of Active Directory and authentication of it with other software in presence of SSO (Single Sign on). So, what actually ldap means? The Lightweight Directory Access Protocol (LDAP) is used to read from and write to Active Directory. By default, LDAP traffic is transmitted unsecured. You can make LDAP traffic confidential and secure by using Secure Sockets Layer (SSL) / Transport Layer Security (TLS) technology. You can enable LDAP over SSL (LDAPS) by installing a properly formatted certificate from either a Microsoft certification authority (CA) or a non-Microsoft CA. so on this blog I will be sharing my knowledge on how to configure secure LDAP connection on Server 2016.

In default, communication between client and server application are not encrypted for LDAP which means it is possible to monitor device or software and view the communications traveling between LDAP client and Server Computers. But that doesn’t mean it can expose the Kerberos, SASL and even NTLM authentication or authorization, because they do have their own encryption methods. So only the data communication between Client and servers do have possibility of getting compromised. Hence let’s work on the securing the communication.

The port that uses by the LDAP for the normal communication is TCP/UDP 389 whereas for the secure communication it will be using 636 port. So, first let’s know how to check it.

Open your machine, go to run, type ‘ldp’ and click on ‘OK’.

Once this is done, a new window will get open. On the ‘Connection’ click ‘Connect’ and provide the server name and port as 636.

So, if you see this kind of error than this means you do not have configured secure LDAP. Then let’s start configuring it.

Configuring secure LDAP:

To configure the secure LDAP, we first need to install Certificate Authority on our Domain Controller. To get install Certificate Authority, please follow this blog. After completion of installing Local CA, open it. Right click on ‘Certificate template’, and select ‘Manage’. On ‘Action’, select ‘View Object Identifiers’.

Now scroll down and verify if you do have Server Authentication with object Identifier 1.3.6.1.5.5.7.3.1, this is the thing which allows us to configure secure ldap.

After verifying Object identifier, now open  ‘Microsoft Management Console’ (MMC).

On ‘Microsoft Management Console (MMC)’, ‘Add or Remove Snap-ins’ using computer Certificates

Add certificate for the local computer and click ‘OK’, once this is done.

After adding the Local Certificate, expand the Personal below the Certificates.

You will see a new folder name ‘Certificates’ right-click on it and navigate to ‘Request New Certificate’ and select it.

A new window will get open for the Certificate Enrollment, click ‘Next’ on this.

On ‘Select Certificate Enrollment Policy’ click on ‘Next’.

At ‘Certificate Enrollment’, select ‘Domain Controller’ and click on ‘Enroll’.

It will take a while to get install the ‘Domain certificate’ on your Domain Controller. After completion click on ‘Finish’.

Now you can see the certificate issued to your domain controller on your certificate page.

Testing:

Once you verified the certificate has been installed on your machine, try to get connect to your machine as we did earlier

If the configuration is good, you will receive this kind of message on your LDP console. If it didn’t you might need to restart your machine once.

Hope this was quite helpful blog for the integrating AD authentication with your Application using Secure channel. Keep posting for any comments J

About Author

pdhewjau

Prashant is a Microsoft MVP for Office Servers and Services. He works as Technical Lead on Thakral One and a Microsoft Certified Trainer for Windows Server, Exchange Server and office 365.

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

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

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

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

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

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

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

Если в ответ вы получили сообщение:

ld = ldap_sslinit("altuninvv.local", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to altuninvv.local.

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

Если сообщение похоже на такое:

Established connection to xxxx.xxxxxxxxx.xxx.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: 
...
forestFunctionality: 6 = ( WIN2012R2 ); 
highestCommittedUSN: 2153249; 
isGlobalCatalogReady: FALSE; 
isSynchronized: TRUE; 
ldapServiceName: XXXXXXXX$@XXXXXXXXXXXXX; 
....
supportedCapabilities (6): 1.2.840.113556.1.4.800 = ( ACTIVE_DIRECTORY ); 1.2.840.113556.1.4.1670 = ( ACTIVE_DIRECTORY_V51 ); 1.2.840.113556.1.4.1791 = ( ACTIVE_DIRECTORY_LDAP_INTEG ); 1.2.840.113556.1.4.1935 = ( ACTIVE_DIRECTORY_V61 ); 1.2.840.113556.1.4.2080 = ( ACTIVE_DIRECTORY_V61_R2 ); 1.2.840.113556.1.4.2237 = ( ACTIVE_DIRECTORY_W8 ); 
supportedControl (37): 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.2.840.113556.1.4.801 = ( SD_FLAGS ); 1.2.840.113556.1.4.473 = ( SORT ); 1.2.840.113556.1.4.528 = ( NOTIFICATION ); 1.2.840.113556.1.4.417 = ( SHOW_DELETED ); 1.2.840.113556.1.4.619 = ( LAZY_COMMIT ); 1.2.840.113556.1.4.841 = ( DIRSYNC ); 1.2.840.113556.1.4.529 = ( EXTENDED_DN ); 1.2.840.113556.1.4.805 = ( TREE_DELETE ); 1.2.840.113556.1.4.521 = ( CROSSDOM_MOVE_TARGET ); 1.2.840.113556.1.4.970 = ( GET_STATS ); 1.2.840.113556.1.4.1338 = ( VERIFY_NAME ); 1.2.840.113556.1.4.474 = ( RESP_SORT ); 1.2.840.113556.1.4.1339 = ( DOMAIN_SCOPE ); 1.2.840.113556.1.4.1340 = ( SEARCH_OPTIONS ); 1.2.840.113556.1.4.1413 = ( PERMISSIVE_MODIFY ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.10 = ( VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( ASQ ); 1.2.840.113556.1.4.1852 = ( QUOTA_CONTROL ); 1.2.840.113556.1.4.802 = ( RANGE_OPTION ); 1.2.840.113556.1.4.1907 = ( SHUTDOWN_NOTIFY ); 1.2.840.113556.1.4.1948 = ( RANGE_RETRIEVAL_NOERR ); 1.2.840.113556.1.4.1974 = ( FORCE_UPDATE ); 1.2.840.113556.1.4.1341 = ( RODC_DCPROMO ); 1.2.840.113556.1.4.2026 = ( DN_INPUT ); 1.2.840.113556.1.4.2064 = ( SHOW_RECYCLED ); 1.2.840.113556.1.4.2065 = ( SHOW_DEACTIVATED_LINK ); 1.2.840.113556.1.4.2066 = ( POLICY_HINTS_DEPRECATED ); 1.2.840.113556.1.4.2090 = ( DIRSYNC_EX ); 1.2.840.113556.1.4.2205 = ( UPDATE_STATS ); 1.2.840.113556.1.4.2204 = ( TREE_DELETE_EX ); 1.2.840.113556.1.4.2206 = ( SEARCH_HINTS ); 1.2.840.113556.1.4.2211 = ( EXPECTED_ENTRY_COUNT ); 1.2.840.113556.1.4.2239 = ( POLICY_HINTS ); 1.2.840.113556.1.4.2255 = ( SET_OWNER ); 1.2.840.113556.1.4.2256 = ( BYPASS_QUOTA ); 
supportedLDAPPolicies (19): MaxPoolThreads; MaxPercentDirSyncRequests; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxBatchReturnMessages; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn; MaxNotificationPerConn; MaxValRange; MaxValRangeTransitive; ThreadMemoryLimit; SystemMemoryLimitPercent; 
supportedLDAPVersion (2): 3; 2; 
supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5; 

-----------

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

Установка OpenSSL

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

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

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

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

Скачаем свежую версию OpenSSL — вы можете скачать её отсюда — https://slproweb.com/products/Win32OpenSSL.html

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

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

pacman -Sy openssl

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

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

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

[ req ]
distinguished_name = req_distinguished_name
req_extensions     = v3_ca

[ req_distinguished_name ]
# Descriptions
countryName=RU
stateOrProvinceName=Magadan region
localityName=Magadan
0.organizationName= Altunin Soft
1.organizationName=IT
commonName=altuninvv.local

#Modify for your details here or answer the prompts from openssl
countryName_default=RU
stateOrProvinceName_default= Magadan region 
localityName_default= Magadan
0.organizationName_default= Altunin Soft
1.organizationName_default=IT
commonName_default= altuninvv.local 
[ v3_ca ]
keyUsage=critical,keyCertSign
basicConstraints=critical,CA:TRUE,pathlen:1
extendedKeyUsage=serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = *. altuninvv.local 
DNS.2 = altuninvv.local

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

openssl genrsa -des3 -out ca.key 4096

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

Generating RSA private key, 4096 bit long modulus (2 primes)
......................................................................................................................................
........................................................................................................................................
....++++..........................++++e is 65537 (0x010001)
Enter pass phrase for ca.key:

Verifying - Enter pass phrase for ca.key:

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

openssl req -new -x509 -extensions v3_ca -days 3659 -key ca.key -out ca.crt -config ca.conf

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

Enter pass phrase for ca.key:
 You are about to be asked to enter information that will be incorporated                                                                                                                                           into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
For some fields there will be a default value,
 If you enter '.', the field will be left blank. 
-----
RU [RU]:
Magadan region [Magadan region]:
Magadan [Magadan]:
Altunin Soft [Altunin Soft]:
 IT [IT]:
altuninvv.local [altuninvv.local]:

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

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

Import-Certificate –Verbose -FilePath ca.crt  -CertStoreLocation 'Cert:LocalMachineRoot'

VERBOSE: Performing the operation "Import certificate" on target "Item: C:caca.crt Destination: Root".


   PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot

Thumbprint                                Subject                                                                          
----------                                -------                                                                          
D5D1306CFFDAF63EDA10710F13F69C0228005350  CN=altuninvv.local, O=IT, O=Altunin Soft, L=Magadan, S=Magadan region, C=RU 

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

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

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

;----------------- request.inf -----------------
[Version]
Signature="$Windows NT$"

;The Subject will need to be your active directory domain name
[NewRequest]
Subject = "CN=altuninvv.local
KeySpec = 1
KeyLength = 4096
Exportable = TRUE
SMIME = FALSE
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
UseExistingKeySet = FALSE
UserProtected = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
;The following will add a subject alternative name of a wildcard cert on *.example.com
;so any ad controller with a hostname of somththing.example.com can use it.
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=*.altuninvv.local&"
_continue_ = "dns=altuninvv.local&"
Выполним запрос на сертификат:
certreq -new req.txt addc1.csr
CertReq: Request Created

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

certreq -new req.txt addc1.csr
CertReq: Request Created

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

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

# v3ext.txt
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also. 
#The *.example.com will allow all Domain controllers with 
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.altuninvv.local
DNS.2 = altuninvv.local

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

openssl x509 -req -days 825 -in addc1.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out addc1-server.crt
Signature ok
subject=CN = altuninvv.local
Getting CA Private Key
Enter pass phrase for ca.key:

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

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

certreq -accept addc1-server.crt
Installed Certificate:
  Serial Number: 01
  Subject: CN=altuninvv.local (DNS Name=*.altuninvv.local, DNS Name=altuninvv.local)
  NotBefore: 2/18/2021 5:37 PM
  NotAfter: 5/24/2023 5:37 PM
  Thumbprint: 4721d27e9fe34aaa672d20d68c0ec01fd9f7a82c

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

PS C:ca> Get-ChildItem "Cert:LocalMachineMy"

   PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy

Thumbprint                                Subject
----------                                -------
4721D27E9FE34AAA672D20D68C0EC01FD9F7A82C  CN=altuninvv.local

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

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

addc1.altuninvv.local

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

altuninvv.local

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

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

C:WindowsSystem32driversetchosts

строку:

192.168.0.10 addc1.altuninvv.local

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

Для проверки подключения мы будет использовать утилиту ldp.exe.

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

Запустим ldp.exe, откроется окно:

В этом окне выберите подключение – подключить

Введем:

Сервер: addc1.altuninvv.local

Порт: 636

Установим галочку SSL

Нажмем Ок, будет осуществлено подключение и выведена дополнительная информация:

Теперь мы может сделать bind к серверу

Выберите Подключение – Привязка

Заполните поля:

Пользователь: CN=ldap-bind,CN=Users,DC=altuninvv,DC=local

Пароль: Pas#w0rds#1

Установите: Простая привязка

нажмите Ок

Будет выведено сообщение:

res = ldap_simple_bind_s(ld, 'CN=ldap-bind,CN=Users,DC=altuninvv,DC=local', <unavailable>); // v.3

Authenticated as: 'ALTUNINVVldap-bind'.

Это означает, что подключение прошло успешно.

Далее выберем пункт меню Вид – Дерево

И в окне выберем — DC=altuninvv,DC=local

Нажмем Ок

Откроется дерево с разделами домена,

Таким образом вы можете просматривать каталог AD через LDAP по SSL.

Заключение

Сегодня мы рассмотрели подключение к контролеру домена AD с использованием протокола LDAP по SSL.

Мы создали свой локальный центр сертификации CA с помощью OpenSSL.

Был выпущен сертификат и установлен на контролере домена.

С помощью утилиты ldp.exe было осуществлено подключение к контролеру домена по SSL.

After installing and configuring Certification Authority (CA) server, Next step is use it to generate SSL certificate for LDAPS configuration on Domain Controller.

The Lightweight Directory Access Protocol (LDAP) is used to read from and write to Active Directory. By default, LDAP traffic is transmitted unsecured. You can make LDAP traffic confidential and secure by using Secure Sockets Layer (SSL) / Transport Layer Security (TLS) technology. You can enable LDAP over SSL (LDAPS) by installing a properly formatted certificate from either a Microsoft certification authority (CA) or a non-Microsoft CA according to the guidelines in this article.

This will help to install certificates, which are digital credentials used to connect to wireless networks, protect content, establish identity, and do other security-related tasks. 

To enable LDAPS, you must install a certificate that meets the following requirements:

• A private key that matches the certificate is present in the Local Computer’s store and is correctly associated with the certificate. The private key must not have strong private key protection enabled.
• The LDAPS certificate is located in the Local Computer’s Personal certificate store (programmatically known as the computer’s MY certificate store).
• The Active Directory fully qualified domain name of the domain controller (for example, ad001.vcloud-lab.com) must appear in one of the following places:
  • DNS entry in the Subject Alternative Name extension.
  • The Common Name (CN) in the Subject field.
• The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as OID).
• The certificate was issued by a CA that the domain controller and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the root CA to which the issuing CA chains.
• You must use the Schannel cryptographic service provider (CSP) to generate the key.

Part 1: Install and configure certificate authority (CA) on Microsoft Windows server with Group Policy
Part 2: Configuring Secure LDAPs on Domain Controller
                       ldp.exe LDAPS Cannot open connection Error 81
Part 3: Install and Configure Active Directory Federation Service (ADFS)

My CA server is hosted on AD server for lab purpose as there are resource constraints in the lab, so properly design your Active directory and Certification Authority server infrastructure. To go ahead, I logged onto Windows server (Already Domain Controller with Certification Services installed), Open either Server Manager >> Tools >> Certification Authority or Search for Certification Authority. This opens certsrv mmc management console. Here expand CA server and right click on Certificate Template. Click Manage from the context menu.

This opens another Management Console for Certificate Templates separately in another window. Find Kerberos Authentication from Template Display Name list and right click on it. Choose Duplicate Template from context menu. On the New Template Properties on General tab provide Template display name LDAPs and choose Publish certificate in Active Directory. Go to Request Handling tab and choose Allow private key to be exported. Next in the Subject Name, choose both User principal name (UPN) and Service principal name (SPN) and click OK.

This newly generated copy of Kerberos Authentication certificate template will show as LDAPs in the templates list. Close Certificate Template Console.

After closing certificate template console, It will return to certsrv (Certification Authority) mmc console. On the Certificate Template right click and choose New >> Certificate Template to Issue. In the Enable Certificate Templates choose LDAPs name. and click OK.

Newly enabled certificate template will show on the list.

Certificate templates is configured, its time to use it. Now new SSL certificate need to be generated on Active Directory Domain Controller. Search and open mmc.exe, Go to File >> Add/Remove Snap-in then click Certificates and click Add. The certificates snap-in allows you to browse the contents of the certificate stores for yourself, a service, or a computer.

First select Computer account on Certificates snap-in and in the Select Computer keep default Local computer (the computer this console is running on) and press Finish. Repeat same process again click Certificates and click Add, but this time choose Service account and in the Select Computer keep default Local computer (the computer this console is running on), on the next select Active Directory Domain Services. In the last click Finish. Now under selected snap-ins you will see two certificates snap-ins, Click OK to proceed.

This will help to install certificates, which are digital credentials used to connect to wireless networks, protect content, establish identity, and do other security-related tasks.

Next go to Certificates (Local Computer) mmc console — it is a LocalMachine certificate stores (Computer Account). Under Personal >> right click Certificates and choose All Tasks, then Request New Certificate. On the Certificate Enrollment Wizard, click Next on Before you Begin and Select Certificate Enrollment Policy, Request LDAPs certificate from list, the earlier created one by clicking check box. Check if Certificate Installation status is succeeded and press Finish (If it is failing restart Certificate Authority services and try again).

New certificate will be listed with Certificate Intended Purposes is KDC Authentication, Samrt Card Logon, Server Authentication, Client Authentication. and Issued to is FQDN of domain controller computer where this certificate was installed. Note down Thumbprint. 

Create a new Folder with below command.

New-Item -Path C: -Name Certs -ItemType Directory

Next from the LocalMachine >> Personal certificates store list all the certificates specially with ThumbPrint. Match the thumbprint on the cert, and use it to export it as PFX certificate with password.

Get-ChildItem Cert:LocalMachineMy | Select-Object ThumbPrint, Subject, NotAfter, EnhancedKeyUsageList

#Change Password and Certificate ThumbPrint accordingly.
$password = ConvertTo-SecureString -String "123456" -Force -AsPlainText
Get-ChildItem -Path Cert:LocalMachineMy0F388654F85C5E1A3934B18293C0FFAB6BD464DF | Export-PfxCertificate -FilePath C:CertsLDAPs.pfx -Password $password

My new certificate is generated unde path C:Certs with name LDAPs.

Next copy the certificate from LocalMachine Personal store to the Active Directory Domain Services Service Account Certificate store under NTDSPersonal Certificates, using below command. 

#Change Certificate ThumbPrint accordingly.
Move-Item "HKLM:SOFTWAREMicrosoftSystemCertificatesMYCertificates0F388654F85C5E1A3934B18293C0FFAB6BD464DF" "HKLM:SOFTWAREMicrosoftCryptographyServicesNTDSSystemCertificatesMYCertificates"

Verify certificates in MMC console or on registry location HKLM:SOFTWAREMicrosoftCryptographyServicesNTDSSystemCertificatesMYCertificates whether they are added successfully.

This is last step in the article, verify LDAPs is correctly setup/configured buy connecting it. For this we need ldp.exe tool, Make sure RSAT AD tools are installed before using it. (It is already installed on Active directory if AD tools are selected for installation)

Install-WindowsFeature RSAT-AD-Tools -IncludeAllSubFeature -IncludeManagementTools

Search for ldp and open it. On the Connection menu select connect choose server, make sure FQDN is selected, Port is 636 and SSL is checked, Click OK to proceed. Once succeeded It shows Established connection to selected domain controller.

Useful Articles
Generate new self-signed certificates for ESXi using OpenSSL
Push SSL certificates to client computers using Group Policy
Replacing a default ESXi certificate with a CA-Signed certificate
Troubleshooting replacing a corrupted certificate on Esxi server
How to import default vCenter server appliance VMCA root certificate and refresh CA certificate on ESXi
How to replace default vCenter VMCA certificate with Microsoft CA signed certificate
 

Привет.

Я часто пишу про тюнинг Active Directory – данная тема интересна тем, что практически на каждом предприятии данная инфраструктурная служба есть, и в большинстве случаев из её возможностей используется малая толика. В данной статье я расскажу про редкий и не освещаемый в простеньких авторизованных курсах функционал – LDAP-политики или Query Policy. Причина забвения данной темы, которая существует с Windows 2000 Server, тривиальна – и без настройки LDAP-политик всё работает с Default Query Policy. Однако в высоконагруженных или требующих взаимодействия с внешними LDAP-сервисами применениях знать, как работают LDAP-политики – надо.

Я предполагаю, что вы знаете, что такое CN, DN, RDN, LDAP, DC, GC, не путаете сайты Active Directory и то, что в IE, а также прониклись Active Directory настолько, что браузер для вас – это вначале ADSI.msc и только после – всё остальное. Наличие знаний хотя бы на уровне MCSA Windows Server 2012 обязательно.

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

Мы будем изучать все существующие в природе Query Policy – начиная с Windows 2000 Server и заканчивая доступной на данный момент версией Windows Server 2016.

LDAP-политики (Query Policy) в Active Directory

• Что такое политики LDAP в Active Directory и зачем они нужны
• Базовые операции с политиками
• Как узнать, какие политики Query Policy поддерживаются
• Настраиваем параметры фильтрации доступа к LDAP
• Параметры функционирования LDAP
• Настраиваем параметры функционирования LDAP в Windows Server 2016
• Формат Query Policy
• Параметры, существующие с Windows 2000 Server
  • Параметр Query Policy – MaxActiveQueries
  • Параметр Query Policy – InitRecvTimeout
  • Параметр Query Policy – MaxConnections
  • Параметр Query Policy – MaxConnIdleTime
  • Параметр Query Policy – MaxDatagramRecv
  • Параметр Query Policy – MaxNotificationPerConn
  • Параметр Query Policy – MaxPoolThreads
  • Параметр Query Policy – MaxReceiveBuffer
  • Параметр Query Policy – MaxPageSize
  • Параметр Query Policy – MaxQueryDuration
  • Параметр Query Policy – MaxResultSetSize
  • Параметр Query Policy – MaxTempTableSize
• Параметры, существующие с Windows Server 2003
  • Параметр Query Policy – MaxValRange
• Параметры, существующие с Windows Server 2008 R2
  • Параметр Query Policy – MaxResultSetsPerConn
  • Параметр Query Policy – MinResultSets
• Параметры, существующие с Windows Server 2012
  • Параметр Query Policy – MaxBatchReturnMessages
• Параметры, существующие с Windows Server 2016
  • Параметр Query Policy – MaxDirSyncDuration
• Отключаем жестко заданные лимиты настроек
• Создаём новую Query Policy

Начнём.

Что такое политики LDAP в Active Directory и зачем они нужны

Под термином “политики” в связи с Active Directory обычно имеются в виду групповые политики – мощное и легко расширяемое средство для централизованного управления многими настройками ОС и приложений. Некоторые ещё вспоминают “политики паролей” – PSO, которые появились с Windows Server 2008.

Однако, есть ещё одно применение термина “политики Active Directory” – благодаря объектам, которые относятся к классу queryPolicy, существует возможность тонкой настройки работы контроллеров домена (DC) и серверов глобального каталога (GC), а также ощутимого повышения скорости, надёжности и безопасности их функционирования. Все эти параметры будут относиться именно к клиентским запросам по LDAP и ограничивать размер ответа, занимаемую память, диапазон значений, тайм-ауты и другие подобные свойства. Давайте разберёмся что это, и как это можно (и нужно) эффективно использовать.

Базовые операции с политиками

Query Policy хранятся в специальных объектах класса queryPolicy. Сам класс queryPolicy представляет из себя объект, содержащий в себе “пачку” настроек, которые читаются LDAP-серверами. Пачка реализована как многострочные атрибуты lDAPAdminLimits и lDAPIPDenyList, которые можно редактировать вручную, прямо в объекте AD, а можно “по-красивому”, через утилиту dsmgmt (ранее – через ntdsutil).

Утилита dsmgmt идеологически “более правильная” по причине, что ntdsutil изначально предназначался для работы именно с Active Directory, а dsmgmt позиционируется как более общее решение, которое должно работать со всеми службами LDAP-каталогов, включая AD LDS. А вообще, можно это всё править и через оснастку ADSI Editor. И через вкладку “Attributes” у объекта queryPolicy. И через древнюю утилиту ldp.exe. Особой разницы нет – LDAP – достаточно демократичная штука.

Объекты этого класса находятся в специальном контейнере, который расположен в разделе леса Configuration по DN-адресу CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=контекст-Вашего-леса-Active-Directory. Вы можете увидеть их глазами, если откроете стандартную оснастку Active Directory Sites and Services и не забудете включить отображение ветки лесных сервисов – View / Show Services Node:

Достаточно логично, что эти объекты находятся в разделе configuration, который реплицируется на все контроллеры в лесу. Ведь данные политики применяются не только на контроллеры конкретного домена, а и на GC, и на сайты, которые привязки к доменам не имеют.

Изначально в Active Directory создан единственный объект LDAP-политик с именем Default Query Policy, который содержит настройки “по умолчанию”. Вы его видели на первом скриншоте – а вот так выглядят его настройки для новорожденного DC на Windows Server 2016:

Этот объект надо никогда не трогать. Почему – будет видно далее, а теперь мы поговорим о том, как эти объекты применяются на свою “целевую аудиторию” (DC/GC), редактируются и создаются.

Схема применения LDAP-политик

Объекты queryPolicy могут привязываться к сайту Active Directory, а могут и (что неочевидно) к конкретному контроллеру. Какая же будет логика применения нескольких политик queryPolicy?

1. Контроллер домена смотрит раздел леса Configuration, открывает там контейнер Sites, находит себя и в своём дочернем объекте c CN=NTDS Settings и типом nTDSDSA смотрит на атрибут queryPolicyObject. Если там есть DN политики – настройки применяются и обработка прекращается. Т.е. не как в групповой политике, когда результирующая политика представляет собой “сумму наложений” всех политик на объекте, а сразу – раз политику нашёл, то применил и обработку остановил.
2. Если своей политики у контроллера домена нет, он берёт свой сайт, открывает его дочерний объект с CN=NTDS Settings и типом ntDSSiteSettings, находит там атрибут queryPolicyObject (у которого там может и не быть значения, он опциональный), и, в случае наличия, берёт DN объекта LDAP-политики из него. В этом случае обработка также останавливается.
3. Если не нашлось ничего – контроллер не унывает и идёт читать дефолтный объект с именем Default Query Policy. Поэтому, если Вы придумали свои новые и отличные настройки – всегда делайте новый объект, а не редактируйте дефолтный, чтобы иметь возможность лёгкого возврата настроек (что-то не работает – удалили ссылку на свой объект, контроллер стал читать дефолтный).

Добавлю, что, несмотря на одинаковое название – NTDS Settings, у сайта и у DC объект имеет разные типы – Site Settings (nTDSSiteSettings) и Domain Controller Settings (nTDSDSA).

По сути работа Query Policy ещё проще, чем в случае с групповыми политиками, где стандартную схему применения модицифируют многочисленные дополнительные инструменты. Теперь перейдём к самим настройкам, которые будут разделяться на две части (т.к. атрибута, в которых они задаются, тоже два – lDAPIPDenyList и lDAPAdminLimits.

Как узнать, какие политики Query Policy поддерживаются

Параметры меняются от версии к версии – и каждый контроллер с удовольствием расскажет вам, какие параметры QueryPolicy он знает и умеет обрабатывать. Для этого в LDAP 3.0 объявлен специальный объект root DSA-specific Entry (RootDSE), и у него есть multivalued атрибут supportedLDAPPolicies – вы увидите эти данные, просто подключившись к контроллеру, например, при помощи ldp.exe:

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

Замечу, что аутентификация не нужна – по RFC 2251 данный объект, описывающий возможности LDAP-сервера, поддерживающего LDAP 3.0, должен быть доступен любому.

Ну а теперь можно и понастраивать.

Настраиваем параметры фильтрации доступа к LDAP

Первое и самое простое – фильтрация доступа к контроллерам. Благодаря политикам LDAP Вы можете выбрать IP-адреса, доступ с которых будет заблокирован. Делается это достаточно просто – в каждом объекте queryPolicy есть атрибут lDAPIPDenyList, в котором можно указать нужное количество блокируемых адресов. Формат атрибута – массив строк, а каждая строка должна выглядеть просто – IPv4 адрес, пробел и маска. Например строка:

172.16.0.0 255.240.0.0

заблокирует все обращения к контроллеру с частных IPv4-адресов сетей класса B. Для IPv6 данный механизм не реализован. В устаревшей документации можно встретить утверждение, что данный атрибут работает только для дефолтного объекта LDAP-политик, с CN=Default Query Policy. Это не так – работает и в других.

Думаю, что использование такого параметра вполне очевидно – в случае теоретической доступности контроллера со стороны “ненужных” сетей доступ можно заблокировать. Хотя на данный момент в Windows Server имеется Advanced Firewall, который сам может это сделать, функционал блокировки адресов именно на уровне LDAP-запроса присутствует. Во многом по причине того, что когда данный функционал появился (в 1999 году, вместе с рождением Active Directory), встроенного Firewall в Windows Server не было.

Настраиваем параметры функционирования LDAP в Windows Server 2016

Теперь перейдём к основному массиву настроек. Мы разобьём их список по версиям серверной ОС – от Windows 2000 Server до Windows Server 2016.

Формат Query Policy

Все параметры LDAP-политик имеют формат вида “Имя=Значение”. То есть если нужно присвоить атрибуту Parameter значение 7, результирующая строка будет Parameter=7.

Параметры, существующие с Windows Server 2000

Параметр Query Policy – MaxActiveQueries

Поддерживается версиями ОС

Только Windows 2000 Server; начиная с Windows Server 2003 параметр игнорируется.

Значение по умолчанию

20

Что делает

Когда использовался, указывал максимальное количество параллельно работающих операций поиска в LDAP на конкретном DC. По достижению этого числа DC выдавал при попытке “заказать” операцию поиска ошибку ERROR_DS_ADMIN_LIMIT_EXCEEDED. Сейчас не используется, потому что есть более “умная” настройка, ограничивающая количество параллельных операций не для DC, а для ядра процессора.

Параметр Query Policy – InitRecvTimeout

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

120

Что делает

Устанавливает время в секундах, за которое клиент после подключения (фактически, после bind) должен отправить первый рабочий запрос на LDAP-операцию. Если тайм-аут проходит, а клиент молчит, его отключают.

Модифицируем, например, в случае использования внешнего ПО, которое любит “подключиться и думать, что сказать для начала”. К такому ПО относится ряд продуктов IBM (например, Lotus Domino), а также продуктов Microsoft – тот же ILM 2007 и FIM 2010. Ситуация достаточно проста – если у Вас есть такое ПО, то, возможно, Вам имеет смысл увеличить тайм-аут хотя бы до 240 секунд (я увеличивал в случае с FIM 2010 до 600, это давало плюсы). Это не приведёт к какой-то дополнительной нагрузке на DC, скорее, наоборот – если ПО разработано так, что оно вначале находит ближайший/лучший DC и “цепляется” за него, после где-то у себя в голове ставит галочку “ОК, подключились, теперь будем, если что, запросы кидать”, и далее штатно делает с AD операции, то не имеет смысла держать тайм-аут таким, чтобы он регулярно сбрасывал подключение этого ПО, приводя ситуацию к “странно, вроде подключились, запрос кидать пробую – ошибка. наверное, AD нерабочая…”. Это может привести в хорошем варианте к повторной аутентикации ПО, в плохом – к неработоспособности и достаточно смутным ошибкам. Учитывайте, что существование данного параметра в не-дефолтном значении будет отрабатываться только в хорошо спроектированном ПО, которое работает с LDAP достаточно качественно. Поэтому в общем случае лучше увеличить этот параметр для “доверенного” ПО – пусть подключается и висит, нагрузки от единичных пустых LDAP-сессий нет, а траблшутить Лотус, который вначале подключается и через полчаса лезет почитать, что там интересного в Active Directory, дело очень унылое.

Данный механизм предназначен для защиты от DDoS, а не для воспитательно-карательных мер в отношении легального ПО. Не имеет смысла “наказывать” специфично спроектированное ПО тем, что сбрасывать его сессию.

Но в случае контроллера, работа с которым ведётся исключительно короткими сессиями (на нём не сидит админ с открытой консолью Active Directory Users & Computers весь день, с него лишь периодически “подкачивают” политику клиентские системы), имеет смысл понизить этот тайм-аут в целях своевременного “сброса” непонятных подключений. Нормальные клиенты подключаются и сразу же делают нужные операции. Опыт настройки в различных инсталляциях показал, что снижение до 15 секунд в такой ситуации является вполне эффективным и никак не влияет на применение групповых политик и LDAP-операции клиентов (даже географически удалённых и с медленными каналами связи).

Ещё раз – это ограничение стартового тайм-аута – т.е. ожидания первой операции клиента. Idle timeout рассматривается дальше.

Параметр Query Policy – MaxConnections

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

5000

Что делает

Обозначает максимально возможное количество одновременных LDAP-подключений на DC. Заметьте – не после ldap bind, а вообще, т.е. в случае с обычным DC это будет математическая сумма подключений по портам TCP 389 и TCP 636. Что интересно, при появлении “лишнего” подключения (в дефолтном случае – 5001го) контроллером будет сброшено какое-то из существующих. Критерий сброса в документации не указан, эксперименты показали, что вроде как сбрасывается самое “старое” подключение, однако не всегда – на одной и той же инсталляции DC иногда сходил с ума и начинал дропить без видимой логики выбора.

Меняем это значение, если думаем о безопасности Active Directory. По сути, данный параметр надо увеличивать хотя бы раз в 10 сразу, потому что иначе атака вида DoS на контроллер домена может быть вполне успешно и оперативно реализована – подключаясь в цикле (даже авторизуясь при этом – кто мешает, читать-то AD могут Authenticated Users, а RootDSE и Everyone) можно легко “догнать” суммарное количество сессий до лимита, а после, продолжая инициировать подключения, заставить контроллер сбрасывать рабочие сессии. При этом с точки зрения системы DC загружен не будет (процессор не нагружен, память не кончилась, сетевой интерфейс не загружен, очереди диска нет), а легальные клиенты испытают проблемы. Правда, когда легальный клиент переподключится, то он “выбьет” одну из фейковых сессий LDAP и, в зависимости от нагрузки, может успеть сделать что-то полезное, пока его, в свою очередь, не “выбьет” скрипт, генерящий фейковые сессии.

Параметр Query Policy – MaxConnIdleTime

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

900

Что делает

Устанавливает время бездействия, после которого подключение штатно разрывается со стороны сервера. Важно: время бездействия – это время от поступления на сервер последнего запроса клиента (т.е. если время бездействия выставить в 30 секунд, а клиент запросил выборку, которая по медленному каналу качалась бы больше 30 секунд, контроллер не даст команде корректно отработать – проверено).

В случае наличия ПО, которое постоянно держит открытой подключение на контроллеры домена (тот же Exchange) тайм-аут можно и увеличить, но 15 минут обычно вроде как достаточно. Замечу, что этот тайм-аут сбрасывает только уже аутентицированного клиента. Поэтому в случае, например, “жесткой” привязки Exchange на DC/GC вполне можно этот тайм-аут увеличить – уменьшите количество переподключений. В случае же работы с внешними сервисами (трудно придумать сходу – ну, например, реализуя публично доступный LDAP-каталог (lol)) тайм-аут можно сократить в разы, хоть до 15 секунд – обычно в таких сценариях клиент подключается, делает штучный запрос, и всё – его можно отключать. Надо – ещё раз придёт.

Параметр Query Policy – MaxDatagramRecv

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

4096 байт

Что делает

Устанавливает максимальный размер UDP-датаграммы, которую обрабатывает DC. Т.е. если придёт датаграмма размером больше указанного, контроллер должен её отбросить.

Надо ли править? Обычно нет по банальной причине – LDAP в Active Directory работает по TCP. Никакого особого КПД найти в ограничении размера UDP-пакета не получится, а раз не получится – то надо взять за правило не трогать параметры без явно подтверждённых на то причин. Есть сценарий, в котором повышение этого размера до 64K может быть позитивным, но он мало относится к теме статьи.

Кстати, ранее (в Windows 2000 Server) это значение было меньше в 4 раза, 1024 байта.

Параметр Query Policy – MaxNotificationPerConn

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

5

Что делает

Определяет максимальное количество стоящих в очереди запросов клиента. Т.е. суть проста – клиент подключается, авторизируется, и делает запрос. Клиенту подтверждают, что запрос начинает выполняться, а клиент уже запрашивает следующий. Формируется очередь LDAP-запросов, а данный параметр ограничивает её. Очередь работает по логике FIFO, а действие этого параметра – обычный tail drop, а клиент получает не подтверждение о постановке запроса в очередь, а ERROR_DS_ADMIN_LIMIT_EXCEEDED.

Модифицируем очень осторожно; с одной стороны – снижение этого числа может достаточно эффективно ликвидировать возможность хитрого DoS’а – фейковый клиент подключается, подтверждает подлинность и начинает доставать сервер запросами – “хочу всех пользователей, у которых поле X похоже на Y”, специально подбирая запросы по таким полям, которые и индексируются, и содержат наиболее обширные данные. Да и ANR тут только ухудшит ситуацию. Вопрос вообще достаточно тонкий, требует понимания и тюнинга всей системы индексации атрибутов объектов в Active Directory и в отрыве от этого рассматриваться не должен. Но в общих чертах – да, уменьшение этого числа для DC, с которыми не работают сервисы типа Exchange, а только обычные клиенты, может оказаться превентивной мерой для описаных выше специфических атак.

Параметр Query Policy – MaxPoolThreads

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

4

Что делает

Определяет количество потоков на одном логическом процессоре, доступном DC/GC. Это будут как потоки для обслуживания входящих из сети запросов, так и потоки для обработки LDAP-поиска. То есть, говоря проще, если Вы поставите DC/GC в виртуальную машину и дадите этой виртуальной машине 2 процессора, данный параметр ограничит число параллельных потоков выполнения до 2*4=8. Потоков, заметьте, а не процессов.

Вполне разумно увеличить этот параметр, если у Вас достаточно производительные процессоры. Теоретически можно придумать DoS-атаку, которая выдаст столько запросов (и достаточно “долгоиграющих”), что контроллер запустит их параллельно, и их количество будет достаточно, чтобы “положить” систему. Смотрите и думайте сами, я лишь могу предложить увеличивать этот параметр для систем с быстрыми CPU – до 10 потоков на процессор.

Параметр Query Policy – MaxReceiveBuffer

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

10,485,760 (10 МБайт)

Что делает

Это – размер буфера для одиночного запроса клиента. Если думаете, что это много, просто вспомните, что запрос – это не обязательно текстовая строчка вида (&(l=Кремль)(|(givenName=Дима)(givenName=Вова))), это может быть и масштабная выборка вида “надо все поля всех клиентов, у кого почта на .ru заканчивается”.

Данный параметр тесно связан с количеством одновременно возможных запросов. По сути, вся его оптимизация – это экономия потенциально выделенной памяти в количестве MaxReceiveBuffer * MaxConnections. Заметьте, память выделяется динамически, поэтому наличие этого буфера в 10МБ и количества подключений в 5000 не говорит о том, что DC/GC попытается выделить 50ГБ под буферизацию LDAP-запросов. Т.е. такое возможно в теории, на практике под каждый запрос сразу 10МБ не выделяется. Лучший вариант – мониторинг Вашей инсталляции Active Directory и, в случае отсутствия запросов подобных размеров, снижение этого числа (которое в реальности сделано с большим запасом). На практике в достаточно больших инсталляциях (несколько тысяч хостов, порядка 20 серверов Exchange) данный параметр, будучи установленым в 1МБ, не вызывал никаких проблем.

Кстати, в своё время (в Windows Server 2003) была ошибка, связаннае с тем, что сервер некорректно выделял память под буфер, если его размер в байтах больше странного числа 10737418. Ошибку давно поправили, лечилась она форсированной установкой буфера в 10485760 байт.

У этого параметра есть верхний лимит – 20971520 (в случае попытки выставить параметр выше по факту будет применено это значение).

Параметр Query Policy – MaxPageSize

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

1000

Что делает

Этот параметр достаточно неочевиден по своей настройке. Суть в том, что это не максимальный размер возвращаемых запросом результатов, а размер одной страницы с этими результатами. Если при поиске будет возвращено большее количество объектов, то они будут возвращаться блоками, которые и называются страницами. Сервер держит эти блоки в RAM пока клиент не заберёт их все либо не сделает unbind.

Модифицируем в случае, если хорошо понимаем LDAP и то, что этот параметр, по сути, меняет баланс между “сформировать много страниц ответа и отдавать по одной быстро” vs “сформировать мало страниц и отдавать подольше, но реже”. Интересным является тот факт, что “родной” клиент LDAP в Windows всегда делает paged-запросы, поэтому в принципе сломать что-то этим параметром трудно. Учтите, что тут есть строгая зависимость от того, какие запросы делает клиент – т.е. в случае наличия “глупого” ПО, которое делает не-paged запросы, Вы реально можете ему помешать работать. Если такого ПО нет, я бы рекомендовал снизить этот параметр до 100 исключительно по причине того, что очень малое число запросов к AD возвращают более 100 объектов, а выделять лишнюю память для буферизации смысла нет.
Верхний лимит параметра – 20000 (в случае попытки выставить параметр выше по факту будет применено это значение).

Вообще, нужно учитывать достаточно простую логику Microsoft – все ldap-запросы должны быть с поддержкой paging, поэтому не-paged запросы в общем-то являются потенциально unsupported. Подробнее, если Вы разработчик, можно найти в документации на ldap_create_page_control.

Параметр Query Policy – MaxQueryDuration

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

120

Что делает

То, что и в названии – максимальное время обработки одиночного запроса. Считается от момента поступления оного, а не от подключения клиента, что логично. Как только время закончится – запрос будет остановлен и клиенту будет возвращена ошибка ERROR_INVALID_PARAMETER.

Тонкость – это произойдёт только если запрос всё выполняется. Если же он уже выполнен, вернул много результатов и их постранично забирает клиент, то клиента не отключат. Т.е. цель этого механизма – отключать запросы, которые “перегревают” DC, а не стирать через 2 минуты результаты уже готовых, которые сформированы и лежат в буфере.

На практике этот параметр можно реально уменьшить, и сильно. Две минуты на формирование результатов запроса – это надо иметь огромный лес, сложнейший запрос к GC и очень медленный сервер. Если это не так, запрос даже в 10 секунд – сложная в реальности штука. Опять же – измеряйте Вашу реальную ситуацию и модифицируйте настройки в случае необходимости. Верхний лимит параметра: 1200 (в случае попытки выставить параметр выше по факту будет применено это значение. хотя трудно себе представляю штатный запрос к DC/GC, который в норме выполняется дольше 20 минут).

Параметр Query Policy – MaxResultSetSize

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

262,144

Что делает

Устанавливает размер памяти в байтах (в байтах, а не как иногда пишут – “в объектах”), выделяемых на все результаты всех активных сейчас paged-запросов. Т.е. ещё раз – на вообще все, которые на сервере сейчас уже выполнены, и клиенты их забирают. И именно на paged, которые постранично забирают клиенты. Если места на кэширование результатов нового запроса не хватает, то (ключевое) удаляются результаты старого. И если клиент продолжит его забирать, то надо бы его выполнить повторно.

Лучше всего увеличить этот параметр хотя бы до мегабайта. В крупных инсталляциях хорошо срабатывает увеличение до 16 (число выбрано по причине мониторинга и обнаружения ситуаций, когда в буфере лежало до 10МБ результатов и взято с небольшим запасом). Цель – отсутствие ситуации, когда результаты нового paged-запроса затирают недополученные клиентом результаты более старого paged-запроса.

Кстати, в документации Microsoft есть опечатка – там параметр иногда называется MaxResultSize. Такого параметра нет, можете проверить. Вообще, конечно, параметр логичнее было бы назвать MaxResultSetsSize или какой-нибудь MaxTotalResultSetsSize, но увы.

Параметр Query Policy – MaxTempTableSize

Поддерживается версиями ОС

С Windows 2000 Server.

Значение по умолчанию

10000

Что делает

Достаточно интересный параметр. Суть его в следующем – когда выполняете достаточно сложный запрос, в котором есть логические операции (например, объединения или пересечения множеств), то возникает необходимость в формировании промежуточных таблиц с результатами выборок. В них лежат так называемые candidate object’ы – объекты, часть из которых попадёт в результат. Если размер промежуточной таблицы превзойдёт указанное число записей, то система перестанет обрабатывать запрос пошагово (выбрать множество -> выделить подмножество -> из него выбрать по критерию -> и т.д.) а перейдёт к т.н. direct scan (будет обрабатывать потенциальные объекты по-одному). Вот этот параметр – это максимальный размер такой таблицы для каждого из запросов.

Подумайте, будут ли у Вас запросы, промежуточные результаты которых будут превышать это число, и, в случае наличия оных, увеличьте этот параметр. И обломайтесь – по факту он не увеличится. Производительность таких запросов серьёзно упадёт и Вы ничего сделать не сможете – в Windows Server 2008 R2 максимальное значение этого параметра как раз 10000. Увы, как ни странно, в Windows Server 2003 это можно было регулировать гибче. Т.е. верхний лимит параметра как раз и есть его значение по умолчанию, 10000 – в случае попытки выставить параметр выше по факту будет применено это значение.

Параметры, существующие с Windows Server 2003

Параметр Query Policy – MaxValRange

Поддерживается версиями ОС

С Windows Server 2003.

Значение по умолчанию

1500

Что делает

Устанавливает максимальное число результатов, являющихся полями одного атрибута одного объекта, которые может вернуть один LDAP запрос. В общем-то ключевое, под что параметр заточен – это атрибут members у группы. Политика появилась в Windows Server 2003 вместе с изменениями в репликации multivalued-атрибутов (если помните, именно тогда и при помощи LVR был убран штатный для Windows 2000 Server конфликт репликации multivalued-атрибутов). Ранее, в Windows 2000 Server, значение было установлено на 1000 и не могло быть изменено штатным способом.

Модифицируем, например, в случае наличия групп с количеством участников выше 1500. Хитрый DoS, блокируемый этим параметром, придумать можно, но вот проблемы с отправкой почты на адрес “Все сотрудники” в случае линейного включения всех учетных записей пользователей в группу придумываются ощутимо быстрее. Хотите упростить ситуацию – ставьте сразу на 5000 – это верхний лимит параметра.

Параметры, существующие с Windows Server 2008 R2

Параметр Query Policy – MaxResultSetsPerConn

Поддерживается версиями ОС

С Windows Server 2008 R2.

Значение по умолчанию

10

Что делает

Устанавливает максимальное число хранимых со стороны сервера результатов поисковых запросов клиента. Модифицируем в случае, если у нас очень много параллельных запросов. Фактически, в хостинговых сценариях (например, хостинг Exchange). Кстати, в случае, если Ваш домен был установлен не сразу как Windows 2008 R2, параметр будет равен нулю (что по факту опять-таки превратит его на поддерживающих этот параметр контроллерах в 10).

Параметр Query Policy – MinResultSets

Поддерживается версиями ОС

С Windows Server 2008 R2.

Значение по умолчанию

3

Что делает

Задаёт минимальное число параллельных запросов для включения режима оптимизации paged-запросов, доступного в NT 6.1. Модифицируем просто – если поставить единицу, тогда режим оптимизации будет инициироваться всегда, и отработка запросов ускорится.

Параметры, существующие с Windows Server 2012

Параметр Query Policy – MaxBatchReturnMessages

Поддерживается версиями ОС

С Windows Server 2016.

Значение по умолчанию

1100

Что делает

Задаёт максимальное число ответов при заказе расширенной операции с полем “хочу пачкой (batch)” – LDAP_SERVER_BATCH_REQUEST_OID. Эти операции – это, допустим, расширенный поиск с флагами LDAP_SERVER_DOMAIN_SCOPE_OID, LDAP_SERVER_SHOW_DELETED_OID, LDAP_SERVER_SHOW_RECYCLED_OID и подобными. В ответ на такой запрос может быть отдано много одиночных LDAP Message – вот как раз их максимальное количество, которое надо закэшировать и отдавать клиенту, здесь и задаётся. Параметр можно увеличить в больших инсталляциях – но надо, конечно, для начала мониторить происходящее, чтобы увидеть, есть ли такие запросы на практике.

Параметры, существующие с Windows Server 2016

Параметр Query Policy – MaxDirSyncDuration

Отключаем жестко заданные лимиты настроек

В многих настройках я указывал, что они жёстко ограничены – можно указать любое значение, просто если оно больше некого X, то оно будет расцениваться как X.

Это появилось с Windows Server 2008 и – что удивительно – это можно отключить. Последовательность действий для этого проста:

1. Открываете редактор – подойдёт ADSI;
2. Открываете редактор атрибутов для объекта CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ваш лес – именно для него, для контейнера!
3. Берёте атрибут dSHeuristic и выставляете ему значение 000000000100000001, если атрибут пустой; этим выставляется битовый флаг fLDAPBypassUpperBoundsOnLimits, который читается DC с Windows Server 2008 и старше;

Делайте это крайне осторожно – это атрибут масштабов леса, у него каждый бит делает что-то определённое – не ошибитесь.

Создаём новую Query Policy

Это достаточно тривиальная задача – откроем ADSI, подцепимся к разделу Configuration, откроем последовательно CN=Services, потом CN=Windows NT, потом CN=Directory Service, потом CN=Query-Policies, и, увидев одинокую политику по умолчанию, создадим новый объект queryPolicy:

У объекта надо будет только задать CN – остальные параметры правятся уже просто, редактированием соответствующего атрибута. Так как он один и в начале статьи приведён, дублировать тут не буду.

Я всё прочитал и поменял все параметры. Что теперь?

Теперь, если всё продолжает работать, можно измерить производительность того, что мы наделали. Не наоборот. Т.е. после тюнинга LDAP-политик в первую очередь всё должно продолжить функционировать, а во вторую – улучшить какие-либо характеристики.

Надеюсь, что данный материал поможет Вам эффективнее работать с инфраструктурой на базе Active Directory, а также покажет, что в данном сервисе есть достаточно много такого, что гораздо интереснее, чем унылые инструкции про “Next->Next->Finish->вроде-кое-как-заработало”.

Техники атаки и защиты LDAP-хранилищ достаточно оригинальны и разнообразны (например, неавторизованный пользователь может заказать априори огромный по количеству результатов запрос, притом запросить, чтобы он (результат запроса) ещё и был отсортирован по неиндексированному атрибуту), поэтому грамотный инженер должен хорошо понимать возможности Active Directory по тюнингу такого функционала.

Удач!

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

Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.

Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.

В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).

Отметим, что LDAPS преимущественно используется сторонними приложениями (имеются в виде не-Microsoft клиенты) в целях защиты передаваемых по сети данных (обеспечить невозможности перехвата имена и паролей пользователей и других приватных данных).

Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.

На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage.

Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template.

На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory).

На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.

На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.

Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.

На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).

В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).

Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.

Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
certutil -ca.cert ca_name.cer

Совет. Файл сертификата сохранится в профиле текущего пользователя и в нашем случае имеет имя ca_name.cer.

А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).

certmgr.exe -add C:ca_name.cer -s -r localMachine ROOT


Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.

Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.

Примечание. Утилита ldp.exe на клиентах устанавливается в составе пакета Remote Server Administration Kit (RSAT): RSAT для Windows 10, для 8.1.

В Windows Server 2016 появились новые довольно интересные новые функции, такие как временное членство в группах AD, Privileged Access Management и т.д. Постараюсь описать их более подробно в следующих статьях. В этой статье я покажу, как установить домен Active Directory в Windows Server 2016. Для установки AD, сервер по минимальным требованиям должен соответствовать следующим условиям:

Процессор:

• 64-битный процессор с частотой не менее 1,4 Ггц
• поддержка NX, DEP, CMPXCHG16b, LAHF/SAHF, PrefetchW, Second Level Address Translation (EPT или NPT)

Память

• не менее 512 Мб (для Server Core и Nano редакций), 2 Гб для версии Windows Server с GUI
• поддержка ECC (Error Correcting Code) или аналогов

Дисковый контроллер и требования к месту:

Дисковый контроллер для установки Windows Server 2016 должен быть совместим со спецификацией PCI Express. Windows Server 2016 не позволяет использовать диски ATA/PATA/IDE/EIDE для загрузки, хранения файла подкачки или дисков с данными

Минимальный размер раздела на систему: 32 Гб

Сетевой адаптер:

• сетевой адаптер Ethernet с пропускной способностью не менее 1 Гб/с
• Совместимость с архитектурой PCI Express
• поддержка PXE (-boot Execution Environment)
• Желательна (но не обязательно) поддержка сетевой отладки (KDNet)

В этом примере я использую виртуальную машину, запущенную на сервере VMWare ESXi, на которую и уставлена Windows Server 2016.

1) Войдите на сервер под локальным администраторов. На сервер кроме роли Active Directory Domain Services также будет установлена служба DNS. Изменим настройки сетевого интерфейса, указав в качестве первичного DNS сервера собственный IP адрес севера или адрес 127.0.0.1.

2) Затем откройте Server Manager, нажав на соответствующий значок или выполнив в консоли PowerShell команду ServerManager.exe.

3) В окне Server Manager нажмите Add roles and features

4) В окне мастера добавления ролей и компонентов нажмите Next.

5) В следующем окне нажмите Next

6) Т.к. установка выполняется на локальный сервер, в следующем окне оставьте переключатель в исходном положении и нажмите Next

7) В следующем окне в списке ролей выберите Active Directory Domain Services. В открывшемся окне появится список ассоциированных компонентов, которые должны быть установлены вместе с ролью ADDS. Нажмите кнопку Add features, а затем Next.

В списке компонентов уже должны быть отмечены требуемые для установки компоненты. Нажмите Next.

9) В следующем окне приведено небольшое описание роли AD DS. Нажмите Next.

10) Ознакомьтесь со списком выбранных для установки ролей и компонентов. Для начала установки нажмите кнопку Install.

11) На экране будет отображаться текущий статус процесса установки

12) После окончания установки, нажмите на ссылку Promote this server to a domain controller.

13) Запустите мастер настройки Active Directory. В моем случае я устанавливаю новый лес AD. В том случае, если вы добавляете дополнительный контроллер домена в существующий домен, выберите соответствующую опцию. Я же выбираю опцию Add a new forest и указывают FQDN имя домена (test.net).

14) В следующем окне нужно указать функциональный уровень домена и леса AD. Я выбрал последнюю версию схемы AD – Windows Server 2016. Кроме того, этот сервер будет выступать сервером DNS и являться Global Catalog. Также нужно указать пароль администратора для входа в DSRM режим.

15) Т.к. мой сервер будет первым DNS сервером в лесу, нет необходимости настраивать делегацию DNS. Поэтому просто нажмите Next.

16) NETBIOS имя домена оставим без изменений (TEST)

17) На следующем экране нужно указать путь к каталогам NTDS, SYSVOL и LOG. Мы оставим все пути по-умолчанию, предполагая, что все папки будут храниться в каталоге системного диска C:Windows.

18) На следующем экране можно ознакомиться со списком выбранных настроек. Если все OK, нажмите Next, если нет – вернитесь назад и внесите изменения.

19) Далее выполнится предварительная оценка выбранной конфигурации, в том случае, если критичных конфликтов не будет, станет доступна кнопка Install.

20) Запустится процесс установки контроллера домена

21) После окончания установки, сервер автоматически перезагрузится. Войдите на сервер под учетной записью администратора домена.

22) После входа, запустите привилегированную сессию powershell и выполните команду dsac.exe. Откроется окно центра администрирования Active Directory (Administrative Center). Можно начинать управлять ресурсами домена

23) С помощью следующих команду можно узнать текущий функциональный уровень домена и леса команд Get-ADDomain | fl Name,DomainMode и Get-ADForest | fl Name,ForestMode

Skip ahead to Setup LDAPS using self-signed cert made with openssl if you do not need any background information.
Also,check out my accompanying github repo which contains all the files used in this guide. Inside, see just_the_commands.md to quickly run through just the commands.

Insecure LDAP is dying, Long Live Secure LDAPS

Microsoft will begin enforcing secure connections for Active Directory LDAP in March of 2020. Update: Microsoft has extended the deadline to «second half of calendar year 2020». This is the third extension Microsoft has made since first announcing this change in 2017. Active Directory has long been a haven of questionable security. Microsoft has made several great improvements for security in recent years and this most recent change is designed to plug one of the long-lived security weaknesses of Active Directory.

Why is it needed

Many services using Active Directory communicate over plain-text LDAP binds on port 389 for authentication and queries. Active Directory joined machines authenticate using windows integrated authentication which uses encrypted methods such as kerberos or NTLM. In the same way that plain-text HTTP is insecure, LDAP is also vulnerable to man-in-the-middle attacks and the exposure of sensitive information such as username/passwords. LDAPS, like HTTPS, transmits its data over an encrypted tunnel using SSL or TLS.

How it works

For Active Directory to use LDAPS, just like a web server using HTTPS, it needs a certificate issued to it and installed. If you are familiar with certs for web servers then you are already familiar with the process. First, create a certificate signing request (CSR), send that to a certificate authority (CA), and then install the client certificate created from the CA. Here is a great article by cloudflare about SSL/TLS and certs.

Self-signed or public CA.

Publicly signed certs are often already trusted by many services, but are not free if the cert has a validity period of greater than a few months. For most systems connecting using LDAPS, this benefit of a cert from a public CA is moot since they have a separate truststore just for LDAPS that typically does not contain any public CAs. For a vast majority of people Self-signed is the way to go, since it is free and you can set long expiration dates.

Why not a Microsoft CA Server

When initially looking to configure LDAPS for AD I looked into creating a Microsoft CA server. I ran into several limitations for my use case. First, I found Microsoft’s documentation to be quite long and unnecessarily confusing. Once I figured it all out, it was not too bad, but as you will see the openssl route is quite a bit easier as long as it fits your use case. The primary reason to use Microsoft CA Server is if you plan on issuing certs for other internal only services like internal web servers. Due to the abundance of methods to get free, publicly signed certs, like Let’s Encrypt for web servers, I prefer to use a publicly signed cert even for internal web servers.

See if your application is using plain-text LDAP

From the server running your application you can look at the outbound network traffic and check if there is anything communicating to one of your AD Domain Controllers IP addresses over the default LDAP port of 389. LDAPS uses port 636. The netstat command can be used on both linux and windows to see your open network connections.

Find connections on port 389: Linux

foo@bar:~$ netstat -antlp | grep 389 | grep ESTABLISHED
tcp        0      0 127.0.0.1:46046         192.168.1.10:389        ESTABLISHED -
tcp        0      0 127.0.0.1:34389         216.58.194.78:443       ESTABLISHED -

We can see that this machine is communicating to port 389 on the ip 192.168.1.10 which is an AD Domain controller in my test environment.

find connections on port 389: Windows

C:Windowssystem32>netstat -ant | findstr 389 | findstr ESTABLISHED
  TCP    127.0.0.1:46046        192.168.1.10:389       ESTABLISHED     InHost
  TCP    127.0.0.1:43894        10.2.212.20:64284      ESTABLISHED     InHost

Again we see 192.168.1.10:389 which indicates a program connecting to a AD controller using LDAP on port 389

Setup LDAPS using self-signed cert made with openssl

Prerequisites

• openssl
• Need to know:
  • your active directory domain name. ex: example.com
  • your active directory domain controller’s name. ex: ad01.example.com

Here is how to install openssl if you do not already have it:

#For Debian/Ubuntu 
sudo apt-get install openssl
#For rhel/centos
sudo yum -y install openssl

It is also possible to install it on windows. See this guide for installing openssl on windows: https://tecadmin.net/install-openssl-on-windows/

Creating your own CA

First create a directory to work in. Pro tip: make your life easy and mount a directory on your AD controller from the machine with openssl. We will need to move a few files back and forth and mounting it over smb makes this easy. See these instructions on how to mount an smb share in Ubuntu

Create a text file named ca_san.conf with the following contents, modifying as needed. ex: «example.com» to your domain.

#ca_san.conf
[ req ]
distinguished_name = req_distinguished_name
req_extensions     = v3_ca

[ req_distinguished_name ]
# Descriptions
countryName=Country Name (2 letter code)
stateOrProvinceName=State or Province Name (full name)
localityName=Locality Name (eg, city)
0.organizationName=Your Company/Organization Name.
1.organizationName=Organizational Unit Name (Department)
commonName=Your Domain Name

#Modify for your details here or answer the prompts from openssl
countryName_default=US
stateOrProvinceName_default=Texas
localityName_default=Dallas
0.organizationName_default=My Company Name LTD.
1.organizationName_default=IT
commonName_default=example.com
[ v3_ca ]
keyUsage=critical,keyCertSign
basicConstraints=critical,CA:TRUE,pathlen:1
extendedKeyUsage=serverAuth
subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also. 
#The *.example.com will allow all Domain controllers with 
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.example.com
DNS.2 = example.com

Next save that file to a directory named LDAPS, then run the following commands to create the CA key and cert:

foo@bar:~$ mkdir LDAPS && cd LDAPS

# generate the ca key, create a password and keep it for use throughout this guide.
foo@bar:~/LDAPS$ openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
...........++++
.............................................................................................++++
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:

# create ca cert with valid of 10 years with info based off the 
# provided ca_san.conf file, it will prompt for the password we created earlier 
foo@bar:~/LDAPS$ openssl req -new -x509 
    -extensions v3_ca 
    -days 3650 
    -key ca.key 
    -out ca.crt 
    -config ca_san.conf

foo@bar:~/LDAPS$ ls
ca.crt  ca.key

Now we have created two files: ca.key and ca.crt

Next, we will add the ca.crt as a Trusted Root Certificate and create a (CSR) on an AD controller

In powershell, as Admin, on an AD controller copy over the ca.crt file and run the following to import it as a Trusted Root Certificate:

#import the cert as a trusted CA on the domain controller
Import-Certificate -FilePath ca.crt  -CertStoreLocation 'Cert:LocalMachineRoot' -Verbose

Create a text file named request.inf with the following contents edited for your environment

;----------------- request.inf -----------------
[Version]
 Signature="$Windows NT$"

;The Subject will need to be your active directory domain name
[NewRequest]
 Subject = "CN=example.com"
 KeySpec = 1
 KeyLength = 4096
 Exportable = TRUE
 MachineKeySet = TRUE
 SMIME = FALSE
 PrivateKeyArchive = FALSE
 UserProtected = FALSE
 UseExistingKeySet = FALSE
 ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
 ProviderType = 12
 RequestType = PKCS10
 KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
 OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
;The following will add a subject alternative name of a wildcard cert on *.example.com
;so any ad controller with a hostname of somththing.example.com can use it.
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=*.example.com&"
_continue_ = "dns=example.com&"

Next, on the AD controller run certreq passing in the request.inf we created and specifying the output file ad.csr

certreq -new request.inf ad.csr

Copy the ad.csr over to your machine with openssl and create a new text file named v3ext.txt with the following contents, editing the alt_names to your domain:

# v3ext.txt
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also. 
#The *.example.com will allow all Domain controllers with 
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.example.com
DNS.2 = example.com

Now run the following command to generate the cert for AD:

# create ad_ldaps_cert by signing the csr
# 825 days is the maximum for a cert to be trusted as dictated by 
# the new 2019 guidelines from the CA/Browser Forum
# This is important since macOS has began to enforce this guideline
openssl x509 -req -days 825 
    -in ad.csr 
    -CA ca.crt 
    -CAkey ca.key 
    -extfile v3ext.txt 
    -set_serial 01 
    -out ad_ldaps_cert.crt

Copy ad_ldaps_cert.crt over to the machine back to the AD Controller and accept the cert

# accept the signed cert 
certreq -accept ad_ldaps_cert.crt

We can check that the cert has been imported by running the following powershell. We should see CN=example.com

PS C:LDAPS> Get-ChildItem "Cert:LocalMachineMy"

   PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy

Thumbprint                                Subject
----------                                -------
087B0AB4E62DCE1D33323209EA81F2D58E0BF3B5  CN=example.com

Great, now our cert is imported and ready to be used. Now we can restart the AD Controller or create the following file and run a command to tell AD to start using LDAPS

enable_ldaps.txt

dn:
changetype: modify
add: renewServerCertificate
renewServerCertificate: 1
-

Then run this command passing in the text file:

PS C:LDAPS> ldifde -i -f enable_ldaps.txt
Connecting to "ad01.example.com"
Logging in as current user using SSPI
Importing directory from file "enable_ldaps.txt"
Loading entries..
1 entry modified successfully.

The command has completed successfully

To test that we can use openssl to connect and verify, we can establish a secure connection to our AD controller

openssl s_client -connect nsut-ad01.example.com:636 -CAfile ca.crt

Add Cert to all domain controllers.

To add the cert and privatekey to all of our domain controllers we need to export the cert/privatekey to a pfx file to be imported on each AD DC.

First, we need to get the Thumbprint of our cert to export it. Run this powershell to list your certs under the Cert:LocalMachineMy cert store:

PS C:LDAPS> Get-ChildItem "Cert:LocalMachineMy"

   PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy

Thumbprint                                Subject
----------                                -------
087B0AB4E62DCE1D33323209EA81F2D58E0BF3B5  CN=example.com

Specify a password and copy the thumbprint from the above output and replace it in the below command to export the cert/private key to a pfx file.

# For security reasons we must create a password to encrypt the privatekey. Edit for YOURPASSWORD
$pfxPass = (ConvertTo-SecureString -AsPlainText -Force -String "YOURPASSWORD")
#export cert/privatekey to a pfx file.
Get-ChildItem "Cert:LocalMachineMy87B0AB4E62DCE1D33323209EA81F2D58E0BF3B5" | Export-PfxCertificate -FilePath LDAPS_PRIVATEKEY.pfx -Password $pfxPass

Now we will have a file named LDAPS_PRIVATEKEY.pfx that contains the cert and privatekey for our active directory domain controllers to use.

Test all the Domain Controllers

The Following Powershell will test all of our Active Directory Domain Controllers for LDAPS:

##################
#### TEST ALL AD DCs for LDAPS
##################
$AllDCs = Get-ADDomainController -Filter * -Server nsuok.edu | Select-Object Hostname
 foreach ($dc in $AllDCs) {
    $LDAPS = [ADSI]"LDAP://$($dc.hostname):636"
    #write-host $LDAPS
    try {
    $Connection = [adsi]($LDAPS)
    } Catch {
    }
    If ($Connection.Path) {
    Write-Host "Active Directory server correctly configured for SSL, test connection to $($LDAPS.Path) completed."
    } Else {
    Write-Host "Active Directory server not configured for SSL, test connection to LDAP://$($dc.hostname):636 did not work."
    }
 }

Congratulations

You now have all your domain controllers configured to use Secure LDAPS. But this is just half the battle, we now need to configure all of our Services, Apps, AD joined macOS computers and Servers to use LDAPS.

How to find what systems and servers are using insecure LDAP Binds

Read my next article to learn how to turn on logging in Active Directory and export the logs to CSV using powershell.
Coming soon.