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

По-умолчанию в 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.

First published on MSDN on Apr 10, 2017


Step-by-step guide for setting up

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

Now let us add AD LDS in our VM ldapstest

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.

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.

Now let us try to connect to the AD LDS Instance CONTOSO using ADSI Edit.

Click on Start —> Search “ADSI Edit” and open it.

Right Click on ADSI Edit Folder (on the left pane) and choose Connect To.. . Fill the following values and Click OK.

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

Setup LDAPS (LDAP over SSL)

The Certificate to be used for LDAPS must satisfy the following 3 requirements:

• Certificate must be valid for the purpose of Server Authentication. This means that it must also contains the Server Authentication object identifier (OID): 1.3.6.1.5.5.7.3.1

• The Subject name or the first name in the Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) of the host machine, such as Subject:CN=contosoldaps. For more information, see How to add a Subject Alternative Name to a secure LDAP certificate .

• The host machine account must have access to the private key.

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:\ProgramData\Microsoft\Crypto\Keys\<UniqueContainerName>

Right Click C:\ProgramData\Microsoft\Crypto\Keys\874cb49a696726e9f435c1888b69f317_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:\Users\azureuser\Desktop\ldapstest.cer”.

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

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

Open Command Prompt in administrator mode. Navigate to “C:\Program Files\Java\jre1.8.0_92\bin\” and run the following command:

keytool -importcert -alias «ldapstest» -keystore «C:\Program Files\Java\jre1.8.0_92\lib\security\cacerts» -storepass changeit -file «C:\Users\azureuser\Desktop\ldapstest.cer»

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

По-умолчанию в 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), который выдал сертификат для контроллера домена.

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

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

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

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

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.

---

Applies To:

Windows Server 2012, Windows Server 2012 R2 Preview

DoLdapInitialize

ADDS standard ports are opened during DCPROMO mainly LDAP initiation. Ports are opened during dsa init, specifically in ‘ DoLdapInitialize’ — If we stop the ‘Active Directory Domain Service’ in service.msc neither of the port is listening.

My main purpose of this article is ldaps service & msft-gc-ssl service . Port 636 & 3269 are listing after promoting a DC. We can test that using Telnet, PortQuery , Netmon or Wireshark etc. The result below is taken from newly built DC using PortQry.

PortQry output after promoting a DC for SSL ports.

There is fantastic tool called LDP.EXE which was the part of the windows support tools in earlier version of windows OS (2003). Now days if we installed a DC automatically that is available into a DC due to RSAT. We can connect port 389 & 3268 through ldp
but not 636/3269. Those SSL ports are only listened LDAPS when we put the valid certificate into DCs. We need valid SAN, Intended purpose for that certificate (EKU).

LDP.EXE output after connecting the SSL ports.

If your certificate server itself a DC then you no need to worry for SSL ports. Those ports are connected through LDP.EXE.

NETMON capture for SSL Ports

Also Netmon results are taken after putting the valid certificate into a Domain Controller. Used the filter » LDAP». Also you can use «.Protocol.LDAP». You will get the same result. Here I have installed the netmon in DC.

Listening the ldaps Port (636) into the below Capture

Listening the  gc-ssl Port (3269) into the below Capture

Network capture without netmon

Also you can trace without the Netmon/WireShare. Using Netsh but it is applicable Windows 2008R2 and Windows 7 and upper version OS.

For starting the capture.

netsh trace start capture=yes tracefile=cap.etl

For stopping the capture

netsh trace stop

For reading the .etl file you need the netmon anywhere.

Netsh trace will be created two files. see the below snap. For reading the .etl file you need to select the Windows Parser in Netmon.

Cert server into a domain controller is not recommended.

We need additional steps for listening the ssl ports for DCs If cert server in a member server .We need to publish the certificate template into the cert server & that certificate template need to put DC’s local computer->personal or NTDS->Personal store.

Local computer->personal store

NTDS->Personal store

(This store is available only in DC. When we have more than one cert template for Server Authentication, we can use this store for avoiding the conflict)

Publish a cert Template

Here I have used «Kerberos Authentication» template for publishing the new certificate template.

Log into the certificate server . Run » certtmpl.msc» & chose the   Kerberos Authentication Template.

We need to set few properties before publishing a certificate template. Those are marked as green.

Click on Duplicate Templete.

Publish cert in AD.

Allow Pvt. key to be exported.

Subject Name format

After publishing that cert you can check the properties using » certutil -v -template <Template_Name>». Here my cert template name is LDAPSSL. See the following output.

certutil -v -template LDAPSSL

PS C:> certutil -v -template LDAPSSL

  Name: Active Directory Enrollment Policy

  Id: {32376692-6063-4EDC-A375-572FED78C626}

  Url: ldap:

34 Templates:

  Template[21]:

  TemplatePropCommonName = LDAPSSL

  TemplatePropFriendlyName = LDAPSSL

  TemplatePropEKUs =

4 ObjectIds:

    1.3.6.1.5.2.3.5 KDC Authentication

    1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    1.3.6.1.5.5.7.3.1 Server Authentication

    1.3.6.1.5.5.7.3.2 Client Authentication

  TemplatePropCryptoProviders =

    0: Microsoft RSA SChannel Cryptographic Provider

  TemplatePropMajorRevision = 64 (100)

  TemplatePropDescription = Computer

  TemplatePropSchemaVersion = 2

  TemplatePropMinorRevision = 1

  TemplatePropRASignatureCount = 0

  TemplatePropMinimumKeySize = 800 (2048)

  TemplatePropOID =

    1.3.6.1.4.1.311.21.8.1546289.5796744.12012220.14775765.9035062.224.8004685.4056790 LDAPSSL

  TemplatePropV1ApplicationPolicy =

4 ObjectIds:

    1.3.6.1.5.2.3.5 KDC Authentication

    1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    1.3.6.1.5.5.7.3.1 Server Authentication

    1.3.6.1.5.5.7.3.2 Client Authentication

  TemplatePropEnrollmentFlags = 28 (40)

    CT_FLAG_PUBLISH_TO_DS -- 8

    CT_FLAG_AUTO_ENROLLMENT -- 20 (32)

  TemplatePropSubjectNameFlags = 18c00000 (415236096)

    CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS -- 400000 (4194304)

    CT_FLAG_SUBJECT_ALT_REQUIRE_SPN -- 800000 (8388608)

    CT_FLAG_SUBJECT_ALT_REQUIRE_DNS -- 8000000 (134217728)

    CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN -- 10000000 (268435456)

  TemplatePropPrivateKeyFlags = 10 (16)

    CT_FLAG_EXPORTABLE_KEY -- 10 (16)

  TemplatePropGeneralFlags = 20060 (131168)

    CT_FLAG_AUTO_ENROLLMENT -- 20 (32)

    CT_FLAG_MACHINE_TYPE -- 40 (64)

    CT_FLAG_IS_MODIFIED -- 20000 (131072)

  TemplatePropSecurityDescriptor = O:LAG:EAD:PAI(OA;;RPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;RO)(OA;;RPCR;a05b8cc2

bc-4802-a710-e7c15ab866a2;;RO)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DA)(OA;;RPWPCR;0e10c968-78fb-11d2-90d

0c04f79dc55;;DD)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;EA)(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2

D)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;ED)(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;ED)(A;;CCDCL

RPWPDTLOSDRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;LA)(A;;LCRPLORC;;;AU)

     Allow Enroll        CONTOSOEnterprise Read-only Domain Controllers

    Allow Auto-Enroll   CONTOSOEnterprise Read-only Domain Controllers

    Allow Enroll        CONTOSODomain Admins

    Allow Enroll        CONTOSODomain Controllers

    Allow Enroll        CONTOSOEnterprise Admins

    Allow Auto-Enroll   CONTOSODomain Controllers

    Allow Enroll        NT AUTHORITYENTERPRISE DOMAIN CONTROLLERS

    Allow Auto-Enroll   NT AUTHORITYENTERPRISE DOMAIN CONTROLLERS

    Allow Full Control  CONTOSODomain Admins

    Allow Full Control  CONTOSOEnterprise Admins

    Allow Full Control  CONTOSOAdministrator

    Allow Read  NT AUTHORITYAuthenticated Users

  TemplatePropExtensions =

4 Extensions:

  Extension[0]:

    1.3.6.1.4.1.311.21.7: Flags = 0, Length = 30

    Certificate Template Information

        Template=LDAPSSL(1.3.6.1.4.1.311.21.8.1546289.5796744.12012220.14775765.9035062.224.8004685.4056790)

        Major Version Number=100

        Minor Version Number=1

  Extension[1]:

    2.5.29.37: Flags = 0, Length = 2b

     Enhanced Key Usage

        KDC Authentication (1.3.6.1.5.2.3.5)

        Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

        Server Authentication (1.3.6.1.5.5.7.3.1)

        Client Authentication (1.3.6.1.5.5.7.3.2)

  Extension[2]:

    2.5.29.15: Flags = 1(Critical), Length = 4

    Key Usage

        Digital Signature, Key Encipherment (a0)

  Extension[3]:

    1.3.6.1.4.1.311.21.10: Flags = 0, Length = 33

    Application Policies

        [1]Application Certificate Policy:

             Policy Identifier=KDC Authentication

        [2]Application Certificate Policy:

             Policy Identifier=Smart Card Logon

        [3]Application Certificate Policy:

             Policy Identifier=Server Authentication

        [4]Application Certificate Policy:

             Policy Identifier=Client Authentication

   TemplatePropValidityPeriod = 1 Years

  TemplatePropRenewalPeriod = 6 Weeks

CertUtil: -Template command completed successfully.

PS C:>

Find that Template from computer store using «certutil -store my». See the below snap.

Find the Template Details using «V» switch.

Enabling/Disabling CryptoAPI 2.0

Enabling CryptoAPI 2.0 Diagnostic Logging

wevtutil sl microsoft-windows-capi2/operational /e:True

Disabling CryptoAPI 2.0 Diagnostic Logging

wevtutil sl microsoft-windows-capi2/operational /e:False

More details for Troubleshooting PKI Problems on Windows

Troubleshooting PKI Problems on Windows

PKI Info; those are stored in AD ; See the following Snap.using ADSIEDIT.MSC

Also you can see the ADCS info using DSSITE.MSC

Some key Points.

1. Cert Templates are stored in AD (Configuration Partition).
2. Enterprise Certificate Server in a Domain controller is enabled LDAPS(636) & GC SSL(3269) ports for all the Domain controller)
   1. [Due to Certificate Template  Domain Controller]
3. If all Sub CAs host the same certificate templates for enrolment those servers we can use for Redundancy & fault tolerance.
4. Also you can use Certificate server cluster for Redundancy & fault tolerance.

PKI Events.

(Snap is taken from Windows Server 2008 PKI — Brian Komar)

Certificate Server Registry Key (Path)

We are used «certutil -setreg» for changing those keys.

___________________________________________________

Some Useful Links

1. How to enable LDAP signing in Windows Server 2008
2. TroubleshootingLDAP Over SSL
3. Reading LDAP SSL Network Traffic with NetMon 3.4 and NMDecrypt
4. How to decrypt an SSL or TLS session by using Wireshark
5. How to enable LDAP over SSL with a third-party certification authority
6. Certutil Examples for Managing Active Directory Certificate Services (AD CS)
   from the Command Line
7. Configure SSL/TLS on a Web site in the domain with an Enterprise CA
8. What’s New in AD CS and PKI?
9. How to add a Subject Alternative Name to a secure LDAP certificate
10. Custom Certificate Request in Windows Vista
11. Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority
12. Publish certificates in a foreign Active Directory forest
13. Exporting Certificates using CertUtil
14. VPN Client Compatibility with Windows 7 and Windows Server 2008 R2
15. Online Responder Installation, Configuration, and Troubleshooting Guide
16. LDAP client tracing… using Tracelog
17. HowTo: Determine if a user has logged on via smart card 

LDAP (Lightweight Directory Access Protocol) — это протокол для доступа к службам каталогов, который широко применяется в Windows Server 2012 для управления пользователями, группами и другой информацией. LDAP также используется для проверки подлинности и авторизации пользователей. Настройка LDAP на сервере Windows Server 2012 является важным шагом для обеспечения безопасности и эффективной работы сети.

В этой статье мы рассмотрим шаги по настройке LDAP на сервере Windows Server 2012. Мы рассмотрим, как установить и настроить службу Active Directory Domain Services (AD DS) и как создать и настроить объекты каталога, такие как пользователи и группы. Мы также рассмотрим процесс настройки авторизации и проверки подлинности через LDAP.

Вам понадобятся права администратора для выполнения этих шагов. Перед началом настройки LDAP удостоверьтесь, что ваш сервер Windows Server 2012 находится в рабочем состоянии и имеет подключение к Интернету. Также убедитесь, что у вас есть все необходимые учетные данные и информация о сети, такие как IP-адрес сервера и домена, которые вы хотите использовать для настройки LDAP.

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

Установка Windows Server 2012

1. Вставьте загрузочный носитель (диск или флешку) с операционной системой Windows Server 2012 в компьютер или сервер.
2. Перезагрузите компьютер или сервер и выберите загрузку с установочного носителя.
3. На экране выбора региона и языка, выберите соответствующие настройки и щелкните «Далее».
4. Нажмите на ссылку «Установить сейчас» на экране «Установка операционной системы».
5. Примите лицензионное соглашение и нажмите «Далее».
6. На экране выбора типа установки, выберите «Пользовательская: установка новой копии с удалением всех старых данных» и нажмите «Далее».
7. Выберите диск для установки операционной системы и нажмите «Далее».
8. Дождитесь завершения установки операционной системы.
9. После завершения установки будет запущен мастер настройки Windows Server 2012, который поможет вам настроить базовые параметры операционной системы.
10. Следуйте инструкциям мастера настройки для настройки имени компьютера, пароля администратора и других необходимых параметров.

После завершения мастера настройки Windows Server 2012 вы будете готовы приступить к настройке LDAP на сервере.

Создание учетной записи администратора

1. Откройте Панель управления на сервере Windows Server 2012.

2. Выберите Учетные записи пользователей в меню Управление пользователями.

3. Нажмите на Создать новую учетную запись.

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

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

6. Включите или отключите опцию Изменение пароля при следующем входе, в зависимости от ваших требований безопасности.

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

8. Нажмите на Создать, чтобы завершить процесс создания учетной записи администратора.

Теперь у вас есть учетная запись администратора, которую можно использовать для управления сервером Windows Server 2012 через LDAP.

Установка службы Active Directory

1. Запустите Установщик Windows Server 2012 и выберите «Добавить роли и компоненты».

2. В Стандартном установочном типе выберите «Службы домена Active Directory».

3. Инструкция по конфигурации появится после выбора службы домена Active Directory. Нажмите «Добавить службы домена Active Directory».

4. Появится окно с предупреждением о необходимости установки роли DNS сервера. Нажмите «Добавить роли и функции».

5. Выберите «Сервер DNS» в списке ролей и нажмите «Далее».

6. Появится окно с предупреждением о необходимости установки роли AD DS (службы домена Active Directory). Нажмите «Добавить роли и функции».

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

8. Прочитайте описание настройки службы домена Active Directory и нажмите «Далее».

9. Настройте опции установки службы домена Active Directory по своему усмотрению и нажмите «Далее».

10. Подтвердите выбранные опции установки и нажмите «Установить».

11. Дождитесь завершения установки службы домена Active Directory.

12. После завершения установки службы домена Active Directory, сервер будет перезапущен.

Создание контейнера для LDAP

Прежде чем мы сможем настраивать службу LDAP в Windows Server 2012, нам необходимо создать контейнер для хранения данных.

Вот шаги, которые нужно выполнить для создания контейнера:

1. Откройте «Службы компонентов» через «Панель управления».
2. В меню «Вид» выберите «Каталоги» и перейдите в «Активные каталоги».
3. Нажмите правой кнопкой мыши на папке «Активные каталоги» и выберите «Новый» -> «Каталог».
4. Установите имя для контейнера, например, «LDAP».
5. Во вкладке «Параметры» установите тип контейнера как «Корневой контейнер».
6. Нажмите «ОК», чтобы создать контейнер.

Поздравляю, вы только что создали контейнер для LDAP! Теперь мы готовы приступить к настройке службы LDAP в Windows Server 2012.

Создание группы пользователей

1. Откройте «Панель управления» на сервере Windows Server 2012.

2. Выберите «Инструменты» и затем «Установка и удаление ролей».

3. Выберите «Добавить роль» и выберите «Служба домена Active Directory». Нажмите «Далее».

4. Пройдите по мастеру установки, приняв стандартные настройки. Нажмите «Далее» и «Установить».

5. После установки службы домена Active Directory, вернитесь в «Панель управления».

6. Выберите «Администрирование служб Active Directory» и затем «Пользователи и компьютеры Active Directory».

7. Щелкните правой кнопкой мыши на «Пользователи» в разделе «Домен» и выберите «Новая группа».

8. Введите имя группы, которое хотите создать, и нажмите «ОК».

9. Выберите «Добавить» и введите имя пользователей, которых вы хотите добавить в данную группу.

10. Нажмите «ОК», чтобы завершить создание группы пользователей.

Поздравляю! Вы успешно создали группу пользователей в службе домена Active Directory на сервере Windows Server 2012.

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

Чтобы настроить разрешения для группы в Windows Server 2012, выполните следующие шаги:

1. Откройте «Диспетчер сервера» и выберите «Пользователи и группы».
2. Найдите нужную группу в списке и щелкните правой кнопкой мыши на ней.
3. В контекстном меню выберите «Свойства».
4. На вкладке «Разрешения» нажмите «Добавить».
5. Введите имя или группу, для которых вы хотите настроить разрешения, и нажмите «Проверить имена».
6. Выберите нужные разрешения из списка.
7. Нажмите «ОК» для сохранения настроек.

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

Создание пользователей в LDAP

Для создания пользователей в LDAP в Windows Server 2012 выполните следующие шаги:

1. Откройте «Управление пользователями и группами» в меню «Серверный менеджер».
2. Щелкните «Создать» в разделе «Действия».
3. Выберите «Пользователь» и нажмите «Далее».
4. Введите имя и фамилию пользователя.
5. Введите имя учетной записи.
6. Введите пароль и подтвердите его.
7. Нажмите «Далее» и укажите необходимые параметры, такие как дата окончания действия учетной записи и роль пользователя.
8. Нажмите «Готово», чтобы создать пользователя в LDAP.

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

Обратите внимание, что для создания пользователей в LDAP вам может потребоваться наличие соответствующих прав доступа.

LDAP (Lightweight Directory Access Protocol) – это протокол, который используется для доступа к и управления информацией о пользователях и ресурсах в распределенной сети. Обычно LDAP используется для настройки централизованного каталога, который содержит информацию о пользователях, группах и других объектах в сети.

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

Процесс настройки LDAP включает в себя несколько шагов, которые мы рассмотрим далее. Сначала мы установим и настроим роль службы каталога Active Directory на сервере. Затем мы создадим и настроим объекты в каталоге, такие как пользователи и группы. Наконец, мы проверим работу LDAP, чтобы убедиться, что все настроено правильно.

Важно помнить, что настройка LDAP на Windows Server 2012 R2 требует административных привилегий и базовых знаний сетевой инфраструктуры. Рекомендуется проводить настройку под руководством опытного специалиста.

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

Что такое LDAP

LDAP (Lightweight Directory Access Protocol) — это протокол, который используется для доступа к службам каталога. Он позволяет клиентам выполнить поиск, добавление, изменение и удаление записей в каталоге.

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

LDAP является стандартом в индустрии и широко используется в сетевых приложениях, таких как веб-серверы, электронная почта, VPN и множество других систем. Он обеспечивает простой и эффективный способ хранения и доступа к данным в каталогах, что делает его очень полезным инструментом для организации и управления информацией о пользователях и ресурсах в сети.

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

LDAP использует иерархическую модель организации данных, где информация о пользователях и ресурсах хранится в виде древовидной структуры. Каждая запись в каталоге имеет уникальное имя, которое состоит из компонентов, разделенных запятыми. Компоненты называются rDN (Relative Distinguished Name) и определяют положение записи в древовидной структуре.

LDAP также поддерживает различные атрибуты, которые описывают данные в записях. Атрибуты могут быть одиночными или множественными, и хранят информацию, такую как имена, адреса, телефоны и другие характеристики объектов.

Использование LDAP для настройки службы каталога на Windows Server 2012 R2 позволяет эффективно управлять пользователями и ресурсами в сети, обеспечивая централизованное хранение и доступ к информации.

Преимущества использования LDAP на Windows Server 2012 R2

LDAP (Lightweight Directory Access Protocol) — протокол доступа к каталогам, который служит для управления и доступа к информации в иерархических каталогах. Использование LDAP на сервере Windows Server 2012 R2 имеет несколько преимуществ.

1. Централизованное управление данными. LDAP предоставляет возможность хранить и организовывать информацию о пользователях, группах, ресурсах и других объектах в централизованном каталоге. Это позволяет администраторам эффективно управлять данными, контролировать доступ и осуществлять авторизацию пользователей.
2. Удобный поиск и доступ к данным. С помощью LDAP на Windows Server 2012 R2 можно выполнять быстрый и эффективный поиск информации в каталоге. Пользователи могут получать доступ к данным через LDAP-клиенты, такие как Active Directory Users and Computers, что упрощает проведение операций с данными и повышает производительность.
3. Интеграция с другими системами. LDAP обеспечивает возможность интеграции с различными системами, такими как почтовые серверы, веб-приложения, VPN-серверы и др. Это позволяет синхронизировать данные и обеспечить единый доступ к ним, что способствует повышению эффективности работы и безопасности системы.
4. Управление доступом и безопасностью. LDAP предоставляет механизмы аутентификации, контроля доступа и шифрования данных. Это позволяет обеспечить безопасность информации, контролировать доступ пользователей к ресурсам и предотвращать несанкционированный доступ к данным.

В целом, использование LDAP на Windows Server 2012 R2 позволяет организовать эффективное управление данными, повысить безопасность и удобство доступа к информации. Это способствует повышению производительности и эффективности работы системы в целом.

Установка и настройка LDAP

Шаг 1: Установка роли LDAP

1. Откройте панель управления сервером и выберите «Установка и удаление ролей».
2. На экране выбора ролей установите отметку напротив «Службы доменных служб» и нажмите «Далее».
3. Продолжайте установку, выбрав установку «Локального сервера AD DS» и нажав «Далее».
4. По завершении установки сервер будет перезагружен.

Шаг 2: Создание и настройка домена

1. После перезагрузки сервера, откройте «Server Manager» и выберите «Добавить роль и функцию».
2. Первым этапом выберите «Установка процесса» и нажмите «Далее».
3. На странице выбора ролей выберите «Службы доменного контроллера Active Directory» и нажмите «Далее».
4. Продолжайте установку, выбрав установку «Базовый службы домена» и нажав «Далее».
5. Настройте имя вашего домена и дадайте необходимые учетные данные.
6. Завершите установку и перезагрузите сервер.

Шаг 3: Создание и настройка LDAP

1. Откройте «Server Manager» и выберите «Функции».
2. Выберите «Добавить функцию» и найдите «Службы доменного поля LDAP».
3. Установите флажок напротив «Службы доменного поля LDAP» и нажмите «Установить».
4. После установки переходите к настройкам LDAP, указав необходимые параметры, такие как порт, SSL и директорию.
5. Сохраните настройки и перезапустите службу LDAP для применения изменений.

Шаг 4: Проверка настройки LDAP

1. Откройте командную строку и введите команду «telnet localhost порт», где порт — это номер порта вашей службы LDAP.
2. Если соединение установлено успешно, вы будете подключены к службе LDAP и увидите результаты запроса.
3. Для проверки работы LDAP можно использовать также специальное программное обеспечение, например, LDAP Browser или LDAP Admin.

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

Шаг 1: Установка роли LDAP

Перед тем, как начать настраивать LDAP на Windows Server 2012 R2, необходимо установить соответствующую роль на сервере.

Для установки роли LDAP следуйте следующим шагам:

1. Запустите «Серверный менеджер» на сервере Windows Server 2012 R2.
2. На панели навигации слева выберите «Управление» и затем «Добавить роли и компоненты».
3. В мастере добавления ролей и компонентов нажмите «Далее».
4. Выберите сервер, на котором желаете установить роль LDAP, и нажмите «Далее».
5. В списке ролей найдите «Службы доменных служб каталогов» и отметьте его галочкой.
6. В появившемся окне «Служба доменных служб каталогов» нажмите «Добавить функции».
7. Нажмите «Далее» и затем «Установить». Подождите, пока установка роли не будет завершена.
8. После завершения установки нажмите «Закрыть».

Теперь роль LDAP установлена на сервере Windows Server 2012 R2 и готова к настройке.

Шаг 2: Создание домена Active Directory

После установки Windows Server 2012 R2 на компьютер сервера, необходимо создать домен Active Directory, который позволит управлять пользователями и группами в сети.

Для создания домена Active Directory выполните следующие шаги:

1. Запустите «Server Manager» с рабочего стола или из меню «Start».
2. На главной странице «Server Manager» нажмите на «Add roles and features» в разделе «Dashboard».
3. В открывшемся «Add Roles and Features Wizard» нажмите «Next» на первом экране.
4. Выберите «Role-based or feature-based installation» и нажмите «Next».
5. Выберите сервер, на котором будет создан домен Active Directory, и нажмите «Next».
6. На экране «Server Roles» найдите «Active Directory Domain Services» и отметьте его галочкой. Затем нажмите «Next».
7. На экране «Features» можно оставить значения по умолчанию и нажать «Next».
8. На экране «AD DS» нажмите «Next».
9. На экране «Confirm installation selections» нажмите «Install».
10. После завершения установки нажмите «Close».
11. В «Server Manager» нажмите на «Promote this server to a domain controller» в разделе «Notifications».
12. В открывшемся «Active Directory Domain Services Configuration Wizard» выберите «Add a new forest» и укажите имя вашего домена. Затем нажмите «Next».
13. Выберите уровень функциональности домена и леса, а также пароль администратора домена. Затем нажмите «Next».
14. Укажите путь для файлов базы данных, журнала транзакций и SYSVOL. Затем нажмите «Next».
15. На экране «DNS Options» оставьте автоматическую настройку и нажмите «Next».
16. На экране «Additional Options» можно оставить значения по умолчанию и нажать «Next».
17. На экране «Paths» можно оставить значения по умолчанию и нажать «Next».
18. Проверьте все выбранные параметры и нажмите «Next» для начала установки.
19. После завершения установки компьютер будет перезагружен и создан новый домен Active Directory.

Теперь вы создали домен Active Directory на сервере Windows Server 2012 R2. В следующих шагах вы сможете добавить и управлять пользователями и группами в вашей сети.

Шаг 3: Настройка параметров LDAP

После установки службы LDAP на Windows Server 2012 R2 необходимо настроить параметры службы, чтобы обеспечить корректную работу и безопасность системы. Ниже приведены основные параметры, которые следует настроить при настройке LDAP.

1. Настройка прослушивающих портов

LDAP использует TCP/IP протокол для общения между клиентами и сервером. По умолчанию, LDAP слушает порт 389 для обычного соединения и порт 636 для защищенного соединения с использованием SSL/TLS.

Чтобы настроить порты, откройте файл конфигурации службы LDAP (обычно расположен в директории C:\Windows\System32\ldap.conf) и отредактируйте следующие строки:

# Порт для обычного соединения
LDAP_PORT=389
# Порт для защищенного соединения с использованием SSL/TLS
LDAPS_PORT=636

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

2. Настройка аутентификации

LDAP поддерживает различные методы аутентификации, такие как базовая аутентификация и аутентификация с использованием SASL. При настройке LDAP следует выбрать подходящий метод аутентификации в зависимости от требований системы и безопасности.

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

# Метод аутентификации
LDAP_AUTH_METHOD=simple

В данном примере используется базовая аутентификация (simple). После выбора метода аутентификации, сохраните файл и перезапустите службу LDAP.

3. Настройка доступа к данным

LDAP позволяет настраивать доступ к данным с помощью правил доступа или списков контроля доступа (ACL). С помощью ACL можно указать, кто имеет доступ к каким данным и с какими правами.

Для настройки ACL, откройте файл конфигурации службы LDAP и добавьте следующую секцию:

# ACL
ACCESS_CONTROL=["dn.subtree",""

"by anonymous auth",

"by self write",

"by * read"]

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

Сохраните файл после внесения изменений и перезапустите службу LDAP.

4. Настройка стратегий безопасности

LDAP поддерживает различные стратегии безопасности, такие как использование SSL/TLS для защиты соединения и авторизацию на основе сертификатов.

Для настройки стратегий безопасности, откройте файл конфигурации службы LDAP и отредактируйте следующие строки:

# Использовать или не использовать SSL/TLS
USE_TLS=true
# Путь к сертификатам SSL/TLS
CERTIFICATE_PATH=C:\path\to\certificate
# Путь к приватному ключу SSL/TLS
PRIVATE_KEY_PATH=C:\path\to\private_key

Сохраните файл после внесения изменений и перезапустите службу LDAP.

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

Шаг 4: Проверка функциональности LDAP

После настройки сервера LDAP на Windows Server 2012 R2 необходимо проверить его функциональность, чтобы убедиться, что все работает корректно. Для этого можно использовать различные инструменты и методы.

1. Проверка настройки порта

1. Убедитесь, что порт LDAP (по умолчанию 389) открыт и доступен для подключения. Для этого можно использовать команду Telnet:

   telnet localhost 389

   Если соединение установлено успешно и вы видите пустой экран, значит порт открыт.

2. Проверка настройки аутентификации

1. Проверьте, что корректно заданы учетные данные для аутентификации на сервере. Для этого можно использовать консольную утилиту ldapsearch:

   ldapsearch -x -D "имя_пользователя" -W -b "базовый_путь_домена"

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

3. Проверка поиска объектов

1. Проверьте, что сервер корректно выполняет поиск объектов. Для этого можно использовать консольную утилиту ldapsearch с фильтром:

   ldapsearch -x -D "имя_пользователя" -W -b "базовый_путь_домена" "(условие_поиска)"

   Условие поиска может быть любым, например, «(objectClass=пользователь)». Если получите список найденных объектов, значит поиск работает.

Правильная настройка и функционирование сервера LDAP на Windows Server 2012 R2 открывает широкие возможности для управления и аутентификации пользователей в системе. После проведения указанных проверок можно приступать к использованию данного сервиса на практике.