SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory. Использование имени пользователя и пароля администратора. Аутентификация и контроль доступа к данным каталога
- Войдите в Microsoft Windows как Administrator
- Экспортируйте контекст LDAP context в файл, выполнив в консоли команду
- Откройте полученный файл
ldap.txt . Первая его строка будет содержать DN вашего сервера. Например:
Dn: DC=localhost
Вы можете настроить параметры соединения с LDAP в утилите TrackStudio Server Manager, либо, если ее нет — в любом текстовом редакторе.
Настройка через Server Manager
- Выберите параметры авторизации пользователей: какое поле использовать для поиска соответствий в TrackStudio и какое — в LDAP
- Нажмите Проверить соединение чтобы проверить соединение с LDAP
Настройка соединения в файлах.properties
Если у вас отсутствует возможность запустить Server Manager, вы можете настроить интеграцию с LDAP в файле trackstudio.security.properties
- Включите поддержку LDAP в trackstudio.security.properties:
- Если требуется, включите опцию "Использовать LDAP поверх SSL "
- Укажите адрес сервера LDAP и его порт
- Установите Base DN к cn=users
для вашего доменного имени. Вы можете указать несколько Base DN в
настройках LDAP. Используйте точку с запятой в качестве разделителя.
- Укажите учетную запись пользователя, через которую будет осуществляться вход в Active Directory:
- Укажите пароль к этой записи:
Для того, чтобы пользователи, зарегистрированные в LDAP, имели доступ к TrackStudio, для них должны быть созданы учетные записи. Эти учетные записи должны совпадать с записями в LDAP по названию аккаунта, либо по имени пользователя.
- Чтобы входить по имени и фамилии пользователя установите:
- Чтобы входить по названию учетной записи:
Принцип работы
Если установлено trackstudio.useLDAP yes
, TrackStudio будет соединяться с указанным LDAP-сервером при попытке входа пользователя и выполнять авторизацию средствами LDAP, используя учетную запись, указанную в ldap.userDN
и ldap.userDNpass
. TrackStudio затем выполнит локальный поиск в своей базе данных пользователя, соответствущего указанному логину. После этого TrackStudio будет искать в сервере LDAP пользователя, запись ldap.loginAttrLDAP
которого соответствует имени
или логину
(в зависимости от ldap.loginAttrTS
) найденного пользователя. Затем этот пользователь будет авторизован паролем, указанным в окне входа в систему.
TrackStudio поддерживает работу с фильтрами LDAP. Вы можете вписывать свои фильтры в "Поле поиска в LDAP". Таким образом TrackStudio будет работать только с теми пользователями, которые удовлетворяют условиям указанного фильтра. Подробнее о фильтрах вы можете прочитать в этой статье .
Примечание
- Для входа в TrackStudio в окне входа вы должны использовать именно логин
- В любом случае соответствующий пользователь должен иметь учетную запись в TrackStudio
- Когда вы меняете пароль средствами TrackStudio, на сервере LDAP он не меняется
- Пользователь может войти либо при совпадении пароля с паролем в LDAP, либо с паролем в локальной базе данных TrackStudio. Чтобы запретить встроенную авторизацию, удалите com.trackstudio.app.adapter.auth.SimpleAuthAdapter из цепочки в файле trackstudio.adapter.properties .
LDAP (Lightweight Directory Access Protocol - «облегчённый протокол доступа к каталогам») - это сетевой протокол для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP.
Каталог - специальный вид базы данных, которая содержит информацию в древовидной структуре.
LDAP - относительно простой протокол, использующий TCP/IP и позволяющий производить операции авторизации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP- сервер принимает входящие соединения на порт 389 по протоколам Порты TCP или UDP . Для LDAP- сеансов, инкапсулированных в SSL сертификаты для для сайта, почты , обычно используется порт 636. Служба директорий LDAP основана на клиент-серверной модели. Один или несколько серверов LDAP содержат данные, которые создают directory information tree (DIT). Клиент соединяется с сервером и спрашивает его. Сервер дает клиенту ответ и/или указание, где получить дополнительную информацию(обычно, другой LDAP сервер).
Реализации LDAP
LDAP является широко используемым стандартом доступа к службам каталогов. Из свободно распространяемых открытых реализаций наиболее известен сервер OpenLDAP, из проприетарных - поддержка протокола имеется в Active Directory - службе каталогов от компании Microsoft, предназначенной для централизации управления сетями Windows настройка, ускорение, частые вопросы . Другие реализации служб каталогов, поддерживающие LDAP как протокол доступа: Red Hat Directory Server, Mandriva Directory Server, Novell eDirectory, OpenDS .
Как можно обратиться к информации? К записи обращаются по ее уникальному имени, которое состоит из собственно имени записи (так называемое относительное уникальное имя (Relative Distinguished Name, RDN) с прибавлением к нему имён записей-предков. Так, запись, описывающая Barbara Jensen в приведенном выше примере с Internet-именованием, имеет RDN uid=babs, и DN - uid=babs,ou=People,dc=example,dc=com.
Что такое slapd и что он может сделать? slapd (Stand-alone LDAP демон) это сервер директорий LDAP. Вы можете использовать его для обеспечения собственного сервера директорий. Ваша директория может содержать любую информацию, которую вы захотите. Вы так же можете подключить свою директорию к глобальной службе директорий LDAP или запустить службу директорий самостоятельно. Некоторые возможности slapd: пункт 1.9. , например SASL, TLS (или SSL), поддерживает Unicode и языковые теги.
Что такое slurpd и что он может делать? slurpd (8) - демон, который, с помощью slapd(8), обеспечивает работу службы репликаций. Он отвечает за распространение изменений, сделанных в главной БД slapd, на другие БД slapd. Slurpd освобождает slapd от необходимости беспокоится, если другие БД slapd выключены или недоступны, когда произошли изменения в главной БД. Slurpd автоматически повторяет запросы на обновление. Slapd и Slurpd связаны через простой текстовый файл, который используется для записи изменений.
Directory Information Base - DIB ). Информация включает имя объекта , а также различные атрибуты, характеризующие этот объект . Данные рекомендации носят название стандарта Х.500.Для доступа к объектам этой распределенной базы данных был разработан Протокол Доступа к Каталогу ( Directory Access Protocol – DAP ).
LDAP ( Lightweight Directory Access Protocol ) предоставляет большинство возможностей DAP при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции . LDAP , в отличие от Х.500, использует стек ТСР, а не OSI .
Однако не существует взаимно однозначного соответствия между операциями протокола LDAP и операциями протокола DAP стандарта Х.500.
LDAP - это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.
Эта информация представляет собой данные, хранящиеся в атрибутах. При этом предполагается, что такие данные чаще читаются, чем модифицируются. LDAP основан на клиент-серверной модели взаимодействия.
Общая модель данного протокола состоит в том, что сервер выполняет требуемые клиенту операции . Клиент передает запрос , описывающий операцию, которая должна быть выполнена сервером. Сервер выполняет необходимые операции в Каталоге. После завершения операции или нескольких операций сервер возвращает клиенту ответ, содержащий результаты или код ошибки .
Заметим, что хотя требуется, чтобы серверы возвращали ответы всякий раз, когда такие ответы определены в протоколе, не существует требования синхронного поведения клиентов или серверов. Запросы и ответы для нескольких операций могут пересылаться между клиентом и сервером в любом порядке, однако клиенты должны получить ответ на каждый свой запрос .
Информация на сервере LDAP представляет собой совокупность записей, которые содержат набор атрибутов и сгруппированы в древовидную иерархическую структуру.
Запись идентифицируется глобально уникальным именем (Distinguished Name – DN ) – подобно имени домена в структуре DNS .
Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS .
Преимущества LDAP
Основные причины роста популярности LDAP связаны с тем, что:
- LDAP имеет стандартную схему хранения информации в отличие от реляционных баз данных, в которых в каждом случае определяется своя схема хранения в терминах таблиц и столбцов и взаимосвязей между таблицами. Поэтому в LDAP нет специфичного для каждого Каталога и для каждого приложения управления - нет так называемой "проблемы N+1 Каталога". Для всех серверов LDAP используется единая схема хра-нения, единый способ именования хранимых объектов и единый протокол доступа.
- LDAP позволяет быстро отыскивать необходимые данные, поскольку ориентирован в большей степени на чтение и поиск информации, чем на модификацию.
- LDAP не обязательно должен быть ограничен отдельным сервером, существует возможность организовывать распределенные системы из нескольких серверов. Можно создавать ссылки между различными серверами LDAP, что обеспечивает возможность поиска сразу на нескольких серверах LDAP.
- Как протокол LDAP, так и структура Каталога LDAP организованы в соответствии со стандартами, в результате чего можно единообразно использовать реализации LDAP различных производителей.
Сравнение LDAP и базы данных
Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:
- Соотношение чтение-запись – LDAP, в отличие от реляционных баз данных, оптимизирован для чтения.
- Расширяемость – схемы LDAP легче изменить в процессе функционирования, чем схемы баз данных.
- Распределенность – данные LDAP могут располагаться на не-скольких серверах, поиск на которых может осуществляться с использованием одной команды. В результате можно создавать оптимально расположенные конфигурации серверов LDAP, в зависимости от того, где требуется та или иная информация, одновременно обеспечивая возможность поиска всей информации, хранящейся на всех серверах LDAP. Тем самым достигается более высокая степень распределенности по сравнению с реляционными базами данных.
- Репликация – данные LDAP могут храниться на нескольких серверах, при этом существует возможность использования различных способов синхронизации информации.
- Применение данных – LDAP разработан для эффективного использования данных, хранящихся в Каталоге, разными приложениями, базы данных разрабатываются для одного приложения.
- Сложность взаимосвязей между объектами – объекты баз данных имеют более сложные взаимосвязи, чем записи LDAP.
- Транзакции – в LDAP транзакции проще, обычно изменяется одна запись, транзакции в базах данных более сложные.
- Тип хранимой информации – LDAP хранит информацию в атрибутах.
- Способ именования – LDAP является иерархической структурой данных. Имя объекта представляет собой путь к этому объекту в дереве иерархии, аналогично путям к файлам в обычных файловых системах.
- Схемы – схемы реляционных баз данных полностью определяются разработчиком соответствующей базы данных, LDAP имеет стандартные схемы, включая схему Ядра (Core), общую для любого Каталога. Этим достигается большая интеропера-бельность по сравнению с базами данных.
- Стандарты – использование стандартных схем хранения информации и стандартного протокола доступа является преимуществом LDAP по сравнению с базами данных, так как в этом случае клиенты LDAP могут общаться с любым сервером LDAP, а клиенты баз данных могут взаимодействовать только с базой данных, для которой они разработаны.
- Возможность отката при неудачных операциях – реляционные базы данных имеют более гибкие возможности отката, следовательно, они больше подходят для модификации информации, чем LDAP. Для динамичных объектов возможностей LDAP может быть недостаточно.
Принципы развертывания серверов LDAP
При развертывании серверов LDAP необходимо выполнить следующие задачи:
- Решить, что должно храниться в Каталоге. Необходимо четко понимать, какие приложения будут работать с данными.
- Определить структуру данных в Каталоге и установить их вза-имосвязи.
- Определить набор необходимых схем Каталога с учетом требований приложений.
- Определить пространство имен.
- Определить топологию размещения серверов.
- Определить требуемые репликации, гарантируя, что данные будут доступны везде, где они необходимы.
- Определить оптимальный уровень безопасности с учетом кон-кретных требований безопасности.
Эта статья была написана для одного компьютерного журнала довольно давно. Поскольку с тех пор они так и не связались со мной по поводу её дальнейшей судьбы, делаю вывод о том, что она не пригодилась и выкладываю на суд общественности.
Это НЕ руководство по установке и внедрению LDAP. Всего лишь обзор для тех, кто ещё не знает - а что же это за зверь такой...
Комментарии приветствуются.
СЛУЖБЫ КАТАЛОГОВ. что это и для чего они нужны
И что бы люди там ни говорили —
Я доживу, переберу позвездно,
Пересчитаю их по каталогу,
Перечитаю их по книге ночи.
Сети растут. Локальные сети - не исключение. Зачастую сетка, ещё вчера связывавшая три компьютера, сегодня разрослась, заматерела и обросла ресурсами. Как не потеряться в них? Как не запутаться в логинах и паролях? Как быстро найти нужную информацию? Рано или поздно эти вопросы встают практически перед каждым системным администратором.
Многие обходятся самописными скриптами. Это истинные самураи, их воля подобна лезвию катаны, а затраченное время легко компенсируется полученым опытом. Другие же, умудрённые процессом передачи дел и должности в случае смены работы или ухода в отпуск, используют стандартизированные решения. Имя этим решениям - службы каталогов.
В данном обзоре я кратко введу Вас в курс дела. Итак, что же такое службы каталогов?
Очень кратко и очень упрощённо - это своего рода базы данных, хранящие в себе информацию о пользователях, узлах и объектах сети. Цель их создания - упростить администрирование.
Возникает вопрос: отчего же не использовать именно базу данных? Дело в том, что между сервисом каталогов и реляционными базами данных есть довольно существенные различия:
- модель хранения информации - иерархическая древовидная структура (у БД структура реляционная);
- LDAP ориентирован на ускорение операции чтения, тогда как в БД приоритетна операция записи;
- данные в LDAP меняются сравнительно редко;
- клиенты используют стандартный протокол LDAP, тогда как протокол взаимодействия БД с клиентами не стандартизирован;
- и наконец, служба каталогов обычно легко масштабируется (реплицируется) на несколько серверов.
Служба каталогов легко интегрируется с множеством сервисов, начиная от web-серверов, заканчивая CMS (content managment system). Загляните в документацию используемого Вами приложения, требующего авторизации и поищите там ключевое слово LDAP. Нашли? Так это оно и есть...
Начиналось всё просто. Сети были маленькими, а компьютеры - большими. И было их не так чтобы очень много. В те полузабытые, практически былинные времена обходились простым копированием файлов конфигурации с одного компьютера на другой.
Но время шло. Сети росли и матерели. Становилось всё очевиднее, что нужны какие-то решения. То, что облегчит и без того нелёгкую жизнь системных и сетевых администраторов.
Одной из первых реализаций сервисов такого рода стала разработка комапании Sun Microsystems, первоначально названная Yellow Pages. Впоследствии, из за юридических трений, название было заменено на Network Information Service (NIS) под которым она до сих пор широко известна (в узких кругах).
В основе разработки лежала простая мысль - у компьютеров работающие в сети многие конфигурационные файлы полностью совпадают. Так отчего бы не сделать так, чтобы компьютеры брали эти файлы с одного сервера. Таким образом экономилось не только дисковое пространство (NIS была разработана давно и этот фактор был довольно актуален), но и время затрачиваемое на синхронизацию этих файлов.
Службой каталогов это назвать было сложно, но первые шаги в нужном направлении были сделаны.
Поскольку идея оказалась востребована, CCITT и ISO пошли дальше и разработали серию стандартов X.500, которые включали в себя следующие протоколы: DAP (Directory Access Protocol), DSP (Directory System Protocol), DISP (Directory Information Shadowing Protocol) и DOP (Directory Operational Bindings Management Protocol). Однако впоследствии выяснилось, что эти протоколы чрезмерно сложны и была проведена работа по разработке замены. Ей стал протокол LDAP (Lightweight Directory Access Protocol), послуживший основой для многих удачных решений.
История наиболее известных, основанных на LDAP продуктов, уходит корнями в далёкий 1995 год, когда сотрудники Мичиганского Университета написали первый LDAP-сервер - slapd. В 1996 году компания Netscape пригласила их на работу. В 1999 году, компания AOL стала собственником Netscape. Для продолжения работ над серверными продуктами был заключён стратегический альянс с компанией Sun. Назвали это iPlanet Alliance. С 1999 по 2001 годы команда Netscape Directory Server работала совместно с командой Sun Directory Server, а впоследствии и с разработчиками Innosoft Directory Server (IDDS). Работы велись как над Directory Server, так и над смежными проектами, такими как Meta Directory и Directory Access Router. В октябре 2001 года iPlanet Alliance распался, а его участники Sun и Netscape начали независимое развитие своих продуктов. С 2001 по 2004 годы разработчики Netscape Directory Server много работали над этим проектом. В декабре 2004 Netscape Directory Server стал собственностью компании Red Hat.
Итак, покончив на этом с историей, посмотрим - какие службы каталогов имеются в наличии и чем они хороши.
NIS (хотя, строго говоря, это и не служба каталогов).
Эта разработка Sun Microsystems оказалась очень живучей и используется до сих пор. Её плюсами являются простота концепции и реализации. Минус - можно использовать только на UNIX-совместимых операционных системах, с совпадающими конфигурационными файлами. Отдадим ей дань уважения и перейдём к полноценным LDAP-продуктам. В данной статье я не буду останавливаться на технических подробностях, скажу лишь, что их базовая функциональность различается незначительно. Различия начинаются на уровне документации и прикладного софта, облегчающего администрирование.
Итак, начнём с открытых и бесплатных. Их немного. Собственно, всего два.
Red Hat Directory Server и Fedora Directory Server
Red Hat Directory Server изначально была куплена у Netscape Security Solutions как коммерческий продукт для Red Hat Enterprise Linux, теперь её выпускает сам Red Hat под названием Red Hat Directory Server. Следуя своей политике, Red Hat выпускает и версию для Fedora Core. Её название - Fedora Directory Server. Red Hat Directory Server работает под управлением Red Hat Enterprise Linux (x86, версии 3 и 4), Solaris 9 (SPARC, как 32-разрядный, так и 64-разрядный), HP-UX 11i для HP-9000, а также для 64-разрядной линейки HP Integrity server. Fedora Directory Server менее привередлива и соглашается работать как под Fedora Core (x86, версии 3 и 4) и Red Hat Enterprise Linux, так и под другими версиями linux - gentoo, debian и т.п. Поддерживаются также и Solaris, Windows 2000 и HP/UX 11i (pa-risc). Вывод: отличный выбор для дистрибутивов на базе RedHat. Хорошо документирован, чем выгодно отличается от OpenLDAP. Код этих проектов во многом совпадает (из-за общего прародителя).
OpenLDAP
OpenLDAP - дальнейшее развитие оригинального slapd. Широко распространён. Используется на множестве платформ, таких как Linux, FreeBSD, Windows и MacOS X. Документацию на сайте хочется назвать спартанской. Впрочем, sapienti sat, да и пошаговых руководств в сети предостаточно. Если по каким-либо причинам Вам претит использование продукта от RedHat, OpenLDAP - отличный выбор, проверенный временем. Функциональность у обоих проектов практически идентичная.
На этом открытые и бесплатные LDAP-серверы заканчиваются и начинаются решения корпоративного уровня. К сожалению, подробности их происхождения и функциональности скрыты за глянцем маркетинговых пресс-релизов. Поэтому - буду краток.
Novell eDirectory
Сначала несколько слов о политике лицензирования, поскольку она довольно интересна. Во первых, вся продукция бесплатна для ВУЗов. Во-вторых, Вы можете установить этот продукт и использовать его совершенно бесплатно (годовая лицензия на 100000 пользователей. Тех. поддержка отсутствует. Получить можно запрашивая триальный ключ раз в год). В третьих - а можете купить. Цена - 2$ за одну пользовательскую лицензию без временного ограничения. Работает под следующими операционными системами: Novell Netware, Windows (NT-ветка), Linux (SUSE Enterprise, либо RedHat), Solaris, AIX, HP-UX. Резюме: решение всё в одном - весь комплекс необходимых программ поставляется сразу. Установка и настройка сделаны максимально удобными. Невысокая цена. Отличная документация. Для зарегистрированных пользователей - тех. поддержка. Кроссплатформенность. Минус - закрытые исходники.
Microsoft ActiveDirectory
Входит в состав Windows Server 200x. Идеальное решение для сетей MS. Если планируется использовать линейку продуктов только от MS - стоит задуматься. Если же в качестве сервера, используется что-либо отличное от Windows 200x - рекомендую обратить пристальное внимание на вышеперечисленные продукты. Вывод: Отличная интеграция в систему, высококачественная документация. Недостаток - довольно высокая цена.
Sun Java System Directory Server
В начале 2000-х, Sun слилась с компанией iPlanet и используя её разработки (в частности iPlanet Directory Server) создала свой продукт - Sun ONE, впоследствии переименованный в Sun Java System Directory Server. Это не самостоятельный продукт, а лишь часть Java Enterprise System. Системные требования: Solaris 10, Solaris 9, Solaris 8 (только для SPARC), Red Hat Enterprise Linux 2.1 и 3.1, HP-UX 11i, Microsoft Windows 2000, XP (для разработчиков), 2003. Не продаётся отдельно от Java Enterprise System. Вывод - если Вы решили воспользоваться комплексным решением от Sun, у Вас явно не будет особых проблем. Инженеры Sun помогут Вам установить и настроить его под Ваши нужды. За деньги, разумеется.
IBM Tivoli Directory Server
LDAP-решение от IBM. Работает под следующими ОС: AIX, Solaris, Microsoft Windows 2000, HP-UX, а также Linux для Intel и IBM eServer iSeries, pSeries и zSeries. Цены начинаются от 10000$. Решение явно не для всех. Однако стоит отметить доступную для всех документацию. Крайне рекомендую всем, интересующимся LDAP-тематикой, книгу из серии IBM Red Books Understanding LDAP - Design and Implementation Несмотря на то, что освещается в основном IBM Tivoli Directory Server, в ней содержится очень много качественного теоретического материала о том, что такое LDAP и как лучше спланировать Ваш каталог.
На этом я заканчиваю моё слегка затянувшееся повествование. Надеюсь, я смог заинтересовать Вас. Напоследок скажу следующее. LDAP - это следующий шаг за внедрением DHCP. Удобства, приобретаемые благодаря его использованию, перевешивают трудозатраты на его введение. Если в Вашей локальной сети больше 10 компьютеров - задумайтесь о LDAP.
Эта статья - кратчайшее введение в LDAP и службы каталогов. Для иллюстрации излагаемого материала я буду пользоваться инструментом Softerra LDAP Browser, который можно свободно скачать с сайта производителя .
Концепцию служб каталогов и требования к их реализации определяет серия стандартов X.500 ITU-T. Здесь каталог - это специализированная база данных, оптимизированная для поиска и извлечения информации, также поддерживающая добавление и изменение данных.
Среди реализаций служб каталогов наиболее известные - OpenLDAP и MS Active Directory. Клиентами каталогов являются адресные книги почтовых клиентов, сетевые службы, такие как DNS, SMTP, корпоративные приложения и информационные системы.
Как правило, служба каталогов
- реализует протокол для взаимодействия с клиентами,
- поддерживает разграничение доступа,
- поддерживает репликацию каталогов,
- не поддерживает механизм транзакций.
Для взаимодействия со службами каталогов X.500 широко используется протокол LDAP (Lightweight Directory Access Protocol), специфицированный в RFC4510 . LDAP работает поверх TCP/IP и является легковесной альтернативой протокола DAP (Directory Access Protocol), весьма требовательного к вычислительным ресурсам.
LDAP реализует протокол взаимодействия со службой каталогов и задает модель данных, соответствующую X.500. Эта модель данных такова:
- В каталоге хранятся записи (entry).
- Запись - это коллекция атрибутов (attribute), имеющая уникальное имя (Distinguished Name, DN).
- Каждый атрибут имеет тип (type) и одно или несколько значений. Синтаксис значений зависит от типа.
- Атрибут objectClass позволяет контролировать, какие атрибуты обязательны и какие допустимы в записи. Таким образом, записи, как и атрибуты, имеют тип (object class).
- Записи в каталоге организованы иерархически в виде дерева.
- Определения типов записей (object classes) и типов атрибутов сами являются записями в каталоге, в специальном поддереве, известном как schema.
Запустим Softerra LDAP Browser и откроем одну из публичных служб каталогов, параметры соединения с которыми предустановлены по умолчанию. (Настроив соединение с MS Active Directory или OpenLDAP в вашей корпоративной сети, вы можете исследовать структуру и содержимое корпоративного каталога.)
Иерархическая организация данных в каталоге часто отражает географическую или организационную структуру. Записи на верхнем уровне могут представлять страны, на нижних - области стран и организации, еще ниже - отделы внутри организаций, людей, оборудование, ресурсы. А можно построить дерево по доменным именам Internet.
Текущая выбранная запись в каталоге Carnegie Mellon University (см. картинку выше) имеет уникальное имя DN o=CMRI,o=CMU,dc=cmu,dc=edu . Компоненты DN - имена узлов иерархической структуры от корневого до текущего (справа налево). Самый левый компонент DN называется относительным уникальным именем (Relative Distinguished Name, RDN). Таким образом, DN o=CMRI,o=CMU,dc=cmu,dc=edu состоит из RDN o=CMRI и DN родительской записи o=CMU,dc=cmu,dc=edu .
Можно рассматривать DN как абсолютный путь к файлу (по аналогии с файловой системой) или как первичный ключ записи в таблице (по аналогии с реляционной БД).
В рассматриваемом DN o=CMRI,o=CMU,dc=cmu,dc=edu два верхних уровня названы по доменным именам Internet. А уровнем ниже текущей записи располагаются записи, идентифицируемые значением атрибута ou (см. картинку выше). Здесь имена атрибутов, идентифицирующие записи разных уровней, имеют следующие значения:
Dc аббревиатура от domain component o аббревиатура от organization ou аббревиатура от organizational unit
Эти имена, как и десятки других, - имена стандартных атрибутов, специфицированных в RFC 2256 и предназначенных для использования в объектных классах, описывающих людей, организации, их подразделения и т.п. Все реализациии LDAP поддерживают эти стандартные типы атрибутов. Вот еще несколько примеров: telephoneNumber , name , givenName , postalAddress , sn (аббревиатура от surname).
В рассматриваемой записи с DN o=CMRI,o=CMU,dc=cmu,dc=edu имеются три атрибута, objectClass , o и businessCategory , по каждому из которых можно искать эту запись в каталоге.
Для поиска записей в LDAP-каталоге задаются три компонента:
Base DN (базовое уникальное имя) показывает, откуда в иерархии начать поиск scope (область поиска) показывает область поиска, одно из:
- одна запись, идентифицированная base DN
- записи уровнем ниже base DN, т.е. дочерние, но не внучатые
- поддерево с корнем base DN, включая корень
Например, поиск по условию
BaseDN: o=CMU,dc=cmu,dc=edu scope: поддерево filter: objectClass=organizationalUnit & ou=*Student*
вернет все записи из поддерева с корнем o=CMU,dc=cmu,dc=edu , удовлетворяющие фильтру (синтаксис фильтра в этом примере легко читаемый, но неправильный, см. далее).
На заметку: cуществуют специальные базовые DN для запроса информации о возможностях сервера, для доступа к схеме (schema) и данным мониторинга.
В Softerra LDAP Browser по Ctrl+F3 вызывается окно поиска, в котором удобно экспериментировать с параметрами поиска LDAP:
В фильтре можно использовать следующие проверки для атрибутов (атрибут ou взят для примера):
Присутствие атрибута (ou=*) Равенство значения (ou=School) Наличие подстроки (ou=S*) Больше или равно (ou>=School) Меньше или равно (ou
Заметьте, что отсутствуют проверки > и < . Проверка на приближенное равенство ~= использует фонетические сравнение. Расширенная проверка для сравнения образца со значением атрибута использует реализованное LDAP-сервером правило, идентификатор которого указан после двоеточия. Примеры выражений для проверки наличия подстроки (звездочка означает 0 или более символов):
В начале Sch* в середине *oo* в конце *ol в начале и в конце Sc*ol
Проверки в фильтре можно комбинировать при помощи логических операторов:
AND (&(sn=Иванов)(phone=*)(GivenName=И*)) OR (|(cn=Багира)(cn=Балу)) NOT (!(cn=Пикачу))
Внимание! Последний фильтр с NOT вернет также записи, не содержащие атрибута cn .
Формируя запрос, можно указать типы атрибутов, которые должны быть включены сервером каталога в ответ. Если список типов атрибутов пуст, то окно поиска LDAP Browser отображает идентифицирующие атрибуты найденных записей (это RDN) и DN родительских записей - вместе они образуют DN найденных записей. Поиск LDAP всегда возвращает DN найденных записей, помимо и независимо от списка атрибутов. Зададим явно список атрибутов, которые мы хотим видеть и повторим запрос (несуществующие типы атрибутов в списке игнорируются сервером и не приводят к ошибке):
Чтобы хорошо освоить синтаксис фильтра, попробуйте разные проверки и их логические комбинации.
Как уже упоминалось, служба каталогов позволяет не только извлекать, но также добавлять и модифицировать записи. Softerra LDAP Browser поддерживает только просмотр данных в каталоге, поэтому для внесения изменений в каталог необходим другой инструмент (например, платный Softerra LDAP Administrator).
Для работы с LDAP практически из любого языка программирования можно воспользоваться существующими библиотекми для этого языка. В будущих статьях, посвященных LDAP, я рассмотрю работу с MS Active Directory в Oracle PL/SQL и в языке программирования Python.
