Ldap сервер windows 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:ProgramDataMicrosoftCryptoKeys<UniqueContainerName>

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

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

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

This opens the Certificate Export Wizard. Click Next.

Do not export the private key. Click Next.

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

Exporting the .CER to Desktop. Click Next.

Click Finish to complete the certificate export.

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

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

C:Program FilesJavajre1.8.0_92binkeytool.exe.

Open Command Prompt in administrator mode. Navigate to “C:Program FilesJavajre1.8.0_92bin” and run the following command:

keytool -importcert -alias «ldapstest» -keystore «C:Program FilesJavajre1.8.0_92libsecuritycacerts» -storepass changeit -file «C:UsersazureuserDesktopldapstest.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

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.

Активный каталог — Включение LDAP над SSL

Хотите узнать, как установить службу Active Directory и включить функцию LDAP по SSL на сервере Windows- ими? В этом уроке мы покажем вам, как включить функцию LDAP над SSL на компьютере под управлением сервера Windows.

• Windows 2012 R2

Список оборудования:

В следующем разделе представлен список оборудования, используемого для создания этого руководства Windows.

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

Плейлист Windows:

На этой странице мы предлагаем быстрый доступ к списку видео, связанных с установкой Windows.

Не забудьте подписаться на наш канал YouTube под названием FKIT.

Windows Связанные Учебник:

На этой странице мы предлагаем быстрый доступ к списку учебников, связанных с Windows.

Учебник — Активная установка каталога на Windows

• IP — 192.168.15.10.
• Оперативная система — Windows 2012 R2
• Hostname — TECH-DC01
• Активный домен каталога: TECH.LOCAL

Если у вас уже есть домен Active Directory, вы можете пропустить эту часть учебника.

Откройте приложение «Менеджер сервера».

Доступ к меню Управления и нажмите на Добавление ролей и функций.

Получите доступ к ролевой экрану сервера, выберите службу домена Active Directory и нажмите на кнопку Next.

На следующем экране нажмите на кнопку Добавить функции.

Продолжайте нажимать на кнопку Next, пока не достигнете последнего экрана.

На экране подтверждения нажмите на кнопку «Установка».

Подождите, пока будет завершена установка Active каталога.

Откройте приложение «Менеджер сервера».

Нажмите на меню желтого флага и выберите опцию продвижения этого сервера до контроллера домена

Выберите опцию добавления нового леса и введите корневое доменное имя.

В нашем примере мы создали новый домен под названием: TECH. Местных.

Введите пароль для обеспечения восстановления Active Directory.

На экране параметров DNS нажмите на кнопку Next.

Проверьте имя Netbios, назначенное вашему домену, и нажмите на кнопку Next.

Нажмите на кнопку «Следующая».

Просмотрите параметры конфигурации и нажмите на кнопку Next.

На экране проверки предпосылок нажмите на кнопку «Установка».

Подождите завершения конфигурации Active Directory.

После завершения установки Active каталога компьютер перезаработает автоматически

Вы закончили конфигурацию Active каталога на сервере Windows.

Учебник — Тестирование LDAP на SSL связи

Мы должны проверить, если ваш контроллер домена предлагает УСЛУГу LDAP по SSL в порту 636.

На контроллере домена получите доступ к меню «Пуск» и ищите приложение LDP.

Во-первых, давайте проверим, если ваш контроллер домена предлагает услугу LDAP на порту 389.

Получите доступ к меню Connection и выберите опцию Connect.

Попробуйте подключиться к localhost с помощью порта TCP 389.

Вы должны быть в состоянии подключиться к службе LDAP на localhost порт 389.

Теперь нам нужно проверить, если ваш контроллер домена предлагает услугу LDAP по SSL в порту 636.

Откройте новое приложение LDP Window и попытайтесь подключиться к локальному хозяину с помощью порта TCP 636.

Выберите флажок SSL и нажмите на кнопку Ok.

Если система отображает сообщение об ошибке, контроллер домена пока не предлагает услугу LDAPS.

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

Если вы смогли успешно подключиться к localhost в порту 636 с помощью SSL-шифрования, вы можете пропустить следующую часть этого учебника.

Учебник — Установка сертификационного органа на Windows

Нам необходимо установить службу сертификации Windows.

Местный сертификационный орган предоставит контроллеру доменов сертификат, который позволит службе LDAPS работать на порте TCP 636.

Откройте приложение «Менеджер сервера».

Доступ к меню Управления и нажмите на Добавление ролей и функций.

Получите доступ к ролевой экрану сервера, выберите службу сертификата Active Directory и нажмите на кнопку Next.

На следующем экране нажмите на кнопку Добавить функции.

Продолжайте нажимать на кнопку Next, пока не достигнете экрана ролевой службы.

Включите опцию под названием Сертификационный орган и нажмите на кнопку Next.

На экране подтверждения нажмите на кнопку «Установка».

Подождите, когда завершится установка Сертификационного органа.

Откройте приложение «Менеджер сервера».

Нажмите на меню желтого флага и выберите опцию: Нанастройка Active Directory Certificate Services

На экране учетных данных нажмите на кнопку Next.

Выберите опцию Сертификационного органа и нажмите на кнопку «Следующая».

Выберите опцию Enterprise CA и нажмите на кнопку «Следующая».

Выберите Новый вариант частного ключа и нажмите на кнопку «Следующая».

Храните конфигурацию криптографии по умолчанию и нажмите на кнопку Next.

Установите общее имя для органа по сертификации и нажмите на кнопку Next.

В нашем примере мы устанавливаем общее название: TECH-CA

Установите срок действия органа сертификации Windows.

Сохраняйте местоположение базы данных службы сертификации Windows по умолчанию.

Проверьте резюме и нажмите на кнопку Настройка.

Подождите, пока закончится установка органа по сертификации серверов Windows.

После завершения установки сертификационного органа, перезагрузите компьютер.

Вы закончили установку органа по сертификации Windows.

Учебник — Тестирование LDAP над SSL связи снова

Мы должны проверить, если ваш контроллер домена предлагает УСЛУГу LDAP по SSL в порту 636.

После завершения установки сертификационного органа подождите 5 минут и перезапустите контроллер домена.

Во время загрузки контроллер домена автоматически запрашивает сертификат сервера у местного органа по сертификации.

После получения сертификата сервера контроллер домена начнет предлагать услугу LDAP по SSL в порту 636.

На контроллере домена получите доступ к меню «Пуск» и ищите приложение LDP.

Получите доступ к меню Connection и выберите опцию Connect.

Попробуйте подключиться к localhost с помощью порта TCP 636.

Выберите флажок SSL и нажмите на кнопку Ok.

Попробуйте подключиться к localhost с помощью порта TCP 636.

Выберите флажок SSL и нажмите на кнопку Ok.

На этот раз вы должны иметь возможность подключиться к службе LDAP в локальном порту 636.

Если вы не в состоянии подключиться к порту 636, перезагрузите компьютер снова и подождите еще 5 минут.

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

VirtualCoin CISSP, PMP, CCNP, MCSE, LPIC22020-12-26T21:35:33-03:00

Related Posts

Welcome back to our two-part series on how to enable secure LDAP (LDAPS) communications between client/server applications on Windows Server 2008/2012 domain controllers. In part one, I went over what you should know about LDAPS, your options, and prerequisites. After we understood the concepts of why, where and when we should be looking to use LDAPS, let’s move on to the actual configuration.

Enabling Secure LDAP: Configuring LDAPS

1. Create the right certificate template to issue
First, we need to make sure that your CA is allowed to issue the correct types of certificates. Remember, these must contain the Server Authentication OID 1.3.6.1.5.5.7.3.1.
I’ve described the steps you need to take in order to create such a template in my Creating a Digital Certificate Template for the purpose of Server Authentication in Windows Server 2008/R2/2012 article.
2. Request a certificate for server authentication
To request a certificate from your LDAPS server, do the following on each DC that requires LDAPS connections:

• In Start, type MMC, and then press Enter. If User Account Control prompts it, go ahead and ensure it displays the action you want. After that, select Yes.
• In the MMC console that opens, click File and then click Add/Remove Snap-in.

• Under Available Snap-ins, in Add or Remove Snap-ins, go ahead and select Certificates, and then click Add.

• In the Certificates snap-in, select Computer account and then click Next.

Note: If you plan to have more than one digital certificate for that DC, and if you are using Windows Server 2008/R2/2012, please read this following article BEFORE you proceed: The issue with Active Directory Domain Services (NTDSPersonal) certificate store
If you only plan to have one digital certificate on that DC, please proceed to the next step.

• In Select Computer, select Local. Once you have the correct computer selected, click OK and then click Finish.

• In Add or Remove Snap-ins, select OK.

• In the console tree, expand Certificates (<computer>), right-click Certificates, click All Tasks, and then click Request New Certificate. Note: You cannot do this if you’re connected to a remote DC.

In Certificate Enrollment, click Next.

In the Select Certificate Enrollment Policy, choose Active Directory Enrollment Policy (default) and click Next.

• Select a certificate that allows for server authentication. You may want to use a custom certificate as described in Publishing a Certificate that Supports Server Authentication. Now go ahead and click Enroll.

• The process may take a few seconds to complete. Click Finish in the Certificate Enrollment dialog box. Now you have a digital certificate for the first DC!

• To check your shiny new certificate, in the results pane double-click the certificate that you received to open Certificate properties.

Click the Details tab. In the Field column, go ahead and select Enhanced Key Usage. You’ll want to confirm that the Server Authentication (1.3.6.1.5.5.7.3.1) is listed.

• Repeat this on all the DCs on which you need to enable LDAPS.

Test the LDAP over a TLS Connection

To test if LDAP over TLS works properly, use the ldp.exe tool.
Note: If ldp.exe is not available on your system, you will need to install the Active Directory Directory Services (AD-DS) management tools from the Windows Remote Server Administration Kit (RSAT):
Download Remote Server Administration Tools for Windows 7 with SP1Download Remote Server Administration Tools for Windows 8

• Open a command prompt and type ldp. Click Enter. The LDP application window appears.
• Select Connection, then Connect. The Connect dialog box appears.
• In the Server text box, type the name of your AD server. For this example, type the fully qualified domain name (FQDN) of the DC, just as it appears in the Subject Alternative Name (SAN) of the Digital Certificate.
• In the Port text box, type 636.
• Check the box for SSL.

• Click OK. Now, without the above procedure you will not be able to connect.

After the procedure, note that “Host supports SSL, SSL cipher strength = 128 bits”.

Note: If you try to connect to the right DC but do not use the same FQDN as was listed inside the issued certificate (for example, using the IP address instead), you will not be able to connect using LDAPS.

• Select the Connection menu, click Bind, and then click OK.

The command output should display the user name and domain name that you used for binding, if LDAPS is configured properly. You can start browsing through the AD tree.

If you use the command: netstat -no | find “:636”, you will find the connection to the DC.

Enjoy.

Microsoft active directory servers will default to offer LDAP connections over unencrypted connections (boo!).

The steps below will create a new self signed certificate appropriate for use with and thus enabling LDAPS for an AD server. Of course the «self-signed» portion of this guide can be swapped out with a real vendor purchased certificate if required.

Steps have been tested successfully with Windows Server 2012R2, but should work with Windows Server 2008 without modification. Requires a working OpenSSL install (ideally Linux/OSX) and (obviously) a Windows Active Directory server.

• Create root certificate
• Import root certificate into trusted store of domain controller
• Create client certificate
• Accept and import certificate
• Reload active directory SSL certificate
• Test LDAPS using ldp.exe utility
• Reference

Create root certificate

Using OpenSSL, create new private key and root certificate. Answer country/state/org questions as suitable:

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

Hold onto the resulting ca.key and ca.crt.

Import root certificate into trusted store of domain controller

• From the active directory server, open Manage computer certificates.
• Add the generated ca.crt to the certificate path Trusted Root Certification AuthoritiesCertificates.
• Done.

Create client certificate

We will now create a client certificate to be used for LDAPS, signed against our generated root certificate.

From the active directory server:

• Create a new request.inf definition with the following contents — replacing ACTIVE_DIRECTORY_FQDN with the qualified domain name of your active directory server:

   [Version]
   Signature="$Windows NT$"
  
   [NewRequest]
   Subject = "CN=ACTIVE_DIRECTORY_FQDN"
   KeySpec = 1
   KeyLength = 2048
   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
  

• Run the following to create a client certificate request of client.csr (note: it’s critical this is run from the active directory server itself to ensure correct private key -> certificate association):

   C:> certreq -new request.inf client.csr

Back to our OpenSSL system:

• Create v3ext.txt containing the following:

   keyUsage=digitalSignature,keyEncipherment
   extendedKeyUsage=serverAuth
   subjectKeyIdentifier=hash
  

• Create a certificate client.crt from certificate request client.csr and root certificate (with private key):

   $ openssl x509 
     -req -days 3650 
     -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt 
     -set_serial 01 -out client.crt

• Verify generated certificate:

   $ openssl x509 -in client.crt -text

• Ensure the following X509v3 extensions are all present:

  • X509v3 Key Usage: Digital Signature, Key Encipherment
  • X509v3 Extended Key Usage: TLS Web Server Authentication
  • X509v3 Subject Key Identifier

Accept and import certificate

• From the active directory server with client.crt present, run the following:

   C:> certreq -accept client.crt

• Open Manage computer certificates, the new certificate should now be present under PersonalCertificates. Ensure that:

  • Certificate has a private key association.
  • The «Intended Purposes» is defined as «Server Authentication».
  • Certificate name is the FQDN of the active directory server.

Reload active directory SSL certificate

Alternatively you can just reboot the server, but this method will instruct the active directory server to simply reload a suitable SSL certificate and if found, enable LDAPS:

• Create ldap-renewservercert.txt containing the following:

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

• Run the following command:

   C:> ldifde -i -f ldap-renewservercert.txt

Test LDAPS using ldp.exe utility

• From another domain controller, firstly install our generated root certificate ca.crt to the certificate path Trusted Root Certification AuthoritiesCertificates.

• Open utility:

• From Connection, select Connect.

• Enter name of target domain controller.

• Enter 636 as port number (this is the LDAPS port).

• Click OK to confirm the connection works.

• You’re all done!

Reference

• Enable LDAP over SSL with a third-party certification authority: https://support.microsoft.com/en-us/kb/321051
• LDAP renewServerCertificate: https://msdn.microsoft.com/en-us/library/cc223311.aspx
• How to Enable LDAPS in Active Directory (similar outcome to above): http://www.javaxt.com/tutorials/windows/how_to_enable_ldaps_in_active_directory
• DigiCert LDAPS certificate install guide: https://www.digicert.com/ssl-certificate-installation-microsoft-active-directory-ldap-2012.htm

Данная глава руководства администратора рассказывает о
возможности импорта объектов ARTA Synergy из
сторонних каталогов посредством
Active Directory. В ней детально описано как
настроить и эксплуатировать LDAP а рамках
ARTA Synergy.

Для работы с LDAP-каталогами возможно
использовать любой клиент с поддержкой
LDAP-протокола. Одним их таких клиентов
является JXplorer.

JXplorer — кроссплатформенный
LDAP браузер и редактор с поддержкой
безопасности (в том числе SSL,
SASL и GSSAPI), перевода
на многие языки, онлайн-помощью, коммерческой поддержкой,
пользовательскими формами и многими другими возможностями.

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

Рассмотрим его функциональность на примере поиска пользователя в
одном из каталогов.

Для конфигурирования синхронизации используется файл
/opt/synergy/jboss/standalone/configuration/arta/ldap-sync.xml.

ARTA Synergy поддерживает одновременную
синхронизацию с несколькими LDAP каталогами.
Вся конфигурация хранится в одном файле и разделена на секции
(item). Секции же должны иметь уникальный
номер (ID). По умолчанию файл содержит две
секции — первая для OpenLDAP, вторая для
Active Directory. Данные секции указаны для
примера и отключены.

Обозначения тегов:

Конфигурационный файл
ldap-sync.xml с полями
<code> и
<application>

?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration xmlns="http://www.arta.kz/xml/ns/as/ldap-sync"
  <!-- ... -->
  <!-- синхронизация с OpenLDAP -->
  <item>
    <!-- ... -->
    <group>
      <!-- ... -->
      <!-- поле ldap, из которого будет записан код группы -->
      <code>group_code</code>
      <!-- код приложения, куда будет записана группа -->
      <application>app1</application>
    </group>
  </item>
  <!-- ... -->
<configuration>

* - если параметр пуст или отсутствует, в код группы записывается `ldap_$sha1($DN)`, 

т. е. префикс ldap и sha1-хэш от
Distiguished Name объекта. Можно записать в
<code> название атрибута LDAP, из
которого будет взят код группы. При импорте для кода проводится
валидация на уникальность и соответствие правилам кода. Если
валидация не прошла, невалидная группа пропускается, в лог
записывается ошибка, а импорт продолжается.

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

будет сформирован по следующим правилам:

Файл конфигурации представлен в одной их следующих версий:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration
        xmlns="http://www.arta.kz/xml/ns/as/ldap-sync"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.arta.kz/xml/ns/as/ldap-sync ldap-sync.xsd">
    <!-- синхронизация с OpenLDAP -->
    <item>
       <!-- id синхронизации -->
       <id>1</id>
       <!-- домен -->
       <domain>test.ldap.com</domain>
       <!-- синхронизация -->  
       <sync>
            <!-- LDAP хост -->
            <host>10.20.30.1</host>
            <!-- учетная запись для подключения к каталогу LDAP -->
            <user-dn>cn=syncuser,dc=test,dc=ldap,dc=com</user-dn>
            <!-- пароль -->
            <password>password</password>
            <!-- активно, неактивно -->
            <active>false</active>
            <!-- интервал синхронизации в мс -->
            <interval>1800000</interval>
            <!-- расписание синхронизации; параметр указан, поэтому интервал синхронизации игнорируется -->
            <schedules>19:00,00:00</schedules>
            <!-- следовать ссылкам -->
            <referral>ignore</referral>
            <!-- код группы пользователей, в которую будут включены все импортированные пользователи -->
            <defaultGroup>client_access</defaultGroup>
            <!-- предоставлять ли импортированным пользователям доступ в систему, пока позволяет лицензия --> 
            <!-- после превышения лимита пользователи будут импортированы, но у них будет заблокирован доступ в систему --> 
            <defaultAccess>true</defaultAccess>
        </sync>
        <access>
            <!-- группа доступа -->
            <allow>cn=aiusers,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</allow>
            <!-- группа админов -->
            <admin>cn=aiadmin,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</admin>
        </access>
        <!-- пользователи -->
        <account>
            <!-- поле id пользователя, если пусто - будет использоваться md5 от DN (как раньше было), иначе md5 от поля -->
            <id></id>
            <!-- поле логин -->
            <login>cn</login>
            <!-- поле имя -->
            <firstname>firstName</firstname>
            <!-- поле отчество -->
            <middlename>middleName</middlename>
            <!-- поле фамилия -->
            <lastname>sn</lastname>
            <!-- поле почта -->
            <email>mail</email>
            <!-- базовый узел -->
            <base>dc=test,dc=ldap,dc=com</base>
            <!-- фильтр -->
            <filter>(objectClass=inetOrgPerson)</filter>
        </account>
        <!-- группы -->
        <group>
         <!-- поле id группы, если пусто - будет использоваться hashCode от DN (как раньше было), иначе hashCode от поля -->
            <id></id>
            <!-- при импорте игнорировать группы -->
            <importGroups>false</importGroups>
            <!-- поле имя -->
            <name>cn</name>
            <!-- поле члены -->
            <member>member</member>
            <!-- базовый узел -->
            <base>dc=test,dc=ldap,dc=com</base>
            <!-- фильтр -->
            <filter>(objectClass=groupOfNames)</filter>
        </group>
    </item>

    <!-- синхронизация с Active Directory -->
    <item>
        <id>2</id>
        <domain>msad.com</domain>
        <sync>
            <host>10.20.30.2</host>
            <user-dn>Administrator@msad.com</user-dn>
            <password>secret</password>
            <active>false</active>
            <interval>1800000</interval>
            <referral>follow</referral>
        </sync>
        <access>
        <!-- userAccountControl указывает на поле "Активен" в AD, вместо него можно использовать просто группу -->
            <allow>userAccountControl</allow>
            <admin>CN=aiadmin,CN=Users,dc=msad,dc=com</admin>
        </access>
        <account>
            <id>objectGUID</id>
            <login>sAMAccountName</login>
            <firstname>givenName</firstname>
            <middlename>initials</middlename>
            <lastname>sn</lastname>
            <email>mail</email>
            <base>dc=msad,dc=com</base>
            <filter>(objectClass=person)</filter>
        </account>
        <group>
            <id>objectGUID</id>
            <name>cn</name>
            <member>member</member>
            <base>dc=msad,dc=com</base>
            <filter>(objectClass=group)</filter>
        </group>
    </item>
    </configuration>

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration
        xmlns="http://www.arta.kz/xml/ns/as/ldap-sync"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        version= "2"
        xsi:schemaLocation="http://www.arta.kz/xml/ns/as/ldap-sync ldap-sync_2.xsd">
    <!-- Наборы синхронизации, таких может быть несколько -->
    <item>
        <!-- id синхронизации -->
        <id>1</id>
        <!-- домен -->
        <domain>test.ldap.com</domain>
        <!-- синхронизация -->  
        <sync>
            <!-- LDAP хост -->
            <host>10.20.30.1</host>
            <!-- учетная запись для подключения к каталогу LDAP -->
            <user-dn>cn=syncuser,dc=test,dc=ldap,dc=com</user-dn>
            <!-- пароль -->
            <password>password</password>
            <!-- активно, неактивно -->
            <active>false</active>
            <!-- интервал синхронизации в мс -->
            <interval>1800000</interval>
            <!-- следовать ссылкам -->
            <referral>ignore</referral>
        </sync>
        <!-- доступ -->
        <access>
            <!-- группа доступа -->
            <!-- значение userAccountControl в этом поле указывает на поле "Активен" в AD, вместо него можно      
            использовать просто группу
            -->                                               
            <allow>cn=aiusers,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</allow>
            <!-- группа админов -->
            <admin>cn=aiadmin,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</admin>
        </access>
        <!-- пользователи -->
            <user>
            <!-- базовый узел поиска в LDAP -->
            <base>dc=test,dc=ldap,dc=com</base>
            <!-- фильтр -->
            <filter>(objectClass=inetOrgPerson)</filter>
            <!-- По какому полю сравнивать пользователей -->
            <identity>
                <!-- Откуда из Synergy брать поле для сравнения, из учётной записи -->
                <source type="account"/>
                <!-- либо из произвольной карточки
                <source type="personalrecord" id="id личной карточки"/>
                -->
                <!-- Поля для сравнения. Блок id может быть только один в этом блоке. -->
                <id>
                    <!-- Идентификатор поля Synergy. Для типа источника account возможные значения: id, login, email.
                    Для типа источника personalrecord — идентификатор поля формы карточки пользователя.
                    -->
                        <synergy>id</synergy>
                        <!-- Поле id пользователя из LDAP, если пусто - будет использоваться md5 от DN объекта. Eсли указанное поле отсутствует в импортируемом объекте, либо оно является пустым, то импорт этого объекта не производится, о чём делается запись в лог -->
                        <ldap></ldap>
                    </id>
                </identity>
                <!-- Сопоставление полей учётной записи -->
                <account>   
                    <!-- поле логин -->
                    <login>cn</login>
                    <!-- поле имя -->
                    <firstname>firstName</firstname>
                    <!-- поле отчество -->
                    <middlename>middleName</middlename>
                    <!-- поле фамилия -->
                    <lastname>sn</lastname>
                    <!-- поле почта -->
                    <email>mail</email>
                </account>
                <!-- Сопоставление полей карточки пользователя. Блоков personalrecord может быть несколько
                -->
                <personalrecord>
                    <!-- Идентификатор карточки пользователя. Обязательно должен быть непустым -->
                    <id>какой-то id</id>
                    <!-- Блок field указывает на связь поля из LDAP с полем карточки пользователя. Таких блоков может быть несколько -->
                    <field>
                        <ldap>IIN</ldap>
                        <synergy>form-iin</synergy>
                    </field>
                </personalrecord>
            </user>
                <!-- группы -->
                <group>
                    <!-- базовый узел -->
                    <base>dc=test,dc=ldap,dc=com</base>
                    <!-- фильтр -->
                    <filter>(objectClass=groupOfNames)</filter>
                    <!-- поле id группы, если пусто - будет использоваться hashCode от DN (как раньше было), иначе hashCode от поля -->
                    <id></id>
                    <!-- поле имя -->
                    <name>cn</name>
                    <!-- поле члены -->
                    <member>member</member>
                 </group>
            </item>
        </configuration>

Данная глава содержит инструкцию по настройке синхронизации и
разделена на два подраздела:

Для настройки синхронизации необходимо иметь права
Администратора AD. Перед началом настройки
настоятельно рекомендуется сделать резервную копию базы
mySQL, чтобы в случае возникновения ошибок
иметь возможность восстановления базы до текущего состояния.