Служба каталогов — это система программного обеспечения, которая хранит, организует и предоставляет доступ к информации в каталоге операционной системы компьютера. В разработке программного обеспечения каталог представляет собой карту между именами и значениями. Это позволяет искать именованные значения, аналогично словарю. Чаще всего используется для представления персонала, материальных или сетевых ресурсов.
Коротко говоря: AD — это база данных служб каталогов, а LDAP — один из протоколов, которые вы можете использовать для общения с ней. LDAP — это протокол, а Active Directory — это сервер.
Что такое Active Directory?
Active Directory — это реализация служб каталогов, которая предоставляет все виды функций, таких как аутентификация, управление группами и пользователями, администрирование политик и многое другое. Active Directory служит единым хранилищем данных для быстрого доступа к данным для всех пользователей и контролирует доступ для пользователей на основе политики безопасности каталога.
Active Directory (AD) поддерживает как Kerberos, так и LDAP — Microsoft AD на сегодняшний день является наиболее распространенной системой служб каталогов, используемой сегодня. AD обеспечивает Single-SignOn (SSO) и хорошо работает в офисе и через VPN. AD и Kerberos не являются кроссплатформенными, что является одной из причин, по которой компании внедряют программное обеспечение для управления доступом для управления входами с разных устройств и платформ в одном месте. AD поддерживает LDAP, что означает, что он все еще может быть частью вашей общей схемы управления доступом.
Active Directory — это только один пример службы каталогов, которая поддерживает LDAP. Также есть и другие варианты: служба каталогов Red Hat, OpenLDAP, сервер каталогов Apache и другие.
А еще Active Directory можено интегрировать с Asterisk
Что такое LDAP?
LDAP (Lightweight Directory Access Protocol) — это открытый и кроссплатформенный протокол, используемый для аутентификации служб каталогов.
LDAP позволяет приложениям взаимодействовать с другими серверами служб каталогов. Это важно, потому что службы каталогов хранят и передают важную конфиденциальную информацию, связанную с пользователями, паролями и учетными записями компьютеров.
Как Active Directory и LDAP работают вместе?
Active Directory поддерживает LDAP, что означает, что вы можете объединить их, чтобы улучшить управление доступом. Фактически, многие различные службы каталогов и решения для управления доступом могут понимать LDAP, что делает его широко используемым в средах без Active Directory.
Что такое аутентификация LDAP?
В LDAP v3 есть два варианта аутентификации LDAP — простой и SASL (Simple Authentication and Security Layer).
Простая аутентификация допускает три возможных механизма аутентификации:
- Анонимная аутентификация: предоставляет клиенту анонимный статус для LDAP.
- Аутентификация без аутентификации: только для целей регистрации, не должна предоставлять доступ клиенту.
- Аутентификация по имени или паролю: Предоставляет доступ к серверу на основе предоставленных учетных данных — простая аутентификация пользователя или пароля не является безопасной и не подходит для аутентификации без защиты конфиденциальности.
Аутентификация SASL связывает сервер LDAP с другим механизмом аутентификации, таким как Kerberos. Сервер LDAP использует протокол LDAP для отправки сообщения LDAP другой службе авторизации. Это инициирует серию ответных сообщений запроса, которые приводят либо к успешной аутентификации, либо к неудачной аутентификации.
Важно отметить, что по умолчанию LDAP передает все эти сообщения в виде открытого текста, поэтому любой человек, имеющий сетевой анализатор, может читать пакеты. Вам нужно добавить шифрование TLS или подобное, чтобы сохранить ваши имена пользователей и пароли в безопасности.
Что такое запрос LDAP?
Запрос LDAP — это команда, которая запрашивает у службы каталогов некоторую информацию. Например, если вы хотите увидеть, в какие группы входит конкретный пользователь, отправьте запрос, который выглядит следующим образом:
(&(objectClass=user)(sAMAccountName=yourUserName) (memberof=CN=YourGroup,OU=Users,DC=YourDomain,DC=com))
Синтаксис не очень простой, но в официальном вики можно найти много примеров.
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:\LocalMachine\Root'
VERBOSE: Performing the operation "Import certificate" on target "Item: C:\ca\ca.crt Destination: Root".
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
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:\LocalMachine\My"
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\My
Thumbprint Subject
---------- -------
4721D27E9FE34AAA672D20D68C0EC01FD9F7A82C CN=altuninvv.local
Теперь вы должны перегрузить контролер домена, чтобы все настройки вступили в силу.
Обратите внимание, чтобы подключиться к серверу вы должны указать его полное доменное имя, в нашем случае:
addc1.altuninvv.local
Если ПК входит в состав домена altuninvv.local, вы можете использовать для подключение его имя:
altuninvv.local
Тогда контролер домена для подключения будет выбран автоматически из списка доступных, возможно, это будет работать только, при наличии Службы сертификатов на одном из серверов в AD!
Так как мой ПК не входит в домен altuninvv.local и не использует его DNS-сервера, я прописал в файле
C:\Windows\System32\drivers\etc\hosts
строку:
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: 'ALTUNINVV\ldap-bind'.
Это означает, что подключение прошло успешно.
Далее выберем пункт меню Вид – Дерево
И в окне выберем —
DC=altuninvv,DC=local
Нажмем Ок
Откроется дерево с разделами домена,
Таким образом вы можете просматривать каталог AD через LDAP по SSL.
Заключение
Сегодня мы рассмотрели подключение к контролеру домена AD с использованием протокола LDAP по SSL.
Мы создали свой локальный центр сертификации CA с помощью OpenSSL.
Был выпущен сертификат и установлен на контролере домена.
С помощью утилиты ldp.exe было осуществлено подключение к контролеру домена по SSL.
Introduction
Active Directory (AD) is a directory service that stores information about objects on the network in a logical and hierarchical manner. Administrators control and manage access to network resources based on the permissions assigned to the AD user role. Lightweight Directory Access Protocol (LDAP) is a simplified version of the Directory Access Protocol (DAP). LDAP’s primary function is to allow users to find data about people, organizations, and other entities by storing data in the directory and authenticating users to access the directory. It also facilitates the sharing of information from directory services to other applications and services. LDAP authentication helps to verify usernames and passwords before granting access to the data stored in a directory. Therefore, LDAP makes it easier to connect, search, and modify directories by operating as an application protocol that performs authentication.
Why integrate AD with LDAP?
Both Active Directory and Lightweight Directory Access Protocol are essential for maintaining the security of your IT infrastructure. AD is a key component of your IT security layer, and LDAP is a key component of how AD operates. Active Directory is intended to serve as a directory service for user management and to assist you in managing and controlling all of the devices on your network, including computers, services, printers, and mobile devices, as well as the users who interact with them. Each user or group of users can also be granted privileges to Active Directory objects or information. On the other hand, the Lightweight Directory Access Protocol (LDAP) is a directory service authentication protocol that works across platforms. It provides the communication language through which application directory services communicate information about users, passwords, and computer accounts with other network entities.
Access to information in the directory can have a significant impact on system security, and directory services are practically a phone book for your company’s information and devices, which is why AD authentication is so essential. Users can utilize LDAP to gain access to the information they require in AD to do their duties efficiently. Furthermore, since Active Directory is critical to your IT environment, it might be a target for cybercriminals looking to attack your security systems. When a single high-level or high-access account is hacked, sensitive information such as files and information, as well as passwords for other accounts, are exposed. As a result, the integration of directory servers and LDAP is critical for the proper and secure operation of the organization’s IT systems.
Prerequisites for integrating AD with LDAP:
- IP address details or the hostname of the LDAP server.
- Administrator account and credentials of LDAP server.
- Organization’s Active Directory information.
- System requirement of a minimum of 2 GB Disk Space and 1 GB Memory.
- The base distinguished name that needs to be added in the LDAP fields.
How does Active Directory work with LDAP?
There are two methods of LDAP authentication with respect to accessing the Active Directory:
- Simple Authentication: In this authentication method, a bind request is created using the user credentials. The same request is forwarded to the server for authentication.
- SASL (Simple Authentication and Security Layer) Authentication: This framework uses a third-party authentication service as a first step to bind to the LDAP server. Based on that, the authentication request is approved or rejected. This method can provide increased security. Since there are multiple authentication methods deployed in this method and each acts as a separate process, the directory remains highly secure.
Steps to integrate LDAP with AD:
Before implementing LDAP, you should determine what authentication methods you require, how users will search the systems for information/data, and where your security and information demands are. Follow the below steps to integrate LDAP with Active Directory:
- Login to Active Directory using an administrator account.
- Scroll down to the LDAP Support section and choose the Server Overview tab.
- A popup will now display some fields that need information pertaining to the LDAP account.
- Fill in the details of Server and Port in the fields provided beside them. For Server, use the domain name or the IP address, and for Port, use code 389 for unencrypted LDAP connection and 636 for encrypted LDAP connection.
- In the Base DN field, enter the complete base details of the AD including the suffix.
- Set the Search Scope as per the required level of search. When set to 0, the search gets limited to the base object. When set to 1, the search level gets expanded till the child objects. Setting it as 2 will search the whole subtree including the base object and all its child objects. This is the default search scope.
- For the Username Attribute, fill in the object name that needs to be searched in the directory.
- Enter the Search Filter with the details of the required string. This string is used for the LDAP search to locate and filter the object in the AD. For example, use (objectclass=user) to filter all entities that have the object class as User.
- Click on Verify to ensure that all the applied settings are correct.
- The details of the administrator account must be entered.
- Select Save to apply the changes.
- To enable LDAP authentication for users, go to Admin and select User Management.
- All the available users will be listed. Select the user for whom LDAP needs to be enabled.
- Click on Advanced and check the LDAP Authentication option.
- Click on Save to apply the changes.
Best Practices for LDAP Integration:
By adhering to best practices for managing your AD user access privileges, you can ensure that your Active Directory is properly configured with LDAP authentication.
- Ensure that your AD and LDAP servers are properly set up, in order to reduce the possibility of an AD problem affecting your end users.
- Configure your AD groups based on their role or the level of access they should have, and keep these groups up to date to keep your system secure by restricting unauthorized access.
- Set up each user or user group with the least amount of access necessary to complete their work or execute their duty, because the more access any user or user group has, the more likely the access will be exploited, i.e. the less access you offer each user and group, the safer your systems will be.
- Review your Active Directory and LDAP authentication configuration on a regular basis to ensure there are no modifications that could cause a security threat to the network.
Conclusion:
LDAP is a vital component of Active Directory’s operation since it communicates all messages between the AD and the rest of your IT environment. Therefore, monitor and manage your AD to ensure that you are using it in a safe and efficient manner, which is critical for the security and day-to-day operations of your IT systems.
Active Directory (AD) – проприетарная реализация от компании Microsoft службы каталогов – совокупности программных сервисов и баз данных для иерархического представления информационных ресурсов в сети (компьютеров, принтеров, сетевых дисков и пр.) и настройки доступа к ним.
LDAP (Lightweight Directory Access Protocol) – облегчённый протокол доступа к каталогам, открытый стандартизированный протокол, применяемый для работы с различным реализациям служб каталогов, в том числе и Active Directory.
Основной задачей Active Directory является хранение информации обо всех объектах в сети и предоставление её внешним системам. В свою очередь, LDAP позволяет пользователям получить доступ к ресурсам в зависимости от прав, настроенных администратором службы каталогов.
Для работы протокола LDAP по-умолчанию используется TCP-порт 389.
Существует защищённая версия протокола LDAP – LDAPS (LDAP over SSL), которая использует безопасное TLS/SSL-соединение для передачи данных. Протокол LDAPS по умолчанию использует TCP-порт 636.
Далее описаны основы Active Directory, более подробную информацию смотрите в официальной документации на сайте Microsoft.
Что такое леса, деревья и домены в Active Directory?
Основными структурными элементами Active Directory являются:
- домен – группа объектов (пользователей, компьютеров и пр.), основная административная единица AD. Для каждого домена настраиваются правила доступа к нему и политики взаимодействия с другими доменами (отношения доверия);
- структурное подразделение – необязательный наименьший возможный контейнер, в который при желании можно сгруппировать объекты домена (другие контейнеры, аккаунты пользователей и компьютеров). Могут использоваться, чтобы определить групповые политики и административный доступ для небольшой совокупности ресурсов в пределах одного домена;
- дерево доменов – коллекция доменов, сгруппированных в иерархическую структуру и имеющих связанное пространство имён;
- лес – контейнер высшего уровня, включающий в себя все домены каждого конкретного экземпляра AD.
Таким образом, в иерархии Active Directory должен быть как минимум один лес, одно дерево и один домен.
Для каждого домена настраивается минимум один сервер с ролью контроллер домена, на котором работают сервисы AD. Он хранит информацию об объектах своего домена, и реализует операции поиска в каталоге, входа пользователей и проверки подлинности.
Контроллер домена, который содержит данные о каждом объекте в лесу AD, называется глобальный каталог. Он хранит полный набор атрибутов объектов своего домена и частичную реплику основных атрибутов (список которых можно настроить) объектов всех остальных доменов. Это позволяет быстро находить информацию независимо от её физического расположения на различных доменах.
В лесу обязательно должен быть минимум один глобальный каталог. По умолчанию им назначается первый контроллер домена, на который устанавливается роль доменных служб Active Directory.
Для связи с глобальным каталогом используется TCP-порт 3268 или 3269 при работе по протоколу LDAP и LDAPS соответственно.
Как работает Active Directory?
Сервисы Active Directory являются частью операционной системы Microsoft Windows Server и устанавливаются в качестве одной или нескольких её ролей.
Основной из них является роль доменные службы Active Directory (Active Directory Domain Services, AD DS) – она используется для организации в защищённую логическую структуру всех объектов сети. Полученная иерархическая схема является независимой от физического расположения объектов и топологии сети. Это значительно упрощает администрирование и настройку доступа, например, изменение физического расположения компьютера не повлияет на его роль в структуре AD.
Основными операциями при работе с Active Directory являются аутентификация пользователей, а также поиск, модификация и сравнение объектов. Эти функции реализуются с помощью протокола LDAP
Кроме AD DS, могут устанавливаться дополнительные роли, расширяющие возможности использования AD: шифрование чувствительных данных, единый вход без повторной аутентификации пользователей на различные веб-сервисы в сети, и пр.
Active Directory содержит:
- хранилище данных – часть службы каталогов, которая управляет хранением и предоставлением информации на каждом контроллере домена. Данные хранятся в структурированной базе данных (БД), которая иначе называется каталог и содержит совокупность всех объектов AD. Каждый из них относится к определённому классу (пользователи, компьютеры, домены и т.д.). В свою очередь, все объекты каждого класса имеют одинаковый набор атрибутов;
- схему – совокупность определений классов и атрибутов (именованных параметров) объектов. Она стандартизирует как данные хранятся в хранилище и благодаря этому позволяет получать информацию (как сказано выше, используется для этого протокол LDAP);
- леса, деревья, домены и организационные подразделения – ключевые элементы логической структуры AD, которые были подробно рассмотрены ранее.
Для конвертации зарегистрированных в структуре Active Directory имён сетевых ресурсов (компьютеров, принтеров и пр.) в IP-адреса используется интеграция с DNS (Domain Name System, системой доменных имён). Это позволяет, например, пользователям получить доступ к компьютерам, а компьютерам – к контроллерам доменов.
Каждый объект в AD представляет собой LDAP-запись, состоящую из набора атрибутов и их значений, которые в совокупности полностью его описывают. Например, объект класса сотрудник содержит атрибут email, который выглядит следующим образом: mail: user@example.com
.
В итоге вся запись для сотрудника, принадлежащего классу employee
, может иметь такой вид:
dn: cn=Ivan Petrov,ou=employee,dc=example,dc=com objectclass: employee sn: Petrov cn: Ivan Petrov mail: petrov@example.com ou: people |
Обратим внимание на значение первого атрибута записи: cn=Ivan Petrov,ou=employee,dc=example,dc=com
. Это уникальное имя (Distinguished Name, DN), которое однозначно идентифицирует запись в пределах леса и представляет собой полный путь от корневой записи AD до рассматриваемого объекта. В данном случае запись, содержащая сведения о сотруднике Ivan Petrov
, является дочерней записью организационного подразделения ou=employee
, а у неё в качестве родителя выступает доменное имя example.com
. При этом значения, уникальные в пределах своей родительской записи, называются относительным уникальным именем (Relative Distinguished Name, RDN). Например, cn=Ivan Petrov
– RDN по отношению к ou=employee
. Совокупность всех RDN в виде иерархической цепочки и составляет DN каждой записи. Схематически это можно изобразить таким образом:
Значения атрибутов можно использовать для фильтров поиска объектов AD, а значения DN – чтобы однозначно идентифицировать объект (например, для его модификации).
Преимущества Active Directory/LDAP в ВКС
Участники видеоконференции могут быть «разбросаны» по разным местам (разные города, страны и даже континенты). Число пользователей сервера видеоконференцсвязи может варьироваться от единиц до сотен тысяч. В этом случае Active Directory/LDAP значительно облегчает работу администратора, который занимается обслуживанием каталога корпоративных пользователей.
Интеграция со службами каталогов по протоколу LDAP избавляет администратора от повторного заведения учётных записей в панели управления сервером, что значительно экономит его время. Пользователи, в свою очередь, избавляются от сеанса повторной авторизации. Active Directory/LDAP даёт возможность использовать на ВКС терминале существующий механизм авторизации, без необходимости повторного ввода своего логина и пароля вначале работы (механизм единого входа, SSO). Если протокол LDAP будет использоваться в локальной сети, пользователь сможет подключаться и аутентифицироваться на любом компьютере, который входит в корпоративную сеть.
Интеграция TrueConf Server с Active Directory
TrueConf Server интегрируется с Active Directory и другими LDAP-каталогами для объединения пользователей в централизованный каталог, синхронизации адресных книг, управления контактами и определения прав доступа к корпоративной информации
Скачать TrueConf Server Free
Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) are essential tools in modern computer networks. AD, developed by Microsoft, organises and manages network resources in Windows environments. LDAP, on the other hand, is an open protocol that allows applications to access directory services across various platforms.
When integrated, these two technologies create a powerful system for managing user authentication, authorisation and network resources. This piece explores how AD and LDAP work together, their benefits, common uses and challenges to consider when implementing this integration in your organisation’s network infrastructure.
What is Active Directory and LDAP?
Active Directory (AD) is Microsoft’s proprietary directory service designed for Windows domain networks. It organises network resource data like users, computers, groups and other objects. AD provides authentication, authorisation and centralised management for Windows-based systems.
LDAP, an open, vendor-neutral application protocol, accesses and maintains distributed directory information services across IP networks. It’s a lightweight version of the X.500 Directory Access Protocol.
While Active Directory is specific to Microsoft environments, LDAP is a universal protocol that can be used with various directory services across different platforms. AD uses LDAP as one of its communication protocols, enabling LDAP and Active Directory integration.
This means that non-Windows systems can also interact with AD using LDAP, facilitating integration in mixed environments.
How Active Directory Works
Active Directory is a Microsoft-developed directory service for Windows networks. Its key components include:
- Objects: Individual items in the system, like users, computers, or printers.
- Organisational Units (OUs): Groups of related objects.
- Domains: Large containers holding many OUs and objects.
- Trees: Collections of related domains.
- Forests: The biggest grouping, containing multiple trees.
So, Active Directory Authentication helps network administrators (the people who manage the network) do several important things:
- Keep all user information in one place
- Let users log in once to access many different resources
- Apply security rules across the whole network
- Make it easier to find and manage things on the network
How LDAP Works
LDAP is the language used to talk to directory services like Active Directory. It’s a set of rules that tells computers how to ask for information and how to understand the answers they get back.
The user’s details are sent to the directory server by LDAP verification. The computer checks to see if the account and password are already in use. If it’s right, an entry is given.
As part of this process, you may need to connect to the Directory, look for the user and confirm the password. LDAP authentication can do this in a number of ways, such as through simple bind and SASL techniques.
- A program or user needs some information from Active Directory.
- The program sends a request using LDAP to the Active Directory server.
- The Active Directory server looks up the information.
- The server sends back the answer using LDAP.
This happens very quickly, usually in just a fraction of a second.
Also Read: LDAP vs. Active Directory: What’s the Difference?
Why Connect LDAP to Active Directory?
Connecting LDAP to Active Directory is like building a bridge between two important parts of your company’s computer system. Here’s why it’s useful:
- Better Communication: LDAP helps different computer programs talk to each other. When connected to Active Directory, these programs can easily access information about users, computers and other resources.
- Stronger Security: Active Directory stores important information about who can access what in your company. By using LDAP, you can make sure only the right people can see and use this information.
- Easier Management: With this connection, IT teams can more easily control user accounts, passwords and permissions across different systems.
- Improved Efficiency: Users can log in once and access multiple services, making their work smoother and faster.
- Flexibility: LDAP works with many types of systems, so connecting it to Active Directory helps your company use a wider range of software and services.
- Centralised Control: IT admins can manage everything from one place, which saves time and reduces mistakes.
- Scalability: As your company grows, this setup can easily handle more users and resources without major changes.
By connecting LDAP to Active Directory, companies create a more organised, secure and efficient IT environment.
LDAP Integration With Active Directory
When we talk about LDAP integration with Active Directory, we’re talking about setting up programs to use LDAP to ask questions and check if users are allowed to use the network.
To connect LDAP to Active Directory, we need to do a few things:
- Tell the program where to find the Active Directory server.
- Set up security measures to keep the information safe as it travels over the network.
- Provide the right username and password so the program is allowed to ask questions.
Active Directory LDAP Settings and Components
Configurations
When setting up LDAP authentication with Active Directory, there are several important things to configure:
- Server Address: The address of the AD server on the network, which is usually an IP address or username. This is necessary to connect to the right computer in the network for the first time.
- Port: The exact place on a network where data is sent and received. Port 389 is used for standard LDAP and port 636 is used for secured calls with LDAPS (LDAP over SSL).
- Base DN (Distinguished Name): This is where directory searches in AD begin. It limits the scope of queries, which speeds up the search process.
- Bind DN and Password: These are the credentials that are used to log iDirectory into the directory. They show who the connecting organisation is and what access rights it has.
- Search Filter: A set of rules that lets you limit directory searches to certain types of entries. This makes it possible to ask exact questions and get the right information.
- User Attribute: The field used to identify usernames in AD, often «sAMAccountName» or «userPrincipalName».
Components Involved:
In an LDAP integration with Active Directory, several key components work together:
- Active Directory: Stores user and account information on-premises.
- Users: Access LDAP-dependent applications through browsers.
- Web browsers: Interface for users to interact with applications.
- Virtual network: Allows legacy apps to use LDAP services in Azure.
- Legacy applications: Require LDAP for authentication.
- Azure AD: Syncs on-premises identity info to the cloud.
- Azure AD DS: Provides AD features in Azure.
- Azure AD Connect: Tool for syncing on-premises AD to Azure AD.
These components enable seamless authentication and access management across on-premises and cloud environments. Users can access resources securely, while IT admins manage identities centrally.
How LDAP Authentication Works with Active Directory
Active Directory and Lightweight Directory Access Protocol work together to provide robust authentication and directory services. LDAP acts as a communication protocol that allows applications to interact with AD’s directory information.
When integrating LDAP with AD, the process involves setting up LDAP to authenticate user credentials against Active Directory. This is primarily achieved through the BIND operation, which establishes the authentication state for an LDAP session, enabling the protocol to connect to the AD server.
Two methods are commonly used for LDAP-based authentication in AD:
- Simple authentication: This method typically involves using a username and password to create a BIND request to the LDAP server. It can also support anonymous and unauthenticated requests to enterprise resources.
- Simple Authentication and Security Layer (SASL): This approach leverages other authentication services, such as Kerberos, to connect to the LDAP server. SASL enhances security by decoupling authentication mechanisms from application protocols.
It’s important to note that LDAP authentication messages are transmitted in plain text by default, which can pose security risks. To mitigate this, encryption measures like Transport Layer Security (TLS) should be implemented.
Once the LDAP integration with AD is set up, organisations can use this combination to manage permissions for various resources, with LDAP serving as the messenger for integrating AD with other systems in the IT infrastructure.
When someone tries to log in to a system that uses LDAP authentication with Active Directory, here’s what happens:
- The user types in their credentials (username and password).
- Using LDAP, the system transmits a message to Active Directory enquiring, «Is this username and password Directory?»
- Active Directory checks its records.
- If the username and password match what’s in the records, Active Directory sends back a message saying, «Yes, that’s correct.»
- The system allows the user in and decides their permissions based on Active Directory.
This process helps make sure that only people who are supposed to use the system can get in.
Useful Links:
- How to Configure the Directory to Require LDAP Server Signing for AD DS
Benefits of Using LDAP Integration with Active Directory
Using LDAP with Active Directory has several advantages:
- After logging in once, users can log in once and access many different programs and resources.
- The network administrators can manage all user accounts from one place.
- By using Active Directory’s security features, programs can implement stronger ways to check if users are who they say they are.
- As organisations grow and add more users and resources, Active Directory and LDAP can handle the increase easily.
- Many different programs and systems understand LDAP, so it’s easier to make everything work together.
Common Uses for LDAP Authentication with Active Directory
LDAP authentication with Active Directory is used in many different ways:
- Web Applications: Many websites and web-based tools use LDAP to check user logins against Active Directory.
- Network Devices: Things like routers and switches (which help direct traffic on computer networks) often use LDAP authentication.
- Cloud Services: Some cloud platforms can use LDAP to check user logins against an organisation’s Active Directory.
- Email Systems: Many email servers can be set up to use LDAP authentication with Active Directory.
- VPNs: Virtual Private Networks, which allow secure connections to a network from outside, often use LDAP to check user logins.
Best Practices for LDAP and Active Directory Integration
To make sure LDAP integration with Active Directory works well and stays secure, here are some good practices to follow:
- Use Encryption: To keep private data like usernames and passwords safe, you should always encrypt LDAP traffic.
- Limit Permissions: Create a special account for LDAP to use that only has the permissions it absolutely needs.
- Regular Check-Ups: Check the settings for LDAP and Active Directory on a regular basis to make sure they’re still safe and working right.
- Monitor LDAP Traffic: Pay attention to how LDAP is being used to find any strange behaviour that might be a security risk.
- Use Group Policies: Use the tools in Active Directory to keep an eye on LDAP settings for the whole company.
- Keep Everything Updated: Keep Active Directory servers and apps that use LDAP up to date to fix any security issues.
- Test Before Using: Before trying new LDAP login authentication to use in the real system, you should always test them in a safe place.
Challenges to Consider When You Connect LDAP to Active Directory
While using LDAP authentication with Active Directory is very helpful, there are some challenges to be aware of:
Complexity
Setting up and maintaining LDAP integration can be complicated, especially in large organisations. This complexity stems from the need to configure multiple components correctly, including servers, clients and network settings.
Additionally, troubleshooting issues in such a complex system can be time-consuming and require specialised expertise.
Performance
If not set up correctly, LDAP queries can put a strain on Active Directory servers, making things slow down. Large numbers of simultaneous queries or inefficient search filters can overwhelm server resources, leading to increased response times and potentially impacting other critical business operations that rely on Active Directory.
Security Risks
If not properly secured, LDAP can be vulnerable to attacks from hackers. Unencrypted LDAP traffic can be intercepted, potentially exposing sensitive information. Additionally, misconfigured LDAP settings might allow unauthorised access to directory information, compromising the overall security of the organisation’s network.
Compatibility Issues
Some programs may not work perfectly with all LDAP features or specific Active Directory settings. This can lead to integration challenges when deploying new applications or updating existing ones.
Organisations may need to invest time and resources in testing and potentially modifying applications to ensure smooth operation with their LDAP-AD setup.
Dependency
If many systems rely on Active Directory for authentication, problems with Active Directory could affect lots of different systems.
This creates a single point of failure, where issues with AD can cascade across the organisation, potentially disrupting multiple services and applications simultaneously. It’s crucial to have robust backup and failover mechanisms in place to mitigate this risk.
Conclusion
LDAP integration with Active Directory is crucial for modern networks, offering enhanced security, efficiency and usability. While adoption requires careful assessment of advantages and possible challenges, remaining current on developing technologies and authentication techniques is critical for sustaining resilient and secure systems.
At InstaSafe, we understand the complexities of LDAP integration with Active Directory. By leveraging our advanced solutions, you can ensure that your LDAP-AD integration is not only efficient but also protected against modern cyber threats.
Our Secure Cloud Access solution simplifies this process, providing a seamless and secure way to connect your on-premises Active Directory with cloud applications.
Frequently Asked Questions (FAQs)
- What Port does Active Directory use for LDAP authentication?
Active Directory typically uses port 389 for standard LDAP communication and port 636 for LDAP over SSL/TLS (LDAPS). These ports allow secure authentication and data transfer between LDAP clients and Active Directory servers.
- Can you have LDAP and AD on the same network?
Yes, you can have LDAP and Active Directory on the same network. In fact, Active Directory uses LDAP as one of its core protocols. LDAP serves as a communication method for applications to interact with Active Directory’s directory services.
- What are LDAP queries for Active Directory?
LDAP queries for Active Directory are requests sent to retrieve specific information from the directory. These queries can search for users, groups, computers, or other objects. They use a specific syntax to filter and return desired data from the AD database.
- What permissions are needed to read Active Directory as LDAP?
To read Active Directory as LDAP, users typically need «Read» permissions on the objects they’re accessing. The particular permissions may vary based on the information queried. Generally, a user account with basic read access to the directory is sufficient for most LDAP queries.
- How to use LDAP with Active Directory?
You need to give your program the right server address, port and passwords in order to use LDAP with Active Directory. To find people, groups, or other things, use LDAP queries. Use the right means of identification. Make sure that your connections and searches work by testing them. When you can, always use safe connections (LDAPS).
- Is Active Directory the same as LDAP authentication?
AD and LDAP authentication are related but not the same. LDAP is a protocol that is used to access and manage directory information, including AD, while AD is a directory service provided by Microsoft. LDAP authenticates users in AD.
Key Products
Multi Factor Authentication | Identity And Access Management | ZTNA | Zero Trust Application Access | Secure Enterprise Browser
Key Features
Single Sign On | Endpoint Security | Device Binding | Domain Joining | Always On VPN | Contextual Access | Clientless Remote Access | Device Posture Check
Key Solutions
VPN Alternatives | DevOps Security | Cloud Application Security | Secure Remote Access | VoIP Security