что такое ldap авторизация
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Что такое Active Directory и LDAP?
Работаем с каталогами
Active Directory, который является службой каталогов играет такую важную роль в структуре ИТ-инфраструктуры большинства организаций.
Что такое Active Directory?
А еще Active Directory можено интегрировать с Asterisk
Что такое LDAP?
LDAP позволяет приложениям взаимодействовать с другими серверами служб каталогов. Это важно, потому что службы каталогов хранят и передают важную конфиденциальную информацию, связанную с пользователями, паролями и учетными записями компьютеров.
Как Active Directory и LDAP работают вместе?
Active Directory поддерживает LDAP, что означает, что вы можете объединить их, чтобы улучшить управление доступом. Фактически, многие различные службы каталогов и решения для управления доступом могут понимать LDAP, что делает его широко используемым в средах без Active Directory.
Что такое аутентификация LDAP?
Простая аутентификация допускает три возможных механизма аутентификации:
Аутентификация SASL связывает сервер LDAP с другим механизмом аутентификации, таким как Kerberos. Сервер LDAP использует протокол LDAP для отправки сообщения LDAP другой службе авторизации. Это инициирует серию ответных сообщений запроса, которые приводят либо к успешной аутентификации, либо к неудачной аутентификации.
Важно отметить, что по умолчанию LDAP передает все эти сообщения в виде открытого текста, поэтому любой человек, имеющий сетевой анализатор, может читать пакеты. Вам нужно добавить шифрование TLS или подобное, чтобы сохранить ваши имена пользователей и пароли в безопасности.
Что такое запрос 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 следует рассматривать только при отсутствии других вариантов.
OTRS: LDAP аутентификация, авторизация и синхронизация (FreeIPA, AD)
OTRS — система обработки заявок с открытым кодом (Open-source Ticket Request System), написанная на Perl.
Существует в двух вариантах:
Клиенты, очереди, агенты и группы
После установки OTRS у вас сразу будут доступны:
Стандартные группы
После установки системы вы увидите три созданные группы:
Права, связанные с группами
Основные права
Основные права, которые можно настроить в группе, ограничивающие действия агентов:
Дополнительные права
Также существуют и дополнительные права, отображение которых можно включить в настройках (System::Permission):
Аутентификация с использованием базы данных
Стандартный способ аутентификации и авторизации агентов и клиентов — это база данных.
Например, настройки аутентификации агентов, используя базу данных, выглядит так:
Мы также оставим этот способ аутентификации и добавим в дополнение с нему аутентификацию через LDAP.
Роли и компании
Так же мы расширим возможности авторизации, добавив роли и компании:
Постановка задачи
Вы — администратор системы OTRS в компании my-it-company.com, предоставляющей сервисные услуги другим компаниям (или подразделениям внутри вашего холдинга).
Вам очень бы не хотелось заводить учетные записи новых агентов и клиентов вручную, а также заполнять дополнительную информацию, такую как адрес электронной почты, телефон, должность, адрес и номер кабинета — ведь это все уже есть в каталогах LDAP.
И ваша компания также получит очевидные плюсы — единый пароль сотрудника во все системы, блокировка учетной записи в LDAP заблокирует доступ и во все остальные сервисы.
my-it-company.com работает на Linux и использует в качестве сервера каталогов Red Hat FreeIPA, а обслуживаемые вами подразделения — различные леса Microsoft Active Directory, с которыми у вас нет федерации, но есть возможность подключения к контроллерам домена.
Вам нужно разделить потоки заявок от различных клиентов, а также реализовать различные уровни доступа агентов к очередям — менеджеры должны иметь возможность менять приоритет задач в системе.
Сотрудники вашей компании так же могут ставить задачи в системе для внутренних нужд my-it-company.com, иногда являясь и агентами, и клиентами одновременно (а иногда и нет).
Подготовка
Учетные записи для просмотра LDAP
Если запрещен анонимный просмотр дерева каталогов, то создадим в доменах my-it-company.com, pear.com и macrohard.com учетные записи, прав которых нам хватит, чтобы делать запросы к LDAP (назовем их, например, ldap-bot)
Группы FreeIPA для синхронизации с ролями OTRS
Заведем на FreeIPA три группы пользователей, которые будут синхронизироваться с нашими ролями OTRS, например:
Атрибут, определяющий принадлежность к компании
Выберем атрибут, по которому будем определять принадлежность к компании. Пусть это будет атрибут «Организация». Например, у вас все получилось организационно и технически, и все пользователи во всех доменах всегда имеют значение в поле «Организация»:
Определим атрибуты пользователя, используемые FreeIPA
Изучим схему FreeIPA, выяснив названия атрибутов, которые нам понадобятся для синхронизации (ФИО, логин, телефон и т. п.).
dn: uid=laptevs,cn=users,cn=accounts,dc=my-it-company,dc=com
uid: laptevs
givenname: Stanislav
sn: Laptev
cn: Laptev Stanislav
mail: laptevs@MY-IT-COMPANY.COM
l: Moscow
telephonenumber: +7(863)999-99-99
mobile: +7(999)999-99-99
ou: My-it-company
title: SysAdm
Настройка конфигурации OTRS
Файлы конфигурации
Настройка агентов
Аутентификация агентов
Синхронизация агентов (групп LDAP с ролями OTRS)
Если вы решили, что роли вам не подходят, и вы хотите только группы, приведу два примера синхронизации групп LDAP с группами OTRS — упрощенный и с настройкой прав по каждой группе.
Евгений Чайкин aka StraNNik
24 December 2008 г
Два года назад я написал обзорную статью о LDAP-серверах. Некоторое время я собирался вернуться к теме, дабы раскрыть её шире и глубже, но как-то не получалось.
Несколько дней назад к тому старому посту пришёл свежий комментарий. Некто скромный написал:
Ээээ.
написано интересно, но по-прежнему не понятно как этим можно пользоваться. Такие вещи надо уметь объяснить на пальцах. Здесь же написано общими словами и для понимающей публики. Получился обзор рынка LDAP на уровне журнала hard’n’soft а точно не объяснение того, что это такое и с чем это едят. Жаль.
Поскольку буквально в двух предложениях тут выражено то, что вызывало неудовлетворённость у меня самого, сделаю попытку номер два.
Итак, простое, «на пальцах» объяснение — что же такое LDAP и зачем он, собственно, нужен.
LDAP — это гремучая смесь стандартизированного протокола и базы данных.
Откройте опеннет, и Вы наверняка наткнётесь на статью типа «как создать почтовый сервер/фтп/любой-другой-сервис с хранением пользовательских данных в MySQL/PostgreSQL/любой-другой-БД».
И что не так? Спросит меня читатель? Да, в общем, всё так, отвечу я. За исключеньем пустяка. Всё это, по большому счёту, изобретение велосипеда. Которое имеет как положительные стороны (позволяя разобраться в том, что изобретаешь), так и отрицательные — нестандарт периодически выходит боком.
LDAP подразумевает готовые схемы хранения данных для таких случаев. Учётные записи? Пожалуйста. Справочник адресов? Пожалуйста. Права и привилегии? Разумеется.
Кроме готовых схем, LDAP предоставляет готовый стандартизированный протокол, с которым умеют работать многие приложения (а из мэйнстрима — почти всё). Начиная от прокси сервера, заканчивая почтовыми клиентами.
Собственно, это всё.
Стандартизированное хранилище + стандартизированный протокол. Ну и средства управления, куда без них.
Вы будете смеяться, но на этом всё. Просто в следующий раз, когда Вы соберётесь устанавливать любое приложение и Вы задумаетесь — как наиболее оптимально хранить его настройки в БД, попробуйте вбить в гугль поисковый запрос вида: «любое-приложение LDAP» и потратить полчаса на анализ — стоит ли использовать LDAP в Вашем случае.
Напоследок, полезная ссылка и небольшое примечание: в этой заметке автор обращался с терминологией весьма вольно и использовал аббревиатуру LDAP не только для обозначения протокола, но и вместо словосочетания «сервер LDAP».
Спасибо за внимание.
Комментарии
>как наиболее оптимально хранить его настройки в БД
проге будут нужны dn, пароль. возможно настроить права доступа и задать индексы для быстрого поиска.
в принципе, если пишешь сам, то можно задать любую древовидную структуру. видели элемент управления дерево? вот это оно и есть, древовидная структура. лдап хранит данные точно так же + у каждого узла есть имя
тут есть немного теории
http://www.lissyara.su/?id=1277
Основы работы с LDAP
и демо на примере OpenLDAP
может так станет понятнее:)
в схеме как раз и описывается класс и его атрибуты
Похоже все-же придется лезь в длинный man о 200 стр. что бы понять 🙁
2 аноним, среда, 24 декабря 2008 г. 12:45:13:
точно. все описание занимает несколько строчек:)
древовидная база данных заточенная под быстрое чтение, а не запись и добавление данных.
например, OpenLDAP позволяет разбить базу на несколько более мелких. каждая из которых описывается через суффикс.
Что такое ldap авторизация
Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует LDAP как метод подтверждения пароля. LDAP используется только для подтверждения пары «имя пользователя/пароль». Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован LDAP.
В обоих режимах используются следующие параметры конфигурации:
Имена и IP-адреса LDAP-серверов для связи. Можно указать несколько серверов, разделяя их пробелами. ldapport
Номер порта для связи с LDAP-сервером. Если порт не указан, используется установленный по умолчанию порт библиотеки LDAP. ldapscheme
Заметьте, что при использовании ldapscheme или ldaptls шифруется только трафик между сервером Postgres Pro и сервером LDAP. Соединение между сервером Postgres Pro и клиентом остаётся незашифрованным, если только и для него не включён SSL.
Следующие параметры используются только в режиме простого связывания:
Эта строка подставляется перед именем пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания. ldapsuffix
Эта строка размещается после имени пользователя во время формирования DN для связывания, при аутентификации в режиме простого связывания.
Следующие параметры используются только в режиме поиск+связывание:
Корневая папка DN для начала поиска пользователя при аутентификации в режиме поиск+связывание. ldapbinddn
DN пользователя для связи с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание. ldapbindpasswd
Пароль пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание. ldapsearchattribute
Адрес LDAP по стандарту RFC 4516. Это альтернативный способ записи некоторых других параметров LDAP в более компактном и стандартном виде. Формат адреса таков:
Для неанонимного связывания ldapbinddn и ldapbindpasswd должны быть указаны как раздельные параметры.
В настоящее время URL-адреса LDAP поддерживаются только с OpenLDAP и не поддерживаются в Windows.
Нельзя путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это ошибка.
Это пример конфигурации LDAP для простого связывания:
Пример конфигурации для режима поиск+связывание:
Пример той же конфигурации для режима поиск+связывание, но записанной в виде URL:
Такой URL-формат используется и другим программным обеспечением, поддерживающим аутентификацию по протоколу LDAP, поэтому распространять такую конфигурацию будет легче.
Пример конфигурации поиск+связывание, в котором ldapsearchfilter используется вместо ldapsearchattribute для прохождения аутентификации по идентификатору или почтовому адресу пользователя:
Пример конфигурации поиск+связывание, в котором используется поиск SRV-записи в DNS для получения имени сервера и порта службы LDAP в домене example.net :
Подсказка
Поскольку LDAP часто применяет запятые и пробелы для разделения различных частей DN, необходимо использовать кавычки при определении значения параметров, как показано в наших примерах.