SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory. Поиск по базе данных LDAP

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.

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

Без данных статей и понимания - никак

Что такое LDAP в Active Directory (Введение)

Т.к. LDAP пока для меня - это маленькая тайна. Расскажу, что знаю... Итак, LDAP - это некий каталог (дословно - lightweight directory access protocol , в переводе - облегчённый протокол доступа к каталогам ), который хранит в себе различную информацию в древовидной форме и имеет структуру, на нашем примере (на примере домена AD.LOCAL):

Давайте разберем что к чему... В голове структуры - имя домена (AD.LOCAL) , "в подчинении" у домена - отделы (т.н. организационные единицы), у каждого отдела могут быть в подчинении другие отделы. Кроме того, в любой отдел (в том числе и в корневой контейнер - домен) могут входить некие элементы - группы, пользователи, принтеры и др., которые "в себе" могут хранить некоторые настройки - атрибуты объекта (например, у пользователя - пароль, имя, адрес почты и др.).

У каждой записи в LDAP , будь то объект или контейнер с объектами внутри имеется уникальное для всего каталога LDAP имя (т.н. англ. Distinguished Name (DN) - Отличительное имя ). Это даже не имя, а путь , характеризующий полный путь к этом этой записи во всей иерархии. Уникальный путь может выглядеть (на примере группы squid), следующим образом: «cn=squid , ou=groups, ou=UNIXs , dc=ad, dc=local ». Уникальное имя состоит из одного или нескольких относительных отличительных имен (RDN - англ. Relative Distinguished Name ), разделённых запятой. Относительное уникальное имя имеет вид ИмяАтрибута=значение (например cn=squid ). На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами (при этом, в Active Directory имеются некоторые дополнительные ограничения, например, не может быть пользователя с одинаковым именем во всем дереве).

Давайте разберем приведенный путь. Данный путь стОит читать с конца. Он начинается с описания домена , в котором расположен каталог и обозначается как dc=ad, dc=local , здесь - имя dc (оно же Domain Component – компонент доменного имени ) задает имя домена , то есть если бы у нас был домен, например subdomain.ad.local , то данный кусок отличительного имени выглядел бы как dc=subdomain, dc=ad, dc=local. Далее описывается структура иерархия контейнеров отделов (они же OU, они же Organization Unit - организационная единица или подразделение ), которые представляет собой ou=groups, ou=UNIXs . Это стоит читать так же с конца, то есть в текущем домене есть некий контейнер UNIXs , в котором есть подконтейнер groups . Если бы необходимый нам объект находился в отделе, например, Склады, то текущий кусок DN (Distinguished Name) выглядел бы следующим образом: ou=Склады, ou=groups. Далее мы видим в DN описание конкретной записи (в данном случае - запись - это группа squid ). Кусок, DN пути, описывающий группу представляет собой строку cn=squid , где CN - Common Name - общее (относительное) имя (Пользователь, контакт, группа или другой объект, который как правило не имеет дочерних объектов).

Думаю, что общую структуру объяснил понятно. Этого понимания, думаю, будет достаточно для реализации Kerberos LDAP авторизации на основе группы Active Directory .

Настройка squid на Kerberos аутентификацию

Настройку squid на Kerberos аутентификацию необходимо сделать, согласно статьи . После настройки Kerberos аутентификации у нас начинает работать некий прокси-сервер squid, который аутентифицирует доменных пользователей. Предположим, что он имеет некий конфиг:

Ldap ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$ auth_param negotiate program /usr/lib/squid3/squid_kerb_auth auth_param negotiate children 15 auth_param negotiate keep_alive on acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl CONNECT method CONNECT acl localnet src 10.0.0.0/16 acl to_localnet dst 10.0.0.0/16 acl allusers proxy_auth REQUIRED http_access allow manager localhost http_access allow localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow allusers http_access deny !allusers all http_access deny all http_port 10.0.0.10:3129 http_port 127.0.0.1:3129 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320

Конечно же, кроме squid.conf у нас должен быть настроен /etc/krb5.conf и другие необходимые конфиги и, конечно же, Active Directory согласно .

Исходные данные

Конфигурация сети следующая:

Локальная подсеть - 10.0.0.0/16
IP контроллера домена - 10.0.0.1
Имя домена - ad.local
Имя контроллера домена - dc.ad.local
IP хоста со squid - 10.0.0.10

Использование LDAP групп из Active Directory

Собственно, для чего нам использовать LDAP группы из Active Directory? Мы же можем просто составить необходимые списки acl с внесением туда пользователей, например

Acl allusers proxy_auth "/etc/squid3/acls/vipusers.acl" cat /etc/squid3/acls/vipusers.acl [email protected] [email protected] ...

Но это приемлемо, когда в сети 10-30 пользователей и не часто приходится их заводить... Если у вас больше пользователей еще и текучка кадров большая, то становится жутко неудобно вручную добавлять имена в acl и помнить, кого нужно удалить/изменить. После чего перезапускать/релоадить squid, что так же доставляет неудобство для работающих в данный момент пользователей. Гораздо проще добавить пользователя в AD и включить его в некую группу, в результате чего он автоматически получает доступ к глобальной сети с заданными для группы параметрами и не трогать squid совсем...

Для обращения к LDAP Active Directory , в squid используется хелпер squid_ldap_group , кроме того, squid должен быть с опцией --enable-external-acl-helpers="ldap_group" . Как узнать с какими опциями собран squid я писал в .

Настройка Active Directory для использования групп

По умолчанию, в AD запрещено анонимным пользователям получать какую-либо информацию из каталога. Для того, чтобы squid хелпер squid_ldap_group имел право обращаться к каталогу Active Directory и извлекать некую информацию из доменной структуры, необходимо хелперу предоставить некие учетные данные для доступа к LDAP. Для этого я в домене создал учетку с минимально необходимыми правами (членство в группе Domain Users - Пользователи домена ) (??? может будет достаточно группы Гости домена...). Имя учетной записи в моем примере будет [email protected] , важно задать настройку запрета смены пароля и отменить ограничение времени действия пароля при создании учетной записи.

Для удобства, все группы и учетные записи пользователей и компьютеров использующиеся для интеграции сервисов на Linux в инфраструктуру Kerberos я создаю в контейнере UNIXs в подконтейнерах groups, users, hosts соответственно.

Конечно же, нам необходимо создать (для примера) 2 группы пользователей . 1 - это группа, имеющая доступ в интернет без ограничения доступа (называется squid ), 2 - группа, имеющая доступ только к списку избранных сайтов (называется squid-list ). Можно создать сколько угодно групп с заданием разных настроек, но для примера будет достаточно 2х.

Связь хелпера squid_ldap_group с Active Directory

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

Рассмотрим пример установки тестовой связи хелпера squid_ldap_group с каталогом LDAP AD :

Ldap ~ # /usr/lib/squid3/squid_ldap_group -R -d -b "dc=ad,dc=local" \ -f "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,dc=ad,dc=local))" \ -D [email protected] -W /etc/squid3/aduser dc test squid-list Connected OK group filter "(&(objectclass=user)(sAMAccountName=test)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))", searchbase "dc=ad,dc=local" OK [email protected] squid-list Connected OK group filter "(&(objectclass=user)([email protected])(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))", searchbase "dc=ad,dc=local" ERR AD\test squid-list Connected OK group filter "(&(objectclass=user)(sAMAccountName=AD\5ctest)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))", searchbase "dc=ad,dc=local" ERR ivanov squid-list Connected OK group filter "(&(objectclass=user)(sAMAccountName=ivanov)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))", searchbase "dc=ad,dc=local" ERR

Давайте рассмотрим, что мы накуралесили в данной команде (все параметры описаны из man squid_ldap_group):

дословно - do not follow referrals. Как переводится - не знаю Работает и без нее. Но, говорят снижает нагрузку на AD.

ключ указывается на время тестового подключения заставляет squid_ldap_group комментировать свои действия, что помогает в выявлении проблем.

это базовое отличительное имя нашего дерева каталогов (т.н. BaseDN ). Базовое, то есть от этой ветки будет производиться поиск пользователей в LDAP. Допустим, если бы все наши авторизуемые пользователи находились бы в контейнере OU Юристы , то можно было бы задать значение этого ключа -b "ou=Юристы, ou=groups,dc=ad,dc=local" , тем самым снизив нагрузку на LDAP. Т.к. авторизуемые пользователи у меня разбросаны по всей структуре дерева, то в примере я указываю производить поиск от корня дерева -b "dc=ad,dc=local"

задает некий фильтр поиска необходимой нам группы (memberOf=cn=%a) , которая расположена по пути ou=groups,ou=UNIXs,dc=ad,dc=local . В данном фильтре переменная %v заменяется именем пользователя (без указания домена @AD.LOCAL или AD\), а переменная %a заменяется запрашиваемой группой. Т.к. в LDAP я почти ноль, поэтому толкового объяснения данному фильтру не даю... Соответственно, если у вас группа (принадлежность к которой необходимо проверять) расположена в каком-нибудь контейнере linux в домене primer.domen.local , то данный фильтр будет иметь вид: -f "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=linux,dc=primer,dc=domen,dc=local))" .

задает имя пользователя , от которого происходит подключение к каталогу AD.

указывает путь к файлу, который хранит пароль к учетной записи из параметра -D. На данный файл необходимо - пользователя под которым работает squid (обычно это proxy) и на чтение только для владельца.

задает DNS имя сервера LDAP . Здесь можно указать вместо DNS имени - IP адрес.

Далее в листинге я пытаюсь проверить соответствие доменного пользователя test доменной группе squid-list , в которую он действительно входит. При этом, я пытаюсь указать имя пользователя в различных форматах. Как видно, хелпер squid_ldap_group корректно принимает имя только без указания доменной части. О чем нам говорит строка:

Test squid-list Connected OK group filter "(&(objectclass=user)(sAMAccountName=test)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))", searchbase "dc=ad,dc=local" OK

Последней попыткой я пытаюсь проверить принадлежность пользователя ivanov к указанной группе squid-list , при этом, реально ivanov в данную группу не входит. Соответственно, неудачные попытки нам возвращают значение ERR.

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

Настройка squid для авторизации на основе членства в доменной группе LDAP

Приступаем к финальному шагу. Для реализации авторизации на основе членства в доменной группе в squid используется внешний acl, т.н. параметр external_acl_type . Общая схема работы примерно следующая:

# задаем external_acl_type для взаимодействия с LDAP external_acl_type произвольное_имя_ext_acl %LOGIN /путь/к/хелперу/squid_ldap_group -R \ -b "BaseDN" -f "фильтр с переменной %v и %a " -D пользователь_ad@домен -K -W /файл/с/паролем имя_dc # где переменная %v подставляется за счет указания значения %LOGIN, # которое извлекает имя аутентифицированного пользователя # далее необходимо задать acl, которое будет передавать в переменную %a имя групп acl имя_acl external произволное_имя_ext_acl передаваемое_название_группы # далее необходимо с образовавшимся acl работать как с обычным acl, # то есть задавать какие-то разрешения с помощью соответствующих параметров

Если данную схему наложить на наш домен и нашу задачу, то получится примерно следующий конфиг:

Ldap ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$ auth_param negotiate program /usr/lib/squid3/squid_kerb_auth auth_param negotiate children 15 auth_param negotiate keep_alive on external_acl_type ldap_verify %LOGIN /usr/lib/squid3/squid_ldap_group -R \ -b "dc=ad,dc=local" -f "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,dc=ad,dc=local))"\ -D [email protected] -K -W /etc/squid3/aduser dc.ad.local. acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl CONNECT method CONNECT acl localnet src 10.0.0.0/16 acl to_localnet dst 10.0.0.0/16 acl users external ldap_verify squid acl users-list external ldap_verify squid-list acl whitelist dstdomain "/etc/squid3/acls/whitelist.acl" acl allusers proxy_auth REQUIRED http_access allow manager localhost http_access allow localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow users http_access allow users-list whitelist http_access deny !allusers all http_access deny all http_port 10.0.0.10:3129 http_port 127.0.0.1:3129 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320

Давайте разберем получившийся конфиг. Как видно, добавился параметр external_acl_type , заставляющий sqiud обращаться к каталогу LDAP, расположенному на контроллере домена dc.ad.local, через хелпер squid_ldap_group. squid_ldap_group ищет пользователей в каталоге, начиная с пути dc=ad,dc=local , авторизованных пользователей, принадлежащих некоторым группам, имена которых (групп) передаются из acl в переменную %a. Как мы видим, у нас пропал параметр -d за ненадобностью и появился параметр -K. Давайте его разберем. Мы , что при Negotiate Kerberos аутентификации имя пользователя у нас получается в виде пользователь@ДОМЕН , а хелпер squid_ldap_group использует имена в формате пользователь (то есть без доменной части). Так вот, ключ -K заставляет squid_ldap_group "обрезать" часть имени @ДОМЕН и корректно сравнивать имя пользователя и группу.

Далее мы видим, что появилось 3 новых acl - users , users-list и whitelist , которые проверяют принадлежность пользователя к группе с именем squid , к группе с именем squid-list и задает белый список сайтов соответственно. При этом, про первые 2 acl было бы понятней сказать, что они передают в external_acl_type с именем ldap_verify имя группы, которой должен принадлежать аутентифицированный пользователь.

Ну и последнее - это появление двух параметров http_access , которые разрешают доступ acl с именем users и acl с именем users-lis t при доступе этих пользователей к сайтам из acl whitelist . Кроме того, был убран параметр http_access allow allusers , который разрешал доступ всем аутентифицированным пользователям.

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

Особенности работы squid при авторизации на основе доменных групп LDAP

При реализации данной схемы я столкнулся с некоторыми нюансами, которые не стоит оставлять без внимания:

Резюме

В данной статье нам, надеюсь и вам, удалось заставить squid с помощью хелпера squid_ldap_group извлекать из Active Directory информацию о принадлежности пользователя к заданной группе и на основе данной информации предоставлять или не предоставлять доступ к интернету. При этом, есть возможность так же для групп и многие другие настройки и ограничения для доступа в интернет, основываясь на управлении списками доступа acl. До новых статей!

С Уважением, Mc.Sim!

LDAP, или Lightweight Directory Access Protocol – это протокол для управления информацией из централизованного места за счет использования иерархии файлов и каталогов. Его работа чем-то похожа на реляционные базы данных.

LDAP позволяет систематизировать и хранить любого рода информацию. Этот протокол часто используется для централизованной аутентификации.

Данное руководство покажет, как установить и настроить сервер OpenLDAP на выделенный сервер Ubuntu 12.04, а также создать все необходимые группы и пользователей.

Примечание : О настройке LDAP для авторизации можно прочесть в этой серии.

Установка LDAP

Сервер OpenLDAP можно загрузить из стандартных репозиториев Ubuntu. Искомый пакет называется slapd. Кроме того, нужно установить несколько дополнительных утилит.

sudo apt-get update
sudo apt-get install slapd ldap-utils

Система предложит выбрать и подтвердить пароль администратора LDAP.

Настройка slapd

Когда установка будет завершена, нужно перенастроить пакет LDAP. Чтобы открыть инструмент для конфигурации пакета, введите:

sudo dpkg-reconfigure slapd

Система задаст ряд вопросов, чтобы перенастроить пакет.

Omit OpenLDAP server configuration? No
DNS domain name? (Это создаст базовую структуру путей к каталогам; чтобы понять, как это работает, читайте подсказку программы. В целом, общепринятых правил для этой настройки нет. Если у вас есть домен, укажите его здесь. В руководстве используется тестовый домен test.com).
Organization name? (Укажите любое имя; в руководстве – example)
Administrator password? (Укажите пароль, выбранный во время установки пакета, или установите другой пароль).
Database backend to use? HDB
Remove the database when slapd is purged? No
Move old database? Yes
Allow LDAPv2 protocol? No

Установка PHPldapadmin

Для управления LDAP понадобится веб-интерфейс PHPldapadmin. Его тоже можно скачать из репозиториев Ubuntu.

sudo apt-get install phpldapadmin

Эта команда установит необходимый пакет и его PHP-зависимости.

Настройка PHPldapadmin

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

Откройте конфигурации с правами root:

sudo nano /etc/phpldapadmin/config.php

Найдите следующий раздел и отредактируйте его, как показано ниже:

$servers->setValue("server","host","domain_nam_or_IP_address");

Примечание : Значения, выделенные красным, нужно заменить своими данными.

Следующий раздел должен содержать доменное имя (или IP), указанное при перенастройке slapd. Домен нужно преобразовать в формат, который понимает LDAP; для этого нужно разделить все компоненты домена.

Примечание : Компоненты домена – это те его части, что разделены точками.

К примеру, доменное имя imaginary.lalala.com LDAP видит как dc=imaginary,dc=lalala,dc=com. Отредактируйте следующую запись, указав свой домен в правильном формате; условное доменное имя test.com указывается так:

$servers->setValue("server","base",array("dc=test,dc=com"));

Следующее значение, которое нужно изменить, также должно использовать компоненты домена, которые были добавлены в последней записи. Внесите их после cn=admin:

$servers->setValue("login","bind_id","cn=admin,dc=test,dc=com");

Найдите следующий раздел, а в нём – атрибут hide_template_warning. Раскомментируйте строку и установите значение true, чтобы отключить некоторые несущественные предупреждения.

$config->custom->appearance["hide_template_warning"] = true;

Сохраните и закройте файл.

Запуск веб-интерфейса

Откройте в браузере свой домен или IP, добавив сегмент /phpldapadmin.

domain_name_or_IP_address/phpldapadmin

На экране появится приветственная страница интерфейса.

На экране появится форма входа. Если все настройки были выполнены верно, Login DN (имя) будет уже указано (в данном случае это cn=admin,dc=test,dc=com).

Введите пароль, установленный во время настройки slapd.

На экране появится интерфейс с довольно небольшим списком опций.

Нажмите плюсик рядом с доменным именем слева (в данном случае dc=test,dc=com), чтобы развернуть список и увидеть используемую учётную запись.

Добавление подразделений, групп и пользователей

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

Создайте базовую структуру и заполните её информацией.

Создание подразделений

В левой панели нажмите Create new entry here.

Это меню содержит множество различных типов записей.

Чтобы создать простое подразделение, выберите шаблон «Generic: Organizational Unit».

Программа предложит выбрать имя подразделения. Введите groups. Затем нужно зафиксировать изменения.

После этого слева появится новая запись.

Создайте ещё одно подразделение. Повторите описанную выше процедуру, указав имя users.

Теперь в выпадающем списке слева появятся добавленные только что подразделения (чтобы просмотреть список, нажмите плюс рядом с dc=test,dc=com).

Создание групп

Группы позволяют управлять доступом и привилегиями пользователей.

Для примера создадим группы admin, irc и user. После этого нужно настроить аутентификацию пользователей различных групп.

Создайте группы в подразделении groups. Для этого кликните по groups и выберите опцию Create a child entry.

После этого выберите шаблон «Generic: Posix Group». В соответствующем поле укажите имя admin, а затем нажмите Create Object.

Повторите этот процесс, чтобы создать группы irc и user. Будьте внимательны: проверяйте текущую категорию (это должна быть ou=groups), иначе можно создать группу в других категориях.

Чтобы просмотреть созданные группы, откройте в левом меню ou=groups и выберите View 3 children.

Создание пользователей

Теперь нужно создать пользователей и добавить их в группы. Выберите категорию ou=users и нажмите Create a child entry. Выберите шаблон «Generic: User Account». На экране появится довольно большая форма. Заполните её соответствующими данными.

Обратите внимание: Значение Common Name должно быть уникальным для каждой записи в категории. Потому вместо автоматически вносимых в это поле значений рекомендуется указывать имя пользователя.

Нажмите Create Object.

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

Кликните по только что созданному пользователю в левой панели и выберите опцию Copy or move this entry.

Отредактируйте cn=user, указав уникальное значение для common name, а затем нажмите Copy.

На экране появится уже заполненная форма для создания пользователя. При необходимости отредактируйте внесённую информацию. Обязательно измените uidNumber. Нажмите Create Object.

Добавление пользователей в группы

Чтобы добавить пользователя в группу, кликните по требуемой группе и выберите Add new attribute.

В выпадающем меню выберите memberUid. В текстовом поле укажите пользователя, которого нужно добавить, и нажмите Update Object.

Чтобы добавить в группу других пользователей, выберите modify group members и выберите из списка доступных пользователей.

Заключение

Теперь сервер LDAP установлен и готов к работе. Также на нём есть несколько пользователей и групп.

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

Tags: ,

Эта статья - кратчайшее введение в 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, включая корень

filter (фильтр) задает условие отбора записей

Например, поиск по условию

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.