ldap аутентификация что это

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-клиент.

Ниже представлены примеры ужасов некорректной настройки.

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 следует рассматривать только при отсутствии других вариантов.

Источник

Централизованная аутентификация с использованием OpenLDAP

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

Contents

Введение в OpenLDAP

Что такое LDAP?

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

X.500 является моделью для сервисов каталога (Directory Services) в концепции OSI. Он содержит определения пространства имен (namespace) и протоколы для запросов и обновления каталога. Однако, существует немало случаев, когда полноценная функциональность X.500 не требуется. Встречайте LDAP. Как и X.500, он обеспечивает модель данные/пространство имен для каталога и протокола. Однако LDAP разработан для прямой работы через стек TCP/IP. Можно считать LDAP сокращенной версией X.500.

Что такое каталог (directory)?

Каталог — это специализированная база данных, созданная для частых запросов, но нечастых обновлений. В отличие от обычных баз данных, каталог не поддерживает транзакции (transaction) или функциональности отката (roll-back). Каталоги легко дублируются для улучшения доступности и надежности. При дублировании каталогов допускаются временные противоречия при условии, что позже они будут синхронизированы.

Как осуществляется структурирование информации?

Вся информация в каталоге структурирована иерархически. Более того, для того, чтобы внести данные в каталог, каталог должен знать, как хранить эти данные в дереве. Рассмотрим вымышленную компанию и дерево, подобное Интернет:

Поскольку данные не записываются в базу в подобной манере ascii-art, каждый элемент этого дерева должен быть определен. Для названий элементов LDAP использует схему наименований. Большая часть дистрибутивов LDAP (включая OpenLDAP) включает в себя определенное количество предопределенных (и одобренных) схем, таких как inetOrgPerson, или часто используемая схема для определения пользователей, которую могут использовать Unix/Linux-системы, которая называется posixAccount. Существуют утилиты графического интерфейса, основанные на веб, для упрощения управления LDAP: раздел Работа с OpenLDAP содержит неполный список таких утилит.

Заинтересованным пользователям рекомендуется прочитать OpenLDAP Admin Guide.

Для чего же его можно использовать?

LDAP можно использовать для разнообразных нужд. В этой статье описывается централизованное управление пользователями, хранение всех учетных записей пользователей в одном местонахождении LDAP (что не означает, что оно находится на одном сервере — LDAP поддерживает высокую доступность (high availability) и резервирование (redundancy)), однако LDAP может использоваться и в других целях.

Настройка сервера OpenLDAP

Общие примечания

USE flags for net-nds/openldap LDAP suite of application and development tools

OpenLDAP поддерживает два механизма аутентификации:

Although the OpenLDAP default is to use SASL, the initial version of this article used only password-based authentication. With the OLC add-on the article starts to describe the use of the simplest SASL mechanism called EXTERNAL, which relies on the system authentication.

У OpenLDAP есть основной пользователь, «rootdn» (Root Distinguished Name), встроенный в приложение. В отличие от традиционного пользователя root Unix, пользователю rootdn необходимо предоставить соответствующие права доступа. Пользователя rootdn можно использовать только в контексте конфигурации, однако его также можно использовать в определении каталога. В этом случае пользователь может аутентифицироваться как rootdn либо с помощью пароля конфигурации, либо с помощью пароля дерева (основанного на каталоге).

В целях верификации, пароли пользователей (как пользователей rootdn, так и других) можно хранить в виде простого текста, либо в хешированном (hashed) виде. Доступно несколько хеш-алгоритмов, но не рекомендуется использовать слабые алгоритмы (вплоть до MD5). На данный момент, SHA считается достаточно безопасным с точки зрения криптографии.

В нижеприведенной команде хешированное значение создается для данного пароля; результат этой команды можно использовать в файле конфигурации slapd.conf либо во внутреннем определении пользователя в каталоге:

Устаревшая конфигурация (через slapd.conf)

Для более подробного анализа файла конфигурации рекомендуем изучить OpenLDAP Administrator’s Guide, хотя man 5 slapd.conf будет достаточно.

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

By default slapd writes the log events to the local4 syslog facility.

Миграция с slapd.conf на OLC

В нижеследующем примере показано, как можно предоставить доступ для управления к OLC (база данных cn=config) для системного администратора (пользователя root), добавив соответствующие строки в конец файла slapd.conf :

Для дополнительных инструкций прочитайте in-line комментарии сгенерированных файлов.

Наконец, создайте структуру /var/lib/openldap-data :

Initial setup with OLC

This initial configuration can be loaded (and only loaded, unlike ordinary LDAP databases) by the slapadd utility:

When using a root account, be sure to correct ownership of the files created by root, as described below in migrate section.

For the right to change the configuration database, proper permissions must be provided. The next example shows how these privileges are granted to the root system user:

When using OLC, never manually edit the configuration files. The directory files can be used to check the consistency of the configuration through:

Обслуживание каталога

После завершения конфигурации запустите slapd :

Большинство пользователей также захотят запускать демон OpenLDAP автоматически:

Теперь можно использовать сервер каталога для аутентификации пользователей в apache/proftpd/qmail/samba.

The directory server can be managed with tools such as net-nds/phpldapadmin, app-admin/diradm and net-nds/jxplorer from the Gentoo ebuild repository, or app-misc/ldapexplorertool from the poly-c overlay available through Layman or eselect repository.

Server management with OLC

Ниже приводится несколько примеров обновления конфигурации в стиле OLC.

Например, чтобы изменить местонахождение каталога конфигурации OLC (необходимо после миграции с конфигурационного файла на каталог конфигураций):

Чтобы изменить уровень журнала, используемого процессом OpenLDAP:

Чтобы применить изменения, запустите следующую команду:

Журналирование в OpenLDAP

OpenLDAP produces numerous log events, which might not be obvious to interpret, but are necessary for debugging purposes.

As OpenLDAP by default writes the log events into the system log, it is advisable to reconfigure the system logger to direct OpenLDAP log events into a dedicated log file.

It is advisable to use the stats stats2 log level in OpenLDAP standalone server and stats stats2 sync in OpenLDAP cluster. In such case query results logs session-related information such as the following:

Most common errors in server log are err=49 :

Which means «invalid credentials» (i.e. wrong password).

Which means «No such object». Usually this error appears when binddn (user) has no permissions on requested object. So either try to do something wrong, or there is a mistake in the set ACLs.

Управление доступом (ACL)

Таблица ниже показывает уровни доступа доступные в OpenLDAP:

Access level	Privileges	Description
none	0	no access
disclose	d	needed for information disclosure on error
auth	dx	needed to authenticate (bind)
compare	cdx	needed to compare
search	scdx	needed to apply search filters
read	rscdx	needed to read search results
write	wrscdx	needed to modify/rename
manage	mwrscdx	needed to manage

For details about the exact privilege settings, see the manual pages and official OpenLDAP documentation.

Конфигурационный файл

ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. For more information, see Access Control Evaluation.

Конфигурационный каталог

ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. This order, when using OLC, is handled through the olcAccess directives.

The following example inserts a new ACL on top, making the existing olcAccess entries to shift by one:

Дублирование

Высокая доступность

Настройка дублирования изменений на нескольких системах LDAP. В данном руководстве дублирование в OpenLDAP настраивается с помощью специальной учетной записи ( ldapreader ), у которой есть права чтения на основном сервере LDAP и которая загружает изменения с основного сервера на вспомогательный.

Replication within OpenLDAP is, in this guide, set up using a specific replication account ( ldapreader ) which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.

Далее эта настройка дублируется, что позволяет вспомогательному серверу LDAP выполнять роль основного. Благодаря внутренней структуре OpenLDAP, если изменения уже присутствуют в структуре LDAP, повторно они не применяются.

Настройка дублирования

Для того, чтобы настроить дублирование, сначала настройте второй сервер OpenLDAP подобно тому, как описано выше. Однако обратите внимание на то, что в файле конфигурации:

Synchronisation account

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

Enabling syncprov overlay

Overlay can be linked statically and dynamically. When it is built dynamically, you’ll need to load module. For now in Gentoo it’s usually built statically. To ensure type:

Load syncprov module (optional)

To load syncprov module, use the following ldif file:

Setting up replication for database

Next step, mandatory for everybody, is to setup replication for database (must be done on both nodes):

Final configuration

Finally, add replication’s definition.

secret traditionally means the password string.

The only difference is in server’s ident (rid) and provider uri.

If LDAP master (mirror node with initially loaded database) is unavailable (slapd daemon not started, or 389/tcp port is blocked by a packet filter) slapd daemon on secondary node fails to start with the following error message:

Almost certainly the database will not fit into default limits. So, you will need to increase ldapreader ‘s limits. For example:

Performance tuning

Default daemon settings significantly limits LDAP server performance.

Symptoms

When server load fits system limit client applications fails with different kind of timeout errors.

In server log this produces error messages like following:

Increasing OS limits

First, read ldap system user limits:

The first parameter, you need to increase, is the open files limit.

Maximum available value is described in Documentation/sysctl/fs.txt file of kernel documentation:

PAM system limits are stored in /etc/security/limits.conf file or, optionally, in /etc/security/limits.d/ directory. Daemons, started with sys-apps/openrc init system use these parameters (see sys-apps/openrc: start-stop-daemon should use system-services PAM stack for details), so you need just to put in the file:

And restart daemon.

The next limitation is sysctl ‘s net.core.somaxconn parameter.

During run time, this value can be updated via:

After verifying new value do not forget to fix it:

And, possibly, some other application-specific parameters.

Настройка клиентских утилит OpenLDAP

Отредактируйте файл конфигурации клиента LDAP. Этот файл читается командой ldapsearch и другими ldap-утилитами командной строки.

Запущенный сервер можно протестировать с помощью следующей команды:

Настройка клиента для централизованной аутентификации

Существует целый ряд методов/утилит для осуществления удаленной аутентификации. Некоторые дистрибутивы также предоставляют свои собственные конфигурационные утилиты, легкие в использовании. Ниже приводится ряд утилит в произвольном порядке. Существует возможность одновременного сочетания локальных пользователей и центрально авторизованных учетных записей. Это важно, поскольку, например, если LDAP сервер недоступен, по-прежнему можно войти в систему в качестве пользователя root.

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

Настройка клиента PAM метод SSSD

Здесь представлен более краткий метод. Ниже приводятся три файла, которые необходимо отредактировать.

Добавьте sss в конце как показано ниже, чтобы включить передачу поиска имени системному сервису sssd. После завершения редактирования запустите демон sssd.

Теперь попробуйте войти в систему с другого компьютера.

Настройка клиента PAM метод модуль pam_ldap

Сначала настроим PAM таким образом, чтобы разрешить авторизацию LDAP. Установите sys-auth/pam_ldap, чтобы PAM поддерживал авторизацию LDAP, и sys-auth/nss_ldap, чтобы система могла справиться с серверами LDAP для дополнительной информации (используется файлом nsswitch.conf ).

Теперь отредактируйте /etc/ldap.conf следующим образом:

Далее скопируйте файл (OpenLDAP) ldap.conf с сервера на клиент, чтобы клиенты знали об окружении LDAP:

Наконец, настройте клиентов таким образом, чтобы они проверяли LDAP на наличие системных учетных записей:

Перенесение существующих данных на LDAP

Настройка OpenLDAP для централизованного администрирования и управления привычными объектами Linux/Unix непроста, но, благодаря некоторым утилитам и сценариям, доступным в Интернете, задача перенесения системы с администрирования одной системы на центрально управляемую систему на основе OpenLDAP не так уж сложна.

Затем распакуйте утилиты и скопируйте сценарий make_master.sh в распакованное местонахождение:

На момент написания, утилитам требуется следующий ввод:

Ввод	Описание	Пример
LDAP BaseDN	Базовое местонахождение (root) дерева	dc=genfic,dc=org
Почтовый домен	Домен, используемый для адресов электронной почты	genfic.org
Почтовый хост	FQDN инфраструктуры почтового сервера	smtp.genfic.org
LDAP Root DN	Информация об административной учетной записи структуры LDAP	cn=Manager,dc=genfic,dc=org
Пароль пользователя Root LDAP	Пароль для административной учетной записи, cfr ранее команда slappasswd

Утилита также запросит, какие учетные записи и настройки следует перенести.

Troubleshooting

Emerge errors after conversion to LDAP

If for any reasons local user accounts (i.e. /etc/passwd /etc/shadow) or groups (i.e. /etc/group) are deleted after converting the file userbase to LDAP, errors may be encountered relating to missing user (or group) while emerging certain packages.

Example of error while emerging www-servers/apache due to missing «apache» local user account:

Источник