Главная Новости

Службы каталогов | Сетевые технологии


Опубликовано: 05.09.2018

видео Службы каталогов | Сетевые технологии

Биометрическая аутентификация в службе каталогов Active Directory

Централизованное управление ресурсами сети подразумевает концентрацию данных об этих ресурсах в базе данных службы каталогов. Каталог хранит сведения о пользователях, компьютерах, принтерах, сетевых сервисах и т.п.



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

Служба каталогов — это сетевой сервис, представляющий централизованные средства управления ресурсами автоматизированной системы. Под ресурсами подразумеваются все компоненты сетевой инфраструктуры, которые используются для выполнения функций АСУ: пользователи, файлы и каталоги, устройства, сетевые сервисы и т.д. ( рис.1 ).


Службы каталога: штатные решения нестандартных задач

Рис. 1. Служба каталогов

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

Рис. 2. Распределенная служба каталогов

Основными функциями службы каталогов являются следующие:

Управление пользователями и группами (создание/удаление, настройка прав доступа). Управление ресурсами (представление в общий доступ, установка ограничений, удаленное администрирование и т.п.). Разграничение прав доступа (как правило, на уровне пользователей, групп и отдельных ресурсов).

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

поиск ресурсов; распространение сетевых политик; интеграция с другими сервисами.

Сетевая политика — совокупность правил, определяющих методы и средства взаимодействия с общими ресурсами в корпоративной сети.

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

Рассмотрим основные особенности некоторых сервисов каталогов, различных по представляемым возможностям.

Популярные службы каталогов

Network Information Service (NIS/YP)

NIS (Сетевая Информационная Служба) — служба каталогов, разработанная и реализованная Sun Microsystems для систем на основе UNIX. NIS первоначально назывались Yellow Pages (YP), но из-за проблем с торговым знаком Sun изменила это название. Старое название (yp) используется в названиях утилит NIS.

NIS - это иерархическая система, в которой существует три типа хостов: основные (master) серверы, вторичные (slave) серверы и клиентские машины ( рис. 3 ). В качестве источников данных для клиентов используются системные файлы (в терминах NIS — карты ресурсов) основного сервера NIS: passwd, hosts, group, services и прочие. В сети может быть один основной сервер NIS и ни одного или более вторичных серверов. Вторичные серверы хранят копии общих файлов основного сервера для обеспечения избыточности. Клиенты могут быть настроены как на работу с основным сервером NIS, так и со вторичными. Чтобы получить доступ к запрашиваемой информации клиент должен являться членом домена NIS.

Рис. 3. Структура Network Information Service (NIS)

Домен NIS — это совокупность доверенных ресурсов с уникальным в пределах сети именем. Имя домена NIS и способ именования ресурсов напоминает адресацию в системе доменных имен (DNS), но никакого отношения к DNS не имеет. Информация о домене хранится на основном сервере NIS и реплицируется на вторичные сервера наравне с прочими ресурсами. Один основной сервер может вести базы нескольких доменов NIS.

Общий доступ реализуется по следующей схеме: когда клиентскому приложению требуется доступ к некоему ресурсу, то локальные обращения (например, к файлу hosts) транслируются в вызовы удаленных процедур сервера NIS, с которым связан клиент. Поскольку NIS использует RPC, то NIS-серверы работают на тех портах, которые им представляет сервис RPC (т.е. у службы NIS нет выделенного номера порта, в отличие от, например, ftp-сервера или веб-сервера).

Установление связи с сервером NIS выполняется путем широковещательной рассылки запросов. Если в сети имеется несколько серверов (основной и несколько вторичных), то клиент NIS (обычно это программа ypbind) будет использовать адрес первого ответившего и направлять все свои запросы на этот сервер. Время от времени ypbind будет проверять доступность сервера. Если тот не ответит за разумное время, то клиент снова начнет процедуру опроса сети в поисках «живого» сервера.

Сервис NIS поддерживается большинством UNIX-систем общего назначения и представляет простые и удобные средства для организации централизованного управления сетью. NIS хорошо интегрируется с такими сетевыми сервисами, как например DHCP или NFS .

Среди сновных проблемы NIS выделим две:

использовании RPC, что может привести к неработоспособности клиентов при недоступности NIS-сервера; передача карт в открытом виде, что может привести к нарушению информационной безопасности.

Из-за второго недостатка NIS не рекомендуется применять в публичных сетях. Для устранения недостатков NIS были разработаны усовершенствованные спецификации протокола (NYS и NIS+), но они не столь популярны.

Практическое задание по развертыванию NIS в локальной сети приведено в этой лабораторной работе. Исходную спецификацию NIS можно получить на сервере Sun Microsystems (теперь Oracle), в разделе документации ( Network Information Service ), а практические советы по планированию и развертыванию этой службы — например, на сервере Linux Documentation Project ( NIS-HOWTO ).

LDAP

Модель OSI определяет самые разные аспекты взаимодействия открытых систем. Имеется в ней и спецификация X.500, описывающая службу каталогов. X.500 — это серия рекомендаций разработанных ITU-T в 1993 г. и получивших статус международного стандарта ( ISO/IEC 9594-1 ). Спецификация X.511 описывает протокол DAP для доступа к каталогам X.500. DAP, принятый в качестве международного стандарта, оказался избыточным и сложным в реализации и на его основе были разработаны адаптированные версии, среди которых NDS и LDAP.

Протокол LDAP (Lightweight Directory Access Protocol, упрощенный протокол доступа к каталогу) — бинарный клиент-серверный протокол прикладного уровня, предназначенный для доступа к распределенной службе каталогов через Интернет. Этот протокол может использоваться как в качестве шлюза к любым X.500-совместимым каталогам ( рис. 4 ), так и в качестве основного сервиса каталогов ( рис. 5 ). Спецификация текущей версии (LDAP v3) приведена в RFC 4510 .

Рис. 4. LDAP в роли шлюза к каталогу X.500

Рис. 5. LDAP в качестве самостоятельного сервиса

В терминах X.500 каталог представляет собой «совокупность открытых систем, совместно предоставляющих службы каталогов». Проще говоря, это распределенная клиент-серверная база данных, доступ к которой возможен через унифицированные интерфейсы. Пользователь каталога, который может быть человеком или другим каким-то объектом, получает доступ к каталогу (Directory) с помощью клиентского приложения ( DUA ). Клиент взаимодействует с одним или более серверами через агентов системы каталогов ( DSA ) ( рис. 4 ).

LDAP устанавливает порядок взаимодействия между клиентом и сервером на основе обмена сообщениями. Сообщения определяют запрашиваемые клиентом операции, ответы сервера и формат передаваемых данных. LDAP — это сессионный протокол, требующий установления, поддержания и разрыва соединения между клиентом и сервером, поэтому основным транспортом для него является TCP. Для сервиса LDAP имеется стандартный порт 389 (TCP/UDP, см. описание «хорошо известных» (well-known) портов в локальном файле /etc/services).

Основной единицей информации, хранимой в каталоге, является отдельная запись (entry). Каждая запись представляет какой-либо реальный объект: человека, компьютер, организацию и т.д. Запись описывает объект через набор присущих ему атрибутов. Атрибуты представляют собой пары вида «имя — значение». Фактическое значение атрибута зависит от его типа ( рис. 6 ).

Рис. 6. Записи и атрибуты LDAP

Записи хранятся в иерархической структуре, называемой «Информационное дерево каталога» (Directory Information Tree, DIT). Обращение к записям осуществляется по их уникальным именам (DN, distinguished name). DN включает полный путь к записи от корня DIT и этим напоминает путь к файлу в файловой системе. Помимо DN используется и относительное уникальное имя (RDN, relative distinguished name).

Если сравнивать DN и RDN с именами файлов, то DN можно представить так:

/home/user/documents/somefile.txt

а, соответственно, RDN так:

somefile.txt

По сути же, DN есть цепочка из RDN'ов элементов структуры разного уровня.

В LDAP используется унифицированная схема именования и набор обязательных и опциональных атрибутов предопределенных типов, которые имеют короткие алиасы. Некоторые типы атрибутов записей приведены в табл. 1 . Простой пример DIT с несколькими записями приведен на рис. 7 .

Тип атрибута Краткая запись (алиас) Пояснение
CommonName cn Общее имя
StateOrProvinceName st Географическое название региона
OrganizationName o Название организации
OrganizationalUnitName ou Название структурного подразделения
CountryName c Страна
StreetAddress street Улица (как часть адреса)
domainComponent dc Элемент домена
userid uid Уникальный идентификатор пользователя

Рис. 7. Пример (и не более того!) информационного дерева каталога (DIT) в LDAP

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

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

Репликация каталога LDAP может выполняться по следующим сценариям:

multi-master — все LDAP-серверы равноправны, в сети отсутствует четко определенный сервер, управляющий данными; master-slave — главный (master) сервер управляет всеми изменениями каталога и рассылает их на подчиненные (slave) серверы. Этот сценарий может быть расширен до делегирования функций синхронизации одному из подчиненных серверов, который и будет реплицировать данные на остальные slave-серверы.

Наиболее известной (но не единственной) открытой реализацией протокола LDAP является проект Open LDAP .

Active Directory

Начиная с версии Windows 2000 Server Microsoft стала использовать собственную, LDAP-совместимую службу каталогов Active Directory. Об особенностях этой системы централизованного управления вы можете почитать здесь и здесь .

Постоянный адрес этой страницы:

rss