LDAP user authentication explained
LDAP user authentication is the process of validating a username and password combination with a directory server such MS Active Directory, OpenLDAP or OpenDJ. LDAP directories are standard technology for storaging user, group and permission information and serving that to applications in the enterprise.
Authenticating users with an LDAP directory is a two-step process. This article explains the mechanics of it and then how to configure it in LdapAuth.
Step 1 – Resolving the username to a directory entry attribute
User entries in a directory are identified by a distinguished name (DN) which resembles a path-like structure starting at the directory root (the rightmost segment):
In order to authenticate a user with an LDAP directory you first need to obtain their DN as well as their password.
With a login form, people typically enter a simple identifier such as their username or email address. You don’t expect them to memorise the DN of their directory entry. That would be impractical.
To solve this issue a DN resolution comes in. It takes the user’s name or email, then runs a search against the name or email attributes of all user entries to find the matching entry DN. Directories employ highly efficient indexing and caching, so these searches are typically very fast.
The directory attributes to search for are defined in the searchFilter configuration parameter. The default LdapAuth configuration searches the UID and email attributes. The %u placeholder is substituted with the user identifier entered in the login form:
If you want to search for UID only the search filter would look like this:
If you want to search for UID, email and employee number, extend the filter to
Two important things to observe when configuring DN resolution and creating new user entries in the directory:
The attributes – username, email, etc – with which users login must be unique. If two entries are found to have the same identifying attribute, e.g. email, authentication will be promptly denied.
Make sure every user who is expected to login has a defined attribute for the identifying attribute. For example, if users are going to login with their email address, make sure all accounts have a defined email attribute. Else authentication will fail.
The LdapAuth web API does not reveal in the authentication response the cause of the login failure – whether that was a wrong username, a wrong password, or both. To troubleshoot situations where a user is not able to login despite entering a correct username and password, check the service logs.
If a login was rejected due to a bad username, a line like this will appear in the log:
If the username was correctly resolved, but the password was bad:
If we have correctly resolved the user’s directory entry DN, we can proceed to the next step – checking the password.
Step 2 – Validating the user password
Passwords are checked by an LDAP command called bind. A connection is opened to the directory server, then a request is sent to authenticate the connection as a particular user by passing its entry DN and password:
If the credentials are correct, the directory server returns success. Otherwise it returns an LDAP error Invalid credentials (code 49).
Important things to note here:
The password is checked against an attribute in the user’s entry dedicated to serve that purpose. If you’re using a standard directory schema, this attribute is called userPassword . In MS Active Directory the name of this attribute is unicodePwd . Make sure that every user who is expected to login has a defined password attribute. Else authentication will fail.
The password values are often hashed and may be additionally protected, e.g. by making them write-only. Therefore a simple LDAP read and comparison will generally not work here. The bind command is always the preferred method.
Password are typically case sensitive.
Again, remember that log files are your friend. They record details of every login attempt and can be used for quick troubleshooting when authentication is not working as expected. If you need more help with configuring LdapAuth get in touch with us.
LDAP: как этот протокол работает для аутентификации клиентов
Когда у нас есть десятки компьютеров в сети, необходимо правильно организовать данные, а также учетные данные разных пользователей. Для создания иерархической структуры очень важно иметь такую систему, как LDAP, которая позволит нам правильно хранить, управлять и защищать информацию обо всем оборудовании, а также будет отвечать за управление всеми пользователями и ресурсы. Сегодня в этой статье мы собираемся объяснить все о LDAP, а также о том, как установить и настроить его на Linux системы.
Что такое LDAP и для чего он нужен?
LDAP (облегченный протокол доступа к каталогам), также известный как «облегченный протокол доступа к каталогам», представляет собой протокол прикладного уровня TCP/IP, который обеспечивает доступ к упорядоченной и распределенной службе каталогов для поиска любой информации в сети. Прежде чем мы продолжим объяснять, для чего нужен LDAP, нам нужно знать, что такое «каталог». Каталог — это набор объектов с атрибутами, которые организованы логически и иерархически, то есть имеют форму дерева и идеально упорядочены в зависимости от того, что мы хотим, будь то в алфавитном порядке, по пользователям, адресам и т. д.
Как правило, сервер LDAP отвечает за хранение информации для аутентификации, то есть имени пользователя и пароля, для последующего предоставления доступа к другому протоколу или системной службе. Помимо хранения имени пользователя и пароля, он также может хранить другую информацию, такую как контактные данные пользователя, расположение ресурсов локальной сети, цифровые сертификаты самих пользователей и многое другое. LDAP — это протокол доступа, который позволяет нам получать доступ к ресурсам локальной сети без необходимости создавать разных пользователей в операционной системе, а также гораздо более универсален. Например, LDAP позволяет выполнять задачи аутентификации и авторизации для пользователей различного программного обеспечения, такого как Docker, OpenVPN, файловых серверов, таких как те, которые используются QNAP, Synology или ASUSTOR, среди прочего, и многих других применений.
LDAP может использоваться как пользователем, у которого запрашиваются некоторые учетные данные для доступа, так и приложениями, чтобы узнать, есть ли у них доступ к определенной системной информации или нет. Как правило, сервер LDAP располагается в частной сети, то есть в локальных сетях, для аутентификации различных приложений и пользователей, но он также может без проблем работать в общедоступных сетях.
Двумя наиболее популярными службами Active Directory, поддерживаемыми LDAP, являются «Windows Active Directory», также известный как «Windows Active Directory», а также OpenLDAP. Таким образом, протокол LDAP совместим с обеими технологиями, поэтому пользователи могут получить доступ ко всем файлам и приложениям из любого места, им просто нужно пройти аутентификацию, и они получат доступ к своему компьютеру.
В настоящее время версия LDAP — LDAPv3, поэтому, когда мы устанавливаем и используем этот протокол, в подавляющем большинстве случаев мы будем использовать протокол LDAPv3 для аутентификации различных клиентов.
Как работает сервер LDAP
LDAP — это протокол с клиент-серверной архитектурой, поэтому у нас будет несколько клиентов, которые будут подключаться к одному или нескольким серверам LDAP. Как правило, используется один сервер LDAP, к которому подключаются десятки или сотни клиентов для доступа к различным ресурсам локальной сети. На сервере будут храниться все данные, связанные с каталогом, он также будет отвечать за аутентификацию пользователей, проверку того, что одновременно подключен только один пользователь или несколько с разных устройств, и другие задачи, которые мы объясним ниже.
Работа LDAP довольно проста, так как связь похожа на любую другую связь между клиентом и сервером, точно так же, как это происходит в Windows с Active Directory. Ниже вы можете увидеть три наиболее важных этапа коммуникации:
- Клиент подключается к серверу LDAP (процесс называется агентом системы каталогов) через порт TCP/IP 389, чтобы начать сеанс LDAP.
- Устанавливается соединение между клиентом и сервером.
- Обмен данными происходит между сервером и клиентом.
- Прочитать информацию : чтобы прочитать информацию, клиент должен быть аутентифицирован, затем он попытается прочитать и получить информацию из каталога, перед выполнением этого шага сервер проверит, имеет ли этот конкретный пользователь разрешение на чтение информации.
- Изменить информацию : для изменения информации процесс такой же, но сервер проверит, есть ли у нас права на изменение на сервере.
LDAP также позволяет нам обмениваться информацией между несколькими серверами, если мы аутентифицируем себя на сервере, и на нем нет необходимой информации, мы можем сделать этот запрос на другой сервер, который у нас есть в той же локальной сети, чтобы проверить, действительно ли у нас есть эта информация или нет. Это нечто похожее на то, что происходит с DNS серверы, которые запрашивают друг друга, поднимаясь по дереву, пока не достигнут корневых серверов.
Виды операции
На сервере есть разные операции, которые мы можем выполнять как клиенты, ниже вы можете увидеть все, что мы можем сделать:
- Добавить: добавить новую запись. Если запись уже существует, сервер уведомит нас.
- Изменить: изменить запись. Протокол допускает три различных модификации: добавление нового значения, замена значения или удаление значения.
- Удалить: удалить запись.
- Поиск: поиск или получение записей каталога.
- Сравните: посмотрите, имеет ли именованный ввод определенный атрибут.
- Отказаться: отменить предыдущий запрос
- Bind: авторизоваться на сервере
- Запустить TLS — установить безопасную связь с использованием TLS в протоколе LDAPv3.
- Отвязать: закрыть соединение.
Компоненты и структура
- Каталоги: это дерево записей каталогов.
- Входы: состоит из набора атрибутов. Записи описывают пользователя, перечисляя все его атрибуты. Каждая запись имеет уникальный идентификатор со своим DN (отличительное имя).
- Атрибуты: Атрибуты имеют имя и одно или несколько значений, они определены в схемах.
Базовая структура LDAP может быть следующей:
dn: cn=Redes Zone,dc=example,dc=com
cn: Redes Zone
givenName: Redes
sn: Zone
telephoneNumber: +34 666 111 111
telephoneNumber: +34 666 222 222
mail: redeszone@example.com
manager: cn=this article2,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
- dn (отличительное имя): это имя записи, но оно не является атрибутом или частью самой записи.
- cn (общее имя): относительное отличительное имя.
- dc (компонент домена): это отличительное имя родительской записи.
Остальные строки являются атрибутами входных данных, такими как заданное имя, номер телефона, телефонный номер, почта и другой объектный класс, который у нас есть. Сервер всегда содержит поддерево, начинающееся с определенной записи.
Для выполнения поиска мы должны указать URL-адрес для получения информации, синтаксис, который мы должны использовать, следующий:
Многие из этих компонентов являются необязательными, например, мы могли бы просто вызвать DN, чтобы он вернул всю информацию, относящуюся к этой записи.
Различия между Microsoft Active Directory и LDAP
- Microsoft Active Directory
- апаш
- Служба каталогов Red Hat
- OpenLDAP
Его также используют многие другие сервисы, в первую очередь последний OpenLDAP, который представляет собой реализацию протокола с открытым исходным кодом и может быть установлен в любой системе, поскольку исходный код для его компиляции доступен. Однако в большинстве дистрибутивов Linux он доступен в их репозиториях.
Установка и базовая настройка
Установка и ввод в эксплуатацию в операционных системах на базе Linux очень просты, и у нас также есть возможность активировать сервер на QNAP NAS. Далее мы собираемся объяснить, как выполнить установку и базовую настройку в Debian, а также в QNAP.
Debian
Если у нас есть операционная система на базе Linux, такая как Debian, мы сможем установить ldap через официальные репозитории дистрибутива. Для этого мы можем поместить в терминал следующую команду, по логике нам нужны права суперпользователя.
sudo apt install slapd ldap-utils
Как только мы запустим его, он спросит нас, какой пароль администратора поставить на сервер, как только мы его введем, он завершит установку программного обеспечения, и мы сможем начать с ним работать.
Чтобы убедиться, что он был установлен правильно, мы ставим следующий порядок, и он покажет нам все данные сервера в настоящее время.
Следующий скриншот должен показать, что мы получаем сразу после установки:
Теперь нам нужно перенастроить slapd, чтобы поставить собственный домен, мы выполняем следующую команду, чтобы запустить мастер настройки.
sudo dpkg-reconfigure slapd
Мастер спросит нас о многих аспектах сервера, мы можем оставить все, как показано на следующих скриншотах. Самое главное правильно поставить DN.
После того, как мы все сделали, сервер будет готов для добавления разных пользователей.
Первое, что мы должны сделать, это создать список всех пользователей, для этого мы создаем файл в /etc/ldap с именем «users.ldif».
sudo touch /etc/ldap/users.ldif
С помощью любого текстового редактора приступаем к редактированию этого файла со следующим содержимым:
dn: ou=People,dc=redeszone,dc=net
objectClass: organizationalUnit
ou: People
После того, как мы это сделали, мы должны ввести его на сервер следующим образом:
sudo ldapadd -D «cn=admin,dc=redeszone,dc=net» -W -H ldapi:/// -f users.ldif
Он запросит у нас пароль, и мы приступим к его вводу. Это не должно давать нам никаких ошибок.
Наконец, если мы хотим выполнить поиск, мы сможем сделать это следующим образом:
sudo ldapsearch -x -b «dc=redeszone,dc=net» ou
Базовая конфигурация сервера уже выполнена, теперь нам нужно добавить различные записи с необходимой нам информацией.
NAS-сервер QNAP
Если вы используете NAS-сервер QNAP, у нас по умолчанию установлен сервер LDAP. Для этого заходим в раздел «Панель управления/Приложения/LDAP-сервер». В этом меню мы продолжаем вводить доменное имя и пароль администратора, после того как мы его указали, мы продолжаем нажимать «Применить».
После того, как мы применили изменения, сервер будет запущен и запущен. Теперь новые вкладки под названием «Пользователи», «Группа», а также «Восстановление и Восстановить».
В разделе пользователей мы сможем зарегистрировать разных пользователей с помощью небольшого мастера настройки. Нам просто нужно следовать этому простому мастеру, чтобы добавить всех пользователей, которых мы хотим.
У нас также есть возможность добавить новую группу пользователей, у нас также будет мастер, который поможет нам в этом процессе.
Наконец, в разделе резервного копирования и восстановления мы сможем сделать резервную копию всей базы данных сервера и даже восстановить ее из предыдущей копии, что идеально подходит для того, чтобы не потерять всю информацию, содержащуюся на нашем сервере.
Как видите, реализация этого LDAP-сервера в QNAP очень проста, нам не нужно выполнять какую-либо команду через консоль, все делается через графический интерфейс пользователя.
Выводы
Протокол LDAP широко используется в профессиональной среде для аутентификации различных пользователей и там, где мы сможем хранить упорядоченную и иерархическую информацию. Этот протокол используется не только программным обеспечением, таким как OpenLDAP, но и другими системами каталогов, такими как Windows или RedHat, среди многих других, которые мы вам объяснили. Хотя поначалу его работа может показаться сложной, как только мы установим сервер и начнем регистрировать пользователей и группы, вы прекрасно поймете все, что связано с этим важным протоколом.
Этот протокол является одним из самых важных для аутентификации пользователей внутри компании, кроме того, он также часто используется вместе с RADIUS-серверами, и в зависимости от наших потребностей мы можем выбрать этот протокол вместо RADIUS и даже оба сосуществовать в одном локальном сеть для различных целей, которые мы можем ей дать.
LDAP-«аутентификация» — это антипаттерн
Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.
Со временем LDAP стал службой аутентификации де-факто. Широко распространенные и доступные службы LDAP, такие, как Active Directory, стали лакомым кусочком для разработчиков программного обеспечения, которые хотят встроить аутентификацию в свои продукты. Клиентские библиотеки LDAP доступны практически для любого фреймворка, а реализовать интеграцию относительно легко.
Но несмотря на то, что применение LDAP может помочь решить задачу внедрения аутентификации пользователей в различных приложениях компании, оно создает множество проблем. В отличие от специально предназначенных протоколов аутентификации, при использовании LDAP возникают различные уязвимости информационной безопасности.
Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.
Как работает LDAP-аутентификация
Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).
Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!
Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.
К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.
В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы. При этом злоумышленник получит не только возможность разблокировать дверь LDAP, но и доступ к любому приложению, использующему те же учетные данные.
К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.
Недостатки LDAP как системы аутентификации
В 2007 году Шумон Хак выпустил фантастическую статью (LDAP Weaknesses as a Central Authentication System), в которой он описывает три конкретные проблемы при использовании LDAP в качестве системы аутентификации.
1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными
Автор подчеркивает, что защитить от атаки небольшой набор серверов аутентификации гораздо проще, чем защитить большое количество серверов приложений.
В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.
С другой стороны, серверы приложений имеют совершенно иной уровень безопасности и более подвержены риску компрометации. Они менее защищены, работают с более сложными программными стеками и с большей вероятностью имеют уязвимости. И чаще они находятся под управлением людей, которые не имеют глубоких знаний о безопасности. Построение правильной системы безопасности — сложнейший процесс, в котором очень легко допустить ошибку.
Проблема заключается в том, что если один сервер приложений скомпрометирован, то все учетные данные, которыми пользовались их владельцы во время атаки, также скомпрометированы. Под угрозой находится и любая другая система, которая использует тот же каталог LDAP для аутентификации.
2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных
LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.
3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной
Пароль пользователя или секрет аутентификации должен оставаться секретом. Он должен быть известен только самому пользователю и системе аутентификации. При использовании LDAP-аутентификации пользователь вынужден поделиться своим секретом с третьей стороной, чтобы она затем смогла использовать данный секрет для взаимодействия с LDAP-каталогом от имени пользователя.
Важно упомянуть, что при использовании специально предназначенных протоколов аутентификации, таких как Kerberos, и даже с более раннего — NTLM, секрет пользователя никогда не передается по сети. Клиентское устройство и сервер используют криптографические операции, чтобы доказать друг другу, что у них один и тот же секрет и при этом даже не обмениваются самим секретом.
К пунктам Шумона Хука добавлю описание нескольких нюансов LDAP-аутентификации, основываясь на собственном опыте. Прежде всего, тема касается использования Active Directory.
4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать
В одном из моих прошлых постов блога описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.
Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало. Для аутентификации пользователя не должны требоваться и применяться знания о структуре данных, хранящихся в каталоге. Протокол аутентификации должен абстрагироваться от деталей хранилища объектов, расположенного уровнем ниже.
5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом
При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.
Ниже представлены примеры ужасов некорректной настройки.
- Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
- Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
- Отправка паролей в открытом виде на 389-й порт.
- Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?
6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга
Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей). Альянс FIDO стремится сделать пароли пережитком прошлого, а каждое приложение, использующее аутентификацию LDAP, будет помехой на пути к беспарольной политике.
Какие есть варианты?
Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями. Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.
Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией. Стоит попробовать донести до выбранного вендора необходимость доработки продукта с использованием более современных протоколов аутентификации. Возможно он прислушается и пересмотрит свой план разработки.
Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.
В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации. Однако ни в коей мере не стоит поощрять применение LDAP-аутентификации внутри организации. Использование LDAP следует рассматривать только при отсутствии других вариантов.
What is LDAP and how does it work?
As corporations grow, the need to organize user data and assets into a hierarchical structure becomes critical to simplify storage access of those assets. LDAP enables organizations to store, manage, and secure information about the organization, its users, and assets.
In this guide, we’ll explain what LDAP is, its uses, and how it works. We’ll also discuss the levels of LDAP directory and data components – illustrating how it’s an essential tool for managing data about organizations and users alike.
What Is Lightweight Directory Access Protocol (LDAP)?
LDAP is a lightweight version of the Directory Access Protocol (DAP). Its original goal was to provide low-overhead access to an X.500 Directory, but the tool now has a wider variety of uses, which we will discuss later.
LDAP’s primary function is enabling users to find data about organizations, persons, and more. It accomplishes this goal by storing data in the LDAP directory and authenticating users to access the directory. It also provides the communication language that applications require to send and receive information from directory services.
Data and resources that you can find with LDAP include files and user information. It works with printers, computers, and other devices connected via the internet or a company’s intranet.
LDAP works with most vendor directory services, such as Active Directory (AD). With LDAP, sharing information about users, services, systems, networks, and applications from a directory service to other applications and services becomes easier to implement.
What Is LDAP Authentication?
A user cannot access information stored within an LDAP database or directory without first authenticating (proving they are who they say they are). The database typically contains user, group, and permission information and delivers requested information to connected applications.
LDAP authentication involves verifying provided usernames and passwords by connecting with a directory service that uses the LDAP protocol. Some directory-servers that use LDAP in this manner are OpenLDAP, MS Active Directory, and OpenDJ.
Here’s a step-by-step breakdown of the authentication process:
- The client (an LDAP-ready system or application) sends a request to access information stored within an LDAP database.
- The client provides their LDAP server user credentials (username and password).
- The LDAP server cross-checks the user’s submitted credentials against the core user identity data stored in its LDAP database.
- If the provided credentials match the stored core user identity, the client can access the requested information.
- Incorrect credentials will lead to denied access to the LDAP database.
Note that the core user identity stored in the LDAP database isn’t necessarily just usernames and passwords, but also other attributes like addresses, telephone numbers, and group associations.
LDAP vs Active Directory
Active Directory (AD) was developed by Microsoft for Windows domain networks. It is included as a set of services and processes in most Windows operating systems and contains information about each user account connected to the network.
LDAP is a tool for extracting and editing data stored in Active Directory and other compatible directory service providers. Each user account in an AD has several attributes, such as the user’s full name and email address. Extracting this information in a usable format requires LDAP.
LDAP extracts information from AD with a simple, string-based query. LDAP can also share the extracted information (such as usernames and passwords) with connected devices or applications.
Using LDAP eliminates the need for users to manually enter a string of LDAP queries to retrieve information from AD. For example, Microsoft Outlook is an LDAP-enabled Windows program that enters queries automatically to get you the information you want.
What is LDAP used for?
Since LDAP is an open and cross-platform protocol, it works with several directory service providers and has various applications. The most common LDAP use case is serving as a central location for storing authentication information, such as usernames and passwords. You can use the stored authentication information on various applications to validate users.
Popular applications that support LDAP authentication are OpenVPN, Docker, Jenkins, Kubernetes, and Linux Samba servers. System administrators also use LDAP’s single sign on (SSO) feature to manage LDAP database access.
LDAP Operation Types
Here are some basic types of operations in LDAP:
Add
The feature allows you to add new entries to the directory-server database. If the added name already exists, the server won’t accept the entry. Instead, it will deliver an “entryAlreadyExists” notification. LDAP-compliant servers will store added names and other attributes according to the prescribed naming standards to ensure uniformity.
Bind (Authentication)
When you create a session by connecting to an LDAP server, the session’s default authentication state is anonymous. The LDAP bind feature validates the authentication state and changes it from anonymous. Bind can occur either through the Simple or SASL (Simple Authentication and Security Layer) authentication method.
Unbind
Unbind aborts outstanding operations and ends their connections. You can accomplish the same thing by closing the connection, but using unbind is preferred because it frees up resources that may remain assigned to the aborted operation.
Modify
LDAP clients use the modify feature to edit information already stored in a database. Only three types of modifications are permissible:
- Adding a new value to the data
- Replacing or overwriting an existing value
- Deleting an existing value
Search and Compare
The operation lets clients search for and read entries. You can search for entries based on their name, size, scope, type, and other attributes. The compare feature makes it easy to verify whether a named entry has specific attributes.
Delete
Clients use this feature to delete entries from the directory. Note that deletion will not occur unless the client sends a perfectly composed delete request to the server. Some of the features the delete request must have are:
- The name of the entry you want to erase
- Attached request controls
Levels of LDAP Directory
A typical LDAP configuration follows a “tree” hierarchy format. Below are the hierarchy levels from start to end:
- The starting place – a root directory
- Countries
- Organizations or companies
- Divisions, departments, and other organizational units
- People, files, and shared resources (printers, computers, and so on)
You can distribute an LDAP directory across several servers. Queries from the clients are distributed across the multiple servers with the help of replication. Each LDAP server receives requests from users and takes responsibility for the requests before passing them to other servers. The servers will have a replicated version of the directory, and the directories will all synchronize their entries at regular intervals.
LDAP Data Components
Several components work together for LDAP to complete its myriad of tasks, especially when it comes to how it queries and displays data to users. The most essential of these components are:
Attributes
The actual data within an LDAP system are stored as attributes. Each attribute is associated with an attribute type that specifies how clients and the directory server should interact with that attribute. Also, attribute values contain most of the data that users store and access in LDAP systems.
Entries
Attributes define the characteristics of a user or item, while an entry describes the user or item by listing all of their attributes under a name. On their own, attributes have limited functions. You have to associate an attribute with an entry before you can fully utilize it.
Data Information Tree (DIT)
Within an LDAP system, the data defined by attributes represent only a fraction of an object’s available information. The remaining information is obtainable from the entry’s placement within the LDAP system and the relationships its placement suggests. For example, if you have an entry for “inventoryItems” and another for “people”, the data entered under each one will provide a better idea of what each entry represents.
Every entry in an LDAP system is set up as branches on Data Information Trees (DITs). Since every entry in an LDAP tree can symbolize almost anything, users mostly use entries for keeping things organized.
Schemas
Schema is a construct where related ObjectClasses and attribute definitions go under the same category. One DIT can have several unrelated schemas for generating the entries and attributes it needs.
Next steps and further learning
LDAP is an easy-to-implement protocol for consolidating information within your organization. It also serves as a central hub for authentication. You can collect and save user information under one LDAP directory. Whenever an LDAP-enabled application needs any of the stored information, it automatically queries the directory to retrieve it.
Another benefit is that LDAP is open source and compatible with various operating systems, including Windows and Unix-based systems. Below, we’ve included some resources and FAQs — including a blog post on how LDAP authentication works with Sensu Go.
What is an LDAP server?
An LDAP server, also called a Directory System Agent (DSA), runs on Windows OS and Unix/Linux. It stores usernames, passwords, and other core user identities. It uses this data to authenticate users when it receives requests or queries and shares the requests with other DSAs. Several applications and services can connect to a server at once to validate users.
How does LDAP work?
LDAP is a cross-platform protocol for authenticating via directory services. It also provides the communication language applications use to connect to other directory service servers. These directory services house usernames, passwords, and computer accounts, and provide that information to users on the network upon request.
Picture LDAP as a huge virtual phone book. Opening the phone book gives you access to a large directory of contact information for various people, including their usernames and passwords. With LDAP, you can easily verify the credentials of users when they try to access your organization’s database.
What is an LDAP Account?
LDAP Account is an online application for managing different types of accounts stored in an LDAP directory. The account gives users an abstract view of a directory, which makes it easy for people who aren’t tech-savvy to manage LDAP data.
What is the difference between LDAP and Active Directory?
Active Directory (AD) is the directory service database used to store data, authentication and policy of an organization while LDAP is the protocol to communicate with the AD.
In summary, AD works with LDAP, and combining the two applications improves access management.
Is LDAP secure?
LDAP authentication provides standard security with an built-in layer of access management. Malicious actors may still eavesdrop during data transmission between Active Directory and clients. Optimize security by adding SSL/TLS encryption to the LDAP authentication process, which makes information transmitted during the authentication process less vulnerable by encrypting communications.
The default LDAP port used for authentication (Port 389) does not have its own security. Create a secure connection by adding security extensions, such as the LDAPv3 TLS extension or StartTLS mode.
How do you query in LDAP?
LDAP queries facilitate searching for computers, users, groups, and other objects within the Active Directory. LDAP extracts information from AD with the help of a simple, string-based query. You can also use utilities, such as ldapsearch, PowerShell, or VBS scripts to execute queries.
SAML vs LDAP
LDAP and SAML are both authentication protocols that help applications access IT resources. SAML sends user information to your identity provider and other online applications, while LDAP facilitates on-prem authentication and other server processes.
Most organizations combine the use of SAML, LDAP, and other authentication protocols to access various types of IT resources and achieve their business objectives.
Kerberos vs LDAP
Kerberos is a single sign-on and authentication protocol for managing credentials securely. It lets a process connect to an authentication server and provides signed and encrypted tickets for accessing files, applications, and other resources.
LDAP, on the other hand, facilitates accessing OpenLDAP, Active Directory, and other directories. It authenticates connections by cross-checking usernames and passwords stored in the LDAP directory. Since Kerberos is more secure than LDAP and LDAP has more functions than Kerberos, most organizations use both protocols.