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

Михаил Захаров (zakharov@ipb.redline.ru)

Введение.

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

Для построения такой системы на FreeBSD (FreeBSD-4.4-Release) мною было использовано следующее свободно-распространяемое программное обеспечение:

Настройка сервера LDAP.

В качестве сервера LDAP будем настраивать OpenLDAP-2.0.23. Все конфигурационные файлы OpenLDAP находятся в каталоге /usr/local/etc/openldap. Здесь, прежде всего, интересен файл slapd.conf, в котором указываются настройки сервера. В нашем случае этот файл должен состоять как минимум из следующих 8-ми строк:

Первые три строки подключают схемы LDAP. Формат и структура данных, хранимые в LDAP, определяются схемами. Порядок подключения схем важен, поскольку схема может использовать значения, определенные в другой схеме.

Далее указывается тип базы данных, в которой по-настоящему и хранится информация, в нашем случае это ldbm.

Suffix определяет основу для формирования запроса, корень, к которому мы обращаемся при запросе к базе банных LDAP. Suffix выбирается при настройке LDAP-сервера и обычно является доменным именем организации.

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

Последняя строка определяет каталог, в котором будут находиться файлы базы данных LDBM.

В завершении, в slapd.conf полезно добавить правила, разграничивающие доступ к ресурсам LDAP, например такие:

access to dn=».*,dc=testdomain,dc=ru» attr=userPassword

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора 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, или Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения и получения данных из каталога с иерархической структурой. Обычно используемый для хранения информации об организации, ее активах и пользователях, LDAP является гибким решением для определения любого типа сущностей и их свойств.

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

Что такое «служба каталогов»?

Служба каталогов используется для хранения, организации и представления данных в формате «ключ-значение». Обычно каталоги оптимизированы для поиска, поиска и операций чтения поверх операций записи, поэтому они очень хорошо работают с данными, на которые часто ссылаются, но редко меняются.

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

Что такое LDAP?

LDAP, или облегчённый протокол доступа к каталогам, является коммуникационным протоколом, который определяет методы, в которых служба каталога может быть доступна. Говоря более широко, LDAP формирует способ, которым данные внутри службы директории должны быть представлены пользователям, определяет требования к компонентам, используемым для создания записей данных внутри службы директории, и описывает способ, которым различные примитивные элементы используются для составления записей.

Поскольку LDAP является открытым протоколом, существует множество различных реализаций. Проект OpenLDAP является одним из наиболее хорошо поддерживаемых вариантов с открытым исходным кодом.

Основные компоненты данных LDAP

Выше мы обсуждали, как LDAP является протоколом, используемым для связи с базой данных директорий с целью запроса, добавления или изменения информации. Однако это простое определение искажает сложность систем, поддерживающих этот протокол. То, как LDAP отображает данные для пользователей, очень зависит от взаимодействия и отношений между некоторыми определенными структурными компонентами.

Атрибуты

Сама информация в LDAP-системе в основном хранится в элементах, называемых атрибутами. Атрибуты, в основном, являются парами ключ-значение. В отличие от некоторых других систем, ключи имеют предопределённые имена, которые продиктованы выбранным для данной записи объектными классами (об этом мы поговорим чуть позже). Более того, данные в атрибуте должны соответствовать типу, определённому в исходном определении атрибута.

При обращении к атрибуту и его данным (когда он не задан), две стороны соединяются знаком равенства:

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

Записи

Атрибуты сами по себе не очень полезны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP вы используете атрибуты в пределах записи (entry). Запись, по сути, представляет собой набор атрибутов под именем, используемый для описания чего-либо.

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

Пример записи, отображаемой в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

Приведенный выше пример может быть валидной записью в системе LDAP.

Начав знакомиться с LDAP, легко понять, что данные, определяемые атрибутами, представляют собой лишь часть доступной информации об объекте. Остальное — это расположение записи в системе LDAP и связи, проистекающие из этого.

Например, если можно иметь записи как для пользователя, так и для объекта инвентаризации, как кто-то сможет отличить их друг от друга? Один из способов отличить записи разных типов — это создание отношений и групп. Это в значительной степени зависит от того, где находится запись при ее создании. Все записи добавляются в систему LDAP в виде веток на деревьях, называемых Data Information Trees, или DIT-ы.

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

Таким образом, у вас может быть запись для «people» и запись для «inventoryItems». Ваши фактические записи данных могут быть созданы как дочерние записи приведенных выше, чтобы лучше различать их тип. Ваши организационные записи могут быть произвольно определены, чтобы наилучшим образом представить ваши данные.

В примере записи в разделе выше мы видим одно указание на DIT, в строке dn :

Определение компонентов данных LDAP

В последнем разделе мы обсудили, как представлены данные в системе LDAP. Однако мы также должны поговорить о том, как определяются компоненты, которые хранят данные. Например, мы упомянули, что данные должны соответствовать типу, определённому для каждого атрибута. Откуда берутся эти определения? Давайте начнем с самого низа (с точки зрения сложности), и пройдём весь путь вверх.

Определения атрибутов

Атрибуты определяются с использованием достаточно сложного синтаксиса. Они должны указывать имя атрибута, любые другие имена/названия, которые могут быть использованы для ссылки на атрибут, тип данных, а также множество других метаданных. Эти метаданные могут описывать атрибут, указывая LDAP, как сортировать или сравнивать значение атрибута, и пояснять, как он соотносится с другими атрибутами.

Например, это определение для атрибута name :

name — это имя атрибута. Номер в первой строке — это глобально уникальный OID (object id, идентификатор объекта), присвоенный атрибуту, чтобы отличить его от всех остальных атрибутов. Остальная часть записи определяет, как можно сравнить запись во время поиска, и имеет указатель, поясняющий, где найти информацию по требуемому типу данных атрибута.

Определения атрибутов намного сложнее, чем использование и установка атрибутов. К счастью, в большинстве случаев Вам не придётся определять собственные атрибуты, так как наиболее распространённые из них включены в большинство реализаций LDAP, а другие легко импортируются.

Определения классов объектов

Атрибуты собираются в сущностях, называемых ObjectClass (классы объектов). ObjectClasses — это просто группировка связанных атрибутов, которая была бы полезна при описании конкретной вещи. Например, «person» — это objectClass.

Таким образом, если Вы создаете запись для описания человека, то objectClass person (или любой из более специфических объектов objectClasses, производных от person — об этом мы поговорим позже) позволяет использовать все атрибуты внутри этого objectClass:

После этого у вас появляется возможность установить внутри записи следующие аттрибуты:

Атрибут objectClass может использоваться несколько раз, если вам нужны атрибуты из разных классов объектов, но есть правила, которые диктуют, что разрешено. При этом objectClasses-ы бывают нескольких «типов»:

Два основных типа ObjectClasses — это структурный (structural) и дополнительный (auxiliary). Запись должна должна иметь ровно один структурный класс, но может иметь ноль или более вспомогательных классов, используемых для дополнения списка атрибутов, доступных этому классу. Структурный ObjectClasses используется для создания и определения записи, а вспомогательные ObjectClasses-ы добавляют дополнительную функциональность через дополнительные атрибуты.

Определения ObjectClass определяют, являются ли предоставляемые атрибуты обязательными (обозначаются спецификацией MUST ) или необязательными (обозначаются спецификацией MAY ). Несколько ObjectClasses могут предоставлять одни и те же атрибуты, а категоризация атрибута MAY или MUST может варьироваться от objectClass-а к objectClass-у.

В качестве примера, объект Класс person определяется так:

Схемы

Определения ObjectClass и определения атрибутов, в свою очередь, сгруппированы в конструкции, известной как schema (схема). В отличие от традиционных реляционных баз данных, схемы в LDAP представляют собой просто наборы взаимосвязанных ObjectClasses и атрибутов. Один DIT может иметь много различных схем, так что он может создавать нужные ему записи и атрибуты.

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

Организация данных

Мы рассмотрели общие элементы, которые используются для построения записей в LDAP системе и поговорили о том, как эти «строительные блоки» определяются в системе. Однако мы еще не много говорили о том, как организована и структурирована сама информация в LDAP DIT.

Размещение записей в DIT

DIT — это просто иерархия, описывающая взаимосвязь существующих записей. После создания, каждая новая запись должна «подключаться» к существующему DIT, помещая себя в качестве дочерней по отношению к какой-либо существующей записи. Это создает древовидную структуру, которая используется для определения отношений и присвоения значения.

Верхний DIT — это самая широкая категория, под которой каждый последующий узел является чьим-то потомком. Обычно самая верхняя часть записи просто используется как метка, называющая организацию, для которой DIT используется. Эти записи могут быть иметь любой объектный класс, но обычно они строятся с использованием доменных компонентов ( dc=example,dc=com для управляющей информации LDAP, связанной с example.com ), местоположений ( l=new_york,c=us для организации или сегмента в Нью-Йорке), или подразделений организации ( ou=marketing,o=Example_Co ).

Именование (Naming) и ссылочные записи (Referencing Entries) в DIT

Мы ссылаемся на записи по их атрибутам. Это означает, что каждая запись должна иметь однозначный атрибут или группу атрибутов на своем уровне в иерархии DIT. Этот атрибут или группа атрибутов называется относительное отличительное имя или RDN (от relative distinguished name), и несет ту же функцию, что и имя файла в каталоге.

Чтобы однозначно ссылаться на запись, вы используете её RDN в сочетании со всеми RDN её родительских записей. Эта цепочка RDN ведет назад, вверх по иерархии DIT и указывает однозначный путь к соответствующему элементу. Мы называем эту цепочку RDN различимым именем или DN (от distinguished name). Вы должны указать DN для записи во время создания, чтобы система LDAP знала, где разместить новую запись, и могла убедиться, что RDN записи уже не используется другой записью.

По аналогии, вы можете считать RDN относительным именем файла или директории, как если бы вы работали с ними в файловой системе. DN, с другой стороны, больше похоже на абсолютный путь. Важным отличием является то, что LDAP DN содержит наиболее уточнящие значение слева, в то время как файловые пути содержат наиболее уточняющую информацию справа. DN-ы разделяют значения RDN запятой.

Наследование в LDAP

По большей части то, как данные в LDAP-системе соотносятся друг с другом, зависит от иерархии, наследования и вложенности. Изначально LDAP для многих людей кажется непривычным, поскольку в его дизайн реализованы некоторые объектно-ориентированные концепции. В основном это связано с использованием классов, о чем мы уже говорили ранее, и с возможностью наследования, о котором мы поговорим сейчас.

Наследование объектных классов

Каждый objectClass — это класс, который описывает характеристики объектов данного типа.

Однако, в отличие от простого наследования, объекты в LDAP могут быть, и часто являются, экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно потому, что LDAP под классом понимает просто набор атрибутов, которые он ДОЛЖЕН (MUST) или МОЖЕТ (MAY) иметь. Это позволяет указать для записи несколько классов (хотя только один структурный объектный класс может и должен присутствовать), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов со строжайшими определениями MUST или MAY, имеющими приоритет.

Почти все деревья наследования каждого объектного класса заканчиваются специальным объектным классом, называемым «top». Это абстрактный объектный класс, единственное предназначение которого заключается в том, чтобы можно было выполнить требование задавания объектного класса. Он используется для указания вершины цепочки наследования.

Наследование атрибутов

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

Это часто используется для создания более специфических версий общего атрибута. Например, атрибут фамилия (surname) имеет тот же тип, что и имя, и может использовать все те же методы для сравнения и проверки на равенство. Он может унаследовать эти качества, чтобы получить обобщенную форму атрибута «имя» (name). На деле, конкретное определение фамилии может содержать чуть больше, чем указатель на родительский атрибут.

Вариации протокола LDAP

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

Стоит упомянуть, что вы можете увидеть некоторые варианты в обычном формате:

Все три формата используют протокол LDAP, но последние два указывают на дополнительную информацию о том, как он используется.

Заключение

Вы должны достаточно хорошо понимать протокол LDAP и то, как реализации LDAP представляют данные для пользователей. Понимание того, как элементы системы связаны друг с другом, и где они получают свои свойства, делает управление и использование LDAP-систем более простым и предсказуемым.

Источник

Cisco ISE: Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

Приветствую во второй публикации цикла статей, посвященному Cisco ISE. Ссылки на все статьи в цикле приведены ниже:

В данной статье мы углубимся в создание учетных записей, добавлению LDAP серверов и интеграцию с Microsoft Active Directory, а также в нюансы при работе с PassiveID. Перед прочтением настоятельно рекомендую ознакомиться с первой частью.

1. Немного терминологии

Более того, у каждого пользователя и группы пользователей есть дополнительные атрибуты, которые позволяют выделить и более конкретно определить данного пользователя (группу пользователей). Больше информации в гайде.

2. Создание локальных пользователей

1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration → Identity Management → Identities → Users → Add.

Рисунок 1. Добавление локального пользователя в Cisco ISE

2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.

Рисунок 2. Создание локального пользователя в Cisco ISE

3) Пользователей также можно импортировать. В этой же вкладке Administration → Identity Management → Identities → Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.

Рисунок 3. Импорт пользователей в Cisco ISE

3. Добавление LDAP серверов

ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.

В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.

1) Зайдите во вкладку Administration → Identity Management → External Identity Sources → LDAP → Add.

Рисунок 4. Добавление LDAP сервера

2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).

Рисунок 5. Добавление LDAP сервера со схемой Active Directory

Примечание: используйте данные домен админа во избежание потенциальных проблем.

Рисунок 6. Ввод данных LDAP сервера

4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.

Рисунок 7. Определение каталогов, откуда подтянуться группы пользователей

5) Перейдите в окно Groups → Add → Select Groups From Directory для выбора подтягивания групп из LDAP сервера.

Рисунок 8. Добавление групп из LDAP сервера

6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.

Рисунок 9. Перечень подтянутых групп пользователей

7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.

8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.

Рисунок 10. Перечень добавленных LDAP серверов

4. Интеграция с Active Directory

1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration → Identity Management → External Identity Sources → Active Directory → Add.

Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.

Рисунок 11. Добавление сервера Active Directory

2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.

Рисунок 12. Ввод учетных данных

Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.

Рисунок 13. Включение опции PassiveID

4) Перейдите во вкладку Administration → Identity Management → External Identity Sources → Active Directory → PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.

Рисунок 14. Добавление контроллеров домена

5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.

Рисунок 15. Ввод данных контроллера домена

6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent → Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.

Рисунок 16. Автоматическая установка ISE агента

7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers → PassiveID → Providers → Agents → Download Agent.

Рисунок 17. Скачивание ISE агента

Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.

Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.

8) Дополнительно во вкладке Administration → Identity Management → External Identity Sources → Active Directory → Groups → Add → Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 “Добавление LDAP сервера”). Выберите опцию Retrieve Groups → OK.

Рисунок 18 а). Подтягивание групп пользователей из Active Directory

9) Во вкладке Work Centers → PassiveID → Overview → Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.

Рисунок 19. Мониторинг активности доменных пользователей

10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.

Рисунок 20. Активные сессии доменных пользователей

5. Заключение

В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.

Если у вас появились вопросы по данной тематике или же требуется помощь в тестировании продукта, обращайтесь по ссылке.

Источник