Linux. Пользователи и группы

Пользователи и группы пользователей в рамках системы могут быть описаны в локальных файлах /etc/passwd и /etc/group или объявлены на уровне сервера NIS, LDAP или домена Samba. Эти пользователи и группы пользователей могут владеть файлами. На самом деле каждым файлом владеет как пользователь, так и группа пользователей.

Владельцы, участники группы и все остальные

В модели безопасности Unix, пользователь может владеть файлами и каталогами. Когда пользователь владеет файлом или каталогом, он контролирует доступ к нему.

Для всех файлов атрибуты означают:

1. Разрешение на чтение содержимого файла, обозначается буквой r от английского read
2. Разрешение на редактирование и запись содержимого файла, обозначается буквой w от английского write
3. Разрешение на исполнение или запуск скрипта, обозначается буквой x от английского eXecute. На виртуальном хостинге право на исполнение применимо только к папкам и CGI-скриптам. Для обычных файлов (HTML-страницы, картинки, PHP скрипты и т.п.) право на исполнение не будет применяться

Для папок атрибуты означают:

1. Разрешение на чтение позволяет пользователю получить список содержимого папки, обозначается буквой r от английского read
2. Разрешение на запись позволяет пользователю создавать и удалять файлы в этой папке, обозначается буквой w от английского write
3. Разрешение на исполнение разрешает пройти сквозь папку, обозначается буквой x от английского eXecute

В свойствах каждого файла и директории разрешения устанавливаются отдельно для:

1. Владельца файла
2. Группы владельцев файла, которой принадлежит этот файл
3. Всех остальных

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

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

Посмотреть владельца и права доступа к файлам/папкам

Посмотреть права доступа к файлам в Linux проше с помощью графического редактора mc.

Для максимально подробной информации обо всех флагах, в том числе специальных, нужно использовать команду ls с параметром -l:

ls -l файл

user@bash: ls -l /home/karpaff/linuxtutorialwork/chick.png
-rwxr----x 1 harry users 2.7K Jan 4 07:32 /home/karpaff/linuxtutorialwork/chick.png
user@bash:

• Первый символ определяет тип файла. Если первый символ -, то это обычный файл. Если первый символ d, то это каталог.
• Следующие 3 символа показывают разрешения для владельца. Буква означает наличие разрешения, а прочерк - — его отсутствие. В нашем примере у владельца есть все разрешения (чтение, запись и выполнение).
• Следующие 3 символа показывают разрешения для группы. В этом примере у членов группы есть разрешение на чтение, но нет разрешений на запись и выполнение. Обратите внимание, порядок записи разрешений всегда такой: чтение, запись, выполнение. 
• Последние 3 символа показывают разрешения для всех остальных пользователей. В этом примере у них есть только разрешение на выполнение.

Рассмотрим подробнее, что значат условные значения флагов прав:

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

Изменение прав доступа к файлам/папкам

Команда chmod имеет типичный для команд linux синтаксис:

chmod опции права файл

Опций команды, которые нам понадобятся во время работы:

Буквенное обозначение

Права доступа в linux бывают трех основных видов:

• r чтение
• w запись
• x выполнение
• s выполнение от имени суперпользователя (дополнительный)

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

• u владелец файла
• g группа файла
• o все остальные пользователи

Математические операции означают следующее:

• + добавляет к текущим правам доступа новое разрешение
• - удаляет из текущих прав доступа определенное разрешение
• = устанавливает полностью новые разрешения, предыдущие перезаписываются новыми

В одной команде можно перечислять владельцев и их разрешения через запятую.

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

В качестве действий могут использоваться знаки + включить или - отключить. Рассмотрим несколько примеров:

• u+x разрешить выполнение для владельца
• ugo+x разрешить выполнение для всех
• ug+w разрешить запись для владельца и группы
• o-x запретить выполнение для остальных пользователей
• ugo+rwx разрешить все для всех

Числовой формат

• 0 никаких прав
• 1 только выполнение
• 2 только запись
• 3 выполнение и запись
• 4 только чтение
• 5 чтение и выполнение
• 6 чтение и запись
• 7 чтение запись и выполнение

Если используется цифровая запись, первая цифра определяет права владельца, вторая права группы, третья права всех остальных пользователей:

Рекурсивная смена прав

Для смены прав будет использоваться всё та же команда chmod, к ней будет добавлен параметр –R, который собственно и указывает на то, что необходимо сменить права не только самой директории, но и на вложенные папки и файлы. Меняем права на директорию /home/qwerty, а так же на всё содержимое директории:

chmod -R 755 /home/qwerty

chmod -R u+rwx,go+rx /home/qwerty

Какие права следует выставлять

Обычно корректными правами для папок являются 755, а для файлов 644, возможны исключения о которых должен знать разработчик сайта. Также информацию по используемым атрибутам доступа можно найти в документации или на тематических форумах используемой CMS.

Изменение владельца для файла/папки

Синтаксис chown, как и других подобных команд linux очень прост:

chown имя_пользователя опции файл

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

chown имя_пользователя:группа опции файл

Основные опции которые могут понадобиться:

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

Для некоторых специалистов первая встреча с LDAP состоялась при переходе с доменов Windows NT на домены Active Directory или при работе с Novell NDS/eDirectory. В других случаях поддержка LDAP была вторичной по отношению к основной функциональности. Так, у многих знакомство с LDAP произошло при настройке почтовых серверов Exchange 5.5 или Netscape Messaging, создании сайтов Web с требованиями аутентификации, в процессе работы с Web Proxy и т. д. В результате каталоги LDAP стали восприниматься как сугубо утилитарный инструмент для решения той или иной конкретной задачи. Цель настоящей статьи — дать читателям более широкое представление о возможностях применения этой технологии и о внутренней структуре каталогов LDAP.

КАТАЛОГИ LDAP

Каталогом LDAP называют любое хранилище данных с поддержкой протокола LDAP. Наиболее распространенные на сегодняшний день каталоги — Microsoft Active Directory, Sun ONE Directory Server (и более ранние версии того же продукта под марками Netscape и iPlanet) и Novell eDirectory (ранее известный как Novell NDS).

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

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

Заметим, что в компьютерном мире уже существует одна масштабная система, являющаяся, по сути, каталогом — это система серверов DNS. Имеющаяся специализированная технология DNS отлично себя зарекомендовала и не требует улучшений (хотя Microsoft и приняла решение реализовать DNS в Windows 2000 Server на основе Active Directory, т. е. по сути на основе технологии LDAP).

ПРИМЕНЕНИЕ КАТАЛОГОВ LDAP

По способу применения большинство каталогов LDAP можно разделить на несколько основных групп.

Каталоги сетевой операционной системы (Network Operating System, NOS). В настоящий момент наиболее часто встречающийся пример такого использования — построение корпоративной сети под управлением Windows на основе Microsoft Active Directory или Novell eDirectory.

Каталоги NOS содержат информацию обо всех объектах в сети: данные о пользователях, группах пользователей, рабочих станциях, серверах, принтерах и т. д. Внедрение такого каталога обеспечивает централизованное администрирование сети и управление аутентификацией и авторизацией при обращении к сетевым ресурсам. Это позволяет отказаться от дублирования учетной информации в разных точках ее использования. (Надо отметить, что функциональность Active Directory и eDirectory неравнозначна — естественным образом Active Directory лучше интегрирована с ОС Windows NT и 2000. Оба решения имеют как сильные, так и слабые стороны, а потому перед принятием решения необходимо тщательно взвесить целый набор факторов.)

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

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

Характерным примером подобного подхода является линейка продуктов Sun ONE, включающая в себя, помимо прочего, сервер электронной почты, Web Proxy, календарный сервер, сервер Web. Эти продукты изначально рассчитаны на работу с Sun ONE Directory Server, причем все приложения могут хранить данные о пользователях в одном и том же сервере каталогов. Аналогично, почтовый сервер Exchange 2000 опирается на Active Directory как на хранилище данных о своих пользователях.

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

Каталоги в качестве адресных книг организаций. В каталоге может располагаться справочная информация о сотрудниках — адрес электронной почты, номер телефона, комнаты, название должности и т. п. В качестве пользовательского интерфейса применяется обычно почтовый клиент наподобие Microsoft Outlook или Netscape Messenger (только для поиска и чтения) или специально создаваемый клиент, как правило, доступный через Web. Адресная книга служит для поиска и просмотра информации, автоматического заполнения адресов электронной почты и хранения сертификатов PKI, необходимых для организации электронного обмена конфиденциальной информацией.

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

Важно отметить, что с точки зрения управления информационной средой количество сформированных на предприятии каталогов (и в целом — число хранилищ данных о пользователях) желательно свести к минимуму. Поэтому всегда нелишне рассмотреть возможности по применению одного каталога для различных предназначений. Например, каталог NOS может взять на себя роль адресной книги, а каталог какого-либо конкретного приложения можно предоставить в распоряжение других приложений. Подобный подход (консолидация данных о пользователях) в явном виде предлагается крупнейшими производителями каталогов и использующего их ПО — в первую очередь, речь идет о Microsoft и Sun.

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

ПРОТОКОЛ LDAP

Упрощенный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP) представляет собой протокол прикладного уровня; он поддерживает обмен информацией между клиентом и сервером и работает поверх протокола TCP/IP (по умолчанию LDAP использует TCP-порт 389). Идея создания LDAP возникла в ходе экспериментов с ранними реализациями стандарта X.500 в конце 1980-х — начале 1990-х гг. (эти реализации оказались очень сложны и чересчур требовательны к вычислительным ресурсам с клиентской стороны, что привело к необходимости разработки другого клиентского протокола). Технические спецификации нового протокола (RFC 1487 для LDAP версии 2 и RFC 1777 для повсеместно распространенного ныне LDAP версии 3) увидели свет в 1993 и 1995 гг., соответственно.

Первоначально LDAP использовался в качестве дополнения к основному клиентскому протоколу X.500 — протоколу DAP. Таким образом, информационная модель каталогов LDAP полностью унаследована от X.500. В современных каталогах протоколы X.500 либо не поддерживаются вовсе, либо существуют наравне с LDAP, но информационная модель X.500 все равно реализуется — клиент LDAP просто «не знает», от кого он получает информацию — от шлюза между LDAP и DAP или от независимого сервера LDAP.

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

• чтения и поиска — search, compare;
• редактирования — add, delete, modify, rename;
• установления и разрыва связи — bind, unbind, abandon.

Названия этих операций в основном говорят сами за себя и пояснения не требуют. Обратим только внимание на отсутствие операции read — ее функции выполняет search. (Далее мы поясним по механизму работы операции search.)

ХРАНЕНИЕ ДАННЫХ

Спецификации протокола не указывают, в каком именно формате должны храниться сами данные, и производители решают эту задачу по-разному. В большинстве серверов каталогов хранилища сконструированы специальным образом с учетом относительной статичности данных каталога. Каталоги, совмещающие поддержку X.500 и LDAP, используют формат хранения, предписываемый X.500. В каталогах Oracle Internet Directory и IBM SecureWay данные хранятся в реляционных СУБД соответствующих производителей (Oracle и DB2). Наконец, в качестве каталогов LDAP могут выступать и системы, для которых эта функциональность вторична, — например, почтовый сервер Exchange или среда Lotus Domino, где данные представлены в «родных» форматах.

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

Наконец, продукты, наподобие MaXware Virtual Directory (MVD), представляют собой «виртуальные каталоги». MVD работает в качестве шлюза между любым форматом хранения данных (стандартным или нестандартным — к нему прилагается собственная библиотека API для обработки нестандартных форматов) и LDAP. При помощи MVD практически любое хранилище может быть представлено как каталог LDAP.

ИНФОРМАЦИОННАЯ МОДЕЛЬ

Данные в каталогах LDAP представлены как объекты; информация о каждом объекте хранится в наборе атрибутов (точнее, в виде пар «название атрибута — значение атрибута»). Важным отличием от СУБД является возможность присваивать одному объекту несколько атритубов с общим названием: например, объект, описывающий пользователя, может содержать несколько телефонных номеров или адресов электронной почты.

Набор возможных атрибутов задается для каждого каталога заранее. Стандартный набор при необходимости может быть изменен или расширен. Вместе с названием атрибута фиксируется его синтаксис (строка, число, дата и проч.), а потому, в отличие от мира СУБД, название атрибута почти всегда неизменно от каталога к каталогу. Так, атрибут c (country) повсюду означает название страны, l (locality) — населенного пункта, ou (organizational unit) — подразделения организации, cn (common name) — комбинацию имени и фамилии и т. д. В каталогах Active Directory широко применяется атрибут dc (domain component), обозначающий название сегмента корпоративной сети.

Каждый объект каталога принадлежит к одному или нескольким объектным классам. Объектный класс описывает тип объекта и определяет:

• какие атрибуты обязаны присутствовать у объекта данного класса;
• какие атрибуты могут присутствовать у объекта данного класса;
• какой атрибут может использоваться для именования объектов данного класса

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

К примеру, объект, относящийся к классу person, обязан иметь непустые атрибуты cn и sn (фамилия, surname) и может иметь атрибуты telephonenumber, description и некоторые другие. Объект, принадлежащий подклассу organizationalPerson (подкласс person), должен удовлетворять тем же требованиям и может вдобавок содержать иные атрибуты, среди которых title (должность) и ou.

Наиболее распространенным объектным классом для хранения информации о пользователях является на сегодняшний момент inetOrgPerson (здесь inet используется как сокращение от Internet). Это подкласс класса organizationalPerson, он описан в RFC 2798 (в отличие от классов person и organizationalPerson, которые включены в стандарт X.521). Причина в том, что стандарты X.500 формулировались в 1980-х гг. еще до повсеместного распространения Internet, и в описанных там классах отсутствует, например, стандартное поле для адреса электронной почты.

Набор типов атрибутов и объектных классов, определенных для данного каталога, называется его схемой (schema). Схема всех основных каталогов LDAP настраивается администратором, хотя в настоящий момент стандартный способ ее настройки отсутствует, что приводит к определенной степени несовместимости: приложение, которому понадобится каталог LDAP для хранения данных о пользователях, должно поставляться с процедурами адаптации схемы каталога отдельно для каждого (широко используемого) сервера каталогов.

НАИМЕНОВАНИЕ ОБЪЕКТОВ КАТАЛОГА

Объекты каталога организуются в иерархическую логическую структуру — дерево. Его корнем служит пустой корневой объект root; объекты следующего уровня называются суффиксами.

У каждого объекта выделяется один именующий атрибут (Relative Distinguished Name, RDN). Полным идентификатором объекта (Distinguished Name, DN) является строка, полученная конкатенацией всех RDN при перемещении по дереву от данного объекта к корневому (см. пример далее). Заметим, что RDN не обязан быть уникальным в масштабах всего каталога: для обеспечения уникальности DN достаточно, чтобы RDN был уникален среди близлежащих объектов (тех, что расположены непосредственно под объектом, находящимся на один уровень выше).

Иерархия накладывает определенные ограничения на возможности удаления объектов каталога: объект, ниже которого остаются другие объекты, не может быть удален.

ФОРМАТ ОБМЕНА ДАННЫМИ

Формат обмена данными LDAP (LDAP Data Interchange Format, LDIF) — это стандартный способ представления данных каталога в виде текстовых файлов. Благодаря LDIF информация может быть считана из каталога, отредактирована при помощи обыкновенного текстового редактора и экспортирована в тот же или в другой каталог. Файл LDIF может содержать данные о любом количестве объектов каталога.

В качестве примера посмотрим LDIF одного объекта Sun ONE Directory Server:

Из примера видно, что:

• RDN объекта — «uid=vshabat»;
• DN объекта — «uid=vshabat, ou=ICT,o=NIICHAVO», т. е. над ним в дереве имеется еще два объекта (с DN «ou=ICT,o=NIICHAVO» и «o=NIICHAVO», соответственно);
• этот объект каталога принадлежит объектному классу inetOrgPerson и его суперклассам, organizationalPerson, person и top, а также двум дополнительным классам mailrecipient и nsmessagingserveruser, т. е. vshabat является пользователем Sun ONE Messaging Server;
• значение атрибута nsmsgdisallowaccess показывает, что рассматриваемый пользователь не имеет права доступа к электронной почте через протоколы POP и HTTP;
• значение атрибута ou не обязано совпадать со значением RDN вышележащего объекта;
• атрибуты cn, sn и givenName имеют локализованные варианты на русском языке. В файле LDIF они даются после двойного двоеточия в кодировке base64 (LDAPv3 полностью поддерживает кодировку UTF8)

АУТЕНТИФИКАЦИЯ И КОНТРОЛЬ ДОСТУПА К ДАННЫМ КАТАЛОГА

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

Операция bind зачастую используется и другими приложениями, когда в работе с данными каталога нет непосредственной необходимости. Например, приложение может запросить имя пользователя и пароль, сформировать из них запрос к каталогу на операцию bind и проверить ее выполнение. Если операция проходит без ошибок, то аутентификация считается успешной. Заметим только, что в большинстве случаев, когда аутентификация проводится конечными пользователями, детали работы с DN не видны: приложение запрашивает имя пользователя и пароль, затем (соединившись с каталогом в соответствии с собственными правами) находит DN объекта с конкретным именем пользователя и только потом пытается выполнить команду bind.

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

Методы представления информации о контроле доступа (Access Control Information, ACI) до сих пор не стандартизованы и реализуются в различных серверах LDAP по-разному.

ПОИСК ДАННЫХ В КАТАЛОГЕ

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

• адрес сервера (имя DNS или адрес IP);
• номер порта (по умолчанию 389);
• версия LDAP (2 или 3, по умолчанию 3). В настоящий момент серверы, поддерживающие только версию 2, встречаются редко, и многие клиенты по умолчанию используют версию 3;
• DN пользователя, пароль — для аутентификации;
• DN «базового» объекта (Base DN) определяет базу поиска. Поиск будет производиться только в части дерева, лежащей ниже указанного объекта;
• фильтр поиска, где размещены содержательные требования к значениям атрибутов. Строчные атрибуты могут быть проверены на соответствие заданной строке или на наличие в них заданной подстроки. Для численных атрибутов возможен поиск в виде неравенств. Кроме того, в фильтрах можно также использовать стандартные логические операции (AND, OR, NOT);
• область поиска (scope). Возможные варианты — subtree, one или base. При поиске по subtree (наиболее распространенном; многие клиенты задают этот параметр по умолчанию) просматривается часть дерева под базовым объектом. При поиске one рассматриваются лишь те объекты, что находятся непосредственно под базовым (т. е. на один уровень ниже). Наконец, при поиске по base анализируется только сам базовый объект (операция search с областью поиска base является, скорее, операцией считывания, нежели поиска, хотя соответствие записи фильтру поиска все равно проверяется);
• требуемые атрибуты. По умолчанию поиск вернет атрибуты всех найденных записей, а по специальному запросу — значения конкретных атрибутов.

Фильтр поиска может состоять из требования к объектному классу. Например, фильтру «objectclass=inetOrgPerson» соответствуют все объекты этого класса в области поиска.

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

В примере, приведенном на Рисунке 1, фильтр поиска составлен как логическая связка AND условий на должность пользователя и его имя.

ТИРАЖИРОВАНИЕ, ПЕРЕАДРЕСАЦИЯ И ЭСТАФЕТНЫЕ ЗАПРОСЫ

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

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

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

Тиражирование бывает двух видов — с одним или несколькими главными серверами. Первый способ предусматривает, что каждый объект каталога может быть изменен на одном из серверов; его копии на других серверах доступны только для чтения. Второй снимает это ограничение. Полноценная отказоустойчивая система, т. е. система, которая продолжает обрабатывать запросы на редактирование данных после отказа одного из серверов, возможна только во втором случае. Тиражирование с несколькими главными серверами реализовано в каталогах Active Directory, eDirectory и Sun ONE Directory (в последнем случае главных серверов может быть не более двух). Заметим, что подобная схема потенциально опасна: при отсутствии механизма контроля за транзакциями изменения, внесенные на главных серверах, могут конфликтовать друг с другом. Соответствующий механизм решает, какие изменения в итоге осуществятся, а какие — нет (и, как следствие, будут потеряны).

Для реализации отказоустойчивых систем и систем высокой доступности требуются дополнительные средства по распределению нагрузки. Таким инструментом может стать proxy-сервер LDAP, DNS Round Robin или аппаратное решение, наподобие Cisco Local Director.

Несколько серверов можно увязать в единую систему и другими способами. При использовании переадресации (referral) сервер LDAP сообщает, что для обработки запроса клиент должен обратиться к другому серверу LDAP. Переадресация требует, чтобы все принимающие в этом участие клиенты LDAP правильно интерпретировали referral — к сожалению, большинство имеющихся на рынке клиентов этого не делают.

С другой стороны, передача эстафетных запросов (chaining) от клиента LDAP не предполагает никакой дополнительной функциональности: серверы LDAP разделяют дерево каталога между собой и сами пересылают запрос от сервера к серверу. Клиент LDAP в этом случае даже «не знает», что применялся эстафетный запрос. Эстафетные запросы реализованы в серверах каталогов, поддерживающих X.500, — Siemens DirX, Critical Path Directory Server, Nexor. Соответствующий протокол, DSP, является частью стандарта X.500.

АДМИНИСТРИРОВАНИЕ ДАННЫХ КАТАЛОГА

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

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

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

Наконец, различные хранилища пользовательских данных можно объединить в единую систему каталогов — при этом за синхронизацию между хранилищами отвечают метакаталоги. Так, при помощи метакаталога используемый в корпоративной сети каталог Active Directory можно объединить с Sun ONE Directory Server, используемым приложениями Sun ONE, к примеру Messaging Server, а также с корпоративной системой учета кадров. В результате управление содержимым каталога осуществляется автоматически на основе данных других систем.

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

ЧТО ТАКОЕ СЛУЖБА КАТАЛОГОВ?

DNS И СЕТЬ

ЭЛЕКТРОННЫЙ ROLODEX

NDS ПРИХОДИТ НА ПОМОЩЬ

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

ОБЪЕКТЫ NDS ПОД ЛУПОЙ
Люди, места и вещи

ПРОТОКОЛ ДОСТУПА К КАТАЛОГУ ДЛЯ МАСС
LDAP облегчает ношу

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

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

Основной игрок на рынке служб каталогов — это компания Novell с ее Novell Directory Services (NDS). В данной статье мы сравним структуру и функции NDS с другими службами каталогов. Мы оценим также сравнительные достоинства решений с применением других служб каталогов.

ЧТО ТАКОЕ СЛУЖБА КАТАЛОГОВ?

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

Во многом служба каталогов аналогична «желтым страницам». С их помощью вы можете определять местоположение нужной службы по имени в известном окружении (например городе) или производить поиск по определенным категориям (скажем по ресторанам).

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

Чтобы служба каталогов распространялась на разные архитектуры, вы должны иметь возможность обращаться к базе данных о каталогах с любой платформы. Целый ряд компаний реализовал службу каталогов в своих сетевых архитектурах, среди которых DECnet компании Digital Equipment для миникомпьютерной среды и VINES StreetTalk Directory Services компании Banyan для микрокомпьютерной среды. Но на сегодня каждая из этих служб каталогов ориентирована на определенный продукт и поддерживает только сервисы в среде конкретного поставщика.

Отсутствие интероперабельности подвигло комитеты по стандартизации выработать методы реализации и доступа к службе каталогов. Так появился на свет стандарт X.500, разработанный CCITT (теперь это ITU) и принятый ANSI.

Служба каталогов содержит многочисленные типы объектов, каждый из которых имеет набор свойств, определяющих характеристики объекта, предоставляемые сервисы, местоположение и права доступа. Одним из примеров такого объекта является пользователь сети. Профайл пользователя включает информацию об его принадлежности к группам, физическом местоположении, типе компьютера и правах доступа к коммуникационным сервисам, печати и томам, а также к любым другим сервисам, помимо тех, к которым он имеет право доступа как член той или иной группы. Отличие от прежнего сервиса bindery компании Novell в том, что эти права распространяются на всю сеть целиком, а не ограничены одним файловым сервером. (Дополнительную информацию см. во врезке «Люди, места и вещи».)

DNS И СЕТЬ

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

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

Служба каталогов должна также иметь возможность адресовать, идентифицировать и обращаться ко всем средствам и сервисам в Internet. Служба «белых страниц» Internet (Internet White Pages Service, IWPS) предоставляет средства поиска информации о пользователях и организациях в Internet. Однако она не интегрирована в другие службы каталогов. Кроме того, IWPS реализуется на добровольных началах, так что содержащиеся в ней данные часто являются устаревшими.

Один из наиболее популярных аналогов службы поиска IWPS — это whois, предоставляющая информацию о доменах, хостах, сетях и пользователях, зарегистрированных официально Internet-агентствами. В настоящее время доступ к информации IWPS осуществляется преимущественно по стандарту службы каталогов X.500.

ЭЛЕКТРОННЫЙ ROLODEX

Рекомендации X.500 и родственные стандарты предназначены для поддержки коммуникаций между сетевыми системами объектов, таких, например, как данные, приложения, оборудование, пользователи и все, что представляется важным для целей управления. (Документ, опубликованный Гаральдом Альвестрандом с обоснованием рекомендаций X.500, можно найти по адресу: wwwcs.cern.ch/wwcs/public/ftp/pub/internet/draft-ietf-ids-ds-bcp-01.txt.)

Рисунок 1.
В каталоге X.500 содержимое базы данных находится в информационной
базе каталога (DIB). Между пользователем и DIB имеется несколько интерфейсов.
Помимо поиска в DIB агент Directory Services Agent управляет информацией
в DIB и копиями содержащихся в ней деревьев и поддеревьев.

DIB хранит информацию в иерархической древовидной структуре, известной как информационное дерево каталога (Directory Information Tree, DIT). DSA управляет информацией, а также копиями деревьев и поддеревьев. В реализуемой NDS службе каталогов эти копии называются разделами (логические подмножества более крупных объектов) и репликами (копии или образы разделов).

Рекомендации X.500 предусматривают также приложение для управления логической информацией, в том числе создание, удаление, модификацию классов и атрибутов (или свойств) объектов. (Логика, или схема, NDS — это правила, определяющие типы объектов NDS и их свойства.) Данное приложение управляет также правилами DIT.

X.500 имеет некоторые ограничения. Например, полное имя пользователя не является обязательной частью объекта типа пользователь. Однако многие поставщики мощных служб каталогов добавили это свойство в свои продукты — Banyan в StreetTalk, Novell в NDS и т. д.

NDS ПРИХОДИТ НА ПОМОЩЬ

Novell Directory Services состоит из базы данных с информацией о локальных и глобальных сетях, а также инструментов и утилит для управления и навигации по базе данных. Эта многомерная база данных содержит всю информацию о корпоративной сети. Разбитая на логические разделы, база данных тиражируется между несколькими серверами. Тиражирование повышает производительность и обеспечивает избыточность. Например, если файловый сервер выйдет из строя, то каталог все равно будет доступен. Кроме того, пользователи могут входить в сеть, даже если файловый сервер по тем или иным причинам недоступен.

Одним из следствий разбивки на разделы является то, что DNS распределяет фрагменты базы данных между несколькими файловыми серверами. Таким образом, каждый файловый сервер не обязан хранить всю базу данных целиком. Конкретный сервер может содержать одно изображение или реплику раздела каталога. Корневой объект всегда находится в первом созданном разделе, называемом корневым разделом.

Каждый раздел имеет только одну главную реплику. Среди других видов реплик — реплика для чтения/записи и реплика только для чтения.

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

NDS предоставляет информацию о таких сетевых ресурсах, как пользователи, группы, серверы, тома, принтеры и очереди в виде иерархической древовидной структуры. Ресурсы в дереве организуются логическим образом вне зависимости от их физического местоположения. Благодаря этому пользователи могут обращаться к ресурсам, к которым они имеют права доступа, даже не зная, где те находятся.

NDS свободно согласована: она имеет различные уровни согласования на уровне объектов. Цель состоит в синхронизации разделов и реплик, но, например, при изменении одной реплики время, через которое данное изменение будет занесено во все реплики, может различаться. В течение этого временного промежутка база данных находится в несогласованном состоянии, но в процессе согласования.

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

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

NDS базируется на появившейся в 1988 году начальной версии стандарта X.500. Кроме того, NDS содержит такие усовершенствования, как контроль доступа и расширяемость. Цель NDS — обеспечить взаимодействие и обмен информацией между другими базами имен X.500 посредством передачи сертификатов от сертифицированных уполномоченных и других компонентов X.500.

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

ИМЕНА И АДРЕСА

Каталог NDS хранит данные в файлах, расположенных в томах специальных серверов. Эти файлы образуют DIB, а каждая DIB содержит данные для находящихся на соответствующих серверах реплик, а также другие типы глобальной информации.

Кроме того, DIB содержит определения «записей» для каждого допустимого типа объектов каталога. Особый набор полей, называемых свойствами объекта, уточняет определение каждого объекта. Вводимые в поля свойства значения определяют объекты NDS в DIB.

Объекты NDS делятся на две основные категории: физические объекты (например принтеры, серверы, тома и пользователи) и логические объекты (в частности группы, карты каталогов и очереди на печать). Кроме того, логическими объектами являются такие объекты, как организации и организационные единицы, помогающие упорядочить и управлять как физическими, так и логическими объектами.

Объекты NDS — это структуры, хранящие информацию, а не сама информация.

Создавая NDS на базе X.500, Novell предугадала, что отрасль примет его в качестве стандарта, и потому NDS стала одной из первых служб каталогов, поддерживающих облегченный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP). (Дополнительную информацию см. во врезке «LDAP
облегчает ношу».)

NDS уже реализована на платформах наподобие UnixWare и HP-UX, а кое-кто из поставщиков, например IBM и Sun Microsystems, планируют реализовать ее на своих. Интерфейсы API для NDS, в том числе все API службы каталогов для клиентов и сервисов, можно получить бесплатно на узле Web компании Novell по адресу: devsup.novell.com.

Novell собирается интегрировать NDS во все основные серверные платформы. Компания уже предприняла в этом направлении определенные шаги: она предоставила бесплатные лицензии на исходный код NDS основным разработчикам операционных систем. Novell собирается также распространять односерверную двоичную версию NDS для Windows NT по Internet и на основе соглашений с независимыми разработчиками программного обеспечения и поставщиками оборудования.

О заключенных контрактах Novell намеревается объявить в ближайшие несколько месяцев.

STREETTALK КОМПАНИИ BANYAN

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

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

Universal StreetTalk представляет собой независимую от VINES или Enterprise Network Services версию StreetTalk. Banyan предлагает ее бесплатно поставщикам для включения в их продукты.

Universal StreetTalk будет также поддерживать отраслевые стандарты, платформы, сетевые протоколы и протоколы каталогов (такие как DAP, LDAP и Directory System Protocol). Взаимодействуя с другими системами имен, в том числе NDS, Windows NT Directory Service и X.500, он будет предоствлять вход непосредственно в сеть (как это имеет место в NDS и Windows NT).

СЛУЖБА КАТАЛОГОВ MICROSOFT

Windows NT Directory Services компании Microsoft имеет по существу ту же доменную структуру, что и LAN Manager. Домены Windows NT Server образуют строительные блоки сетей на базе NT Server и базис службы каталогов операционной системы.

В Directory Services сервер конфигурируется как первичный контроллер домена (Primary Domain Controller, PDC). Этот сервер содержит информацию о бюджетах пользователей домена; все изменения в учетной информации производятся на PDC. Другие серверы домена можно сконфигурировать как резервные контроллеры домена (Backup Domain Controller, BDC) или обычные серверы.

BDC содержат копии информации о бюджетах пользователей и служат для идентификации пользователей при их регистрации в домене. BDC обеспечивают также отказоустойчивость процесса идентификации. Если PDC выключен, то BDC могут самостоятельно идентифицировать пользователя и предоставить ему доступ к сетевым ресурсам. Любому BDC можно предоставить статус PDC, чтобы он мог распространять по сети любые изменения в каталогах.

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

Тиражирование требует 2 Кбайт при установлении соединения и около 1 Кбайт в расчете на пользователя, так что требования к пропускной способности минимальны. Для задач обновления и резервирования все серверы и клиентские машины в сети сервера NT могут быть синхронизированы по одним системным часам.

Нагрузку по идентификации пользователей PDC делит с BDC. Во многих ситуациях, например в глобальных сетях, BDC ближе к точке входа пользователя, чем PDC. Способность BDC идентифицировать пользователей сокращает как время идентификации, так и сетевой трафик. Это особенно важно в крупных сетях с одним главным пользовательским доменом.

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

Domain Services позволяет создавать несколько доменов и доверительные бюджеты, с помощью которых пользователи одного домена могут получать доступ к данным в другом домене. Недостаток доверительных бюджетов в том, что другие администраторы сети добавляют к ним пользователей доверительного бюджета без вашего ведома. Главный администратор может открывать доверительные бюджеты для каждого нового домена и управлять ими индивидуально из центрального узла, но каждый домен администрируется независимо — всеобъемлющих средств администирования нет. Доверительными бюджетами управлять надо очень осторожно, а пользователи, имеющие к ним доступ, должны очень строго придерживаться мер безопасности.

Microsoft обязалась поддерживать протоколы DAP и LDAP. Так, следующая редакция Exchange Server будет поддерживать LDAP. Очередная редакция Internet Explorer так же, как и ожидаемая крупная редакция Windows NT Server под кодовым названием Cairo (ее появление ожидается в конце этого года), должна поддерживать эти протоколы.

ГЛОБАЛЬНЫЙ ЛОКАТОР

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

ОБЪЕКТЫ NDS ПОД ЛУПОЙ

Люди, места и вещи

Из-за многочисленности типов объектов в службе каталогов значение термина «объект» представляется для большинства неясным. В службе каталогов Novell (NDS) этот термин относится к ресурсам в базе данных NDS. Каталог NDS имеет иерархическую древовидную структуру; наверху дерева находится корень, от которого ответвляются все другие компоненты.

Местоположение объекта в дереве каталога называется его контекстом. Во время процесса установки администратор может задать контекст данного сервера в каталоге. Этот контекст может содержаться внутри имеющегося раздела или быть совершенно новым.

Каждый объект в NDS принадлежит к определенному классу, а каждый класс имеет специфический набор характеристик, называемых свойствами. Базовых классов объектов всего два: физические объекты (например принтеры и пользователи) и логические объекты (скажем очереди на печать и группы).

Каталог NDS содержит объекты-контейнеры и объекты-листья. Подобно ветвям иерархического дерева, объекты-контейнеры, как следует из названия, содержат другие объекты NDS, а также объекты-листья, о которых мы расскажем несколько ниже.

Разновидностей объектов-контейнеров три: страна, организация и организационная единица. Объект-страна позволяет организовать другие объекты с помощью двухбуквенных обозначений для конкретной страны. Этот объект не обязателен (иными словами, он не создается автоматически в процессе установки). Объекты-страны имеют только один уровень. Объект-организация — это объект-контейнер, имя которому дается по названию организации, использующей сеть. В отличие от объекта-страны, объект-организация обязателен. Каталог должен содержать по крайней мере один объект-организацию, но и эти объекты имеют только один уровень. Объект-организационная единица представляет такие элементы, как филиалы компании, отделения и отделы. Эти объекты могут быть многоуровневыми. Родительским объектом является объект-контейнер, содержащий другие объекты каталога.

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

ПРОТОКОЛ ДОСТУПА К КАТАЛОГУ ДЛЯ МАСС

LDAP облегчает ношу

Облегченный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP) — это открытый стандартный протокол Internet для доступа к интерактивным службам каталогов. Он выполняется непосредственно над TCP и применяется почти всеми широко распространенными клиентами каталогов X.500.

LDAP ведет свое начало от протокола доступа к каталогам X.500 (Directory Access Protocol, DAP). LDAP (RFC 1487) был разработан в 1993 году и специфицирован в RFC 1777, 1778, 1779 и 1781.

Не так давно 40 компаний объявили о своем намерении поддерживать LDAP в качестве основного протокола доступа к службам каталогов через TCP/IP. Среди них IBM, Lotus Development, Microsoft, Netscape, Novell, Campbell Services (подразделение FTP Software и создатель OnTime) и Sunsoft.

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

С поддержкой каталогами различных поставщиков стандарта объектам будет проще взаимодействовать друг с другом. Благодаря этому поставщики смогут обеспечить охват всех внутренних сетевых ресурсов в масштабе предриятия и даже доступ к ним через Internet.

RFC 1777 определяет LDAP как протокол поиска в Internet. LDAP не поддерживает сложные средства просмотра, администрирование каталогов, управление логикой, полную идентификацию или инфраструктуру для интернационализации. Отсутствующие функции поддерживаются, однако, протоколом DAP X.500, от которого LDAP происходит. Информационный RFC о LDAP (RFC 1823) описывает функции протокола, которые Microsoft планирует встроить в свой открытый интерфейс службы каталогов (Open Directory Service Interface, ODSI). ODSI базируется на распределенной компонентной объектной модели (Distributed Component Object Model, DCOM), известной прежде как OLE. По существу ODSI — это набор API, с помощью которых разработчики могут обращаться к различным провайдерам службы каталогов.

Содержание

Вступление

В Unix каждому файлу соответствует набор прав доступа, представленный в виде 9-ти битов режима. Он определяет, какие пользователи имеют право читать файл, записывать в него данные или выполнять его. Вместе с другими тремя битами, влияющими на запуск исполняемых файлов, этот набор образует код режима доступа к файлу. Двенадцать битов режима хранятся в 16-битовом поле индексного дескриптора вместе с 4-мя дополнительными битами, определяющими тип файла. Последние 4 бита устанавливаются при создании файлов и не подлежат изменению.
Биты режима (далее права) могут изменяться либо владельцем файла, либо суперпользователем с помощью команды chmod.

Флаг типа (flag) может быть одним из следующих: