Основное улучшение NetWare связано с введением службы каталогов Directory Services (NDS). В данной главе мы ближе познакомим вас с принципами Directory Services. Вы узнаете, из каких частей и фрагментов состоит информационная база данных DIB (Directory Information Base) и какие средства образуют Directory Services.
Directory Information Base (DIB) состоит из схемы каталогов (Directory Schema), дерева каталогов (Directory Tree) и других специальных объектов, используемых для ссылки и в целях эмуляции базы объектов Bindery. Доступ к DIB реализуется через Directory Services. Любой сервер, предусматривающий средства службы каталогов, можно назвать сервером имен (Name Server).
Схема каталога Directory Schema определяет правила построения объектов, которые находятся в Directory Tree. Дерево каталогов Directory Tree - это набор объектов в DIB, за исключением определений Directory Schemа. Так как записи Directory Schema в DIB представляет собой определения, они не размещаются в дереве каталогов Directory Tree, а используются как справочная база данных.
Если вы нарисуете схему, показывающую отношение объектов в дереве каталогов, то она будет выглядеть как перевернутое дерево или корни дерева. Верхний объект в дереве называется корневым объектом. Иногда на него ссылаются как на [root]. Этому корню [root] подчиняются все другие объекты в дереве.
Объекты в дереве идентифицируются по их именам и именам порождающих объектов. Полное имя объекта включает в себя имя объекта и имена всех объектов между ним и корнем [root] дерева.
Наблюдая за порядком имен объектов в полном имени, вы можете видеть структуру дерева каталога Directory Tree. Полное имя называется также отличительным именем объекта - DN (Distinguish Name). Само имя объекта - это частичное или относительное имя RDN (Relative Distinguish Name).
Следующий рисунок дает вам представление о содержимом дерева каталога и взаимосвязи объектов в нем.
[root]
¦¦+-----------------------+
+---------------+¦ ¦
¦ +---+ ¦
+---+---+ +---+---+ +---+---+
¦ A1 ¦ ¦ A2 ¦ ¦ A3 ¦
+-+-+-+-+ +---+---+ +--+-+--+
¦ ¦ +------------+ ¦ ¦ ¦
+--+ +-----+ ¦ +----+ +--+ +-----+
+---+---+ +---+---++---+---+ +---+---+ +---+---+ +---+---+
¦ D1 ¦ ¦ B1 ¦¦ B3 ¦ ¦ B1 ¦ ¦ B1 ¦ ¦ B2 ¦
+-------+ +--+-+--++-------+ +-------+ +-------+ +-------+
¦ ¦
+--+ +-----+
+---+---+ +---+---+
¦ C1 ¦ ¦ C2 ¦
+-------+ +-------+
Объекты в Directory Tree образуют структуру дерева, а дополнительная информация, связанная с этими объектами, хранится в DIB. В дереве каталогов есть информация трех типов: объекты, атрибуты (или характеристики) этих объектов и значения атрибутов. Каждый объект и его атрибуты в дереве создаются на основе определений и ограничений, заданных в схеме каталога.
Основной частью DIB и Directory Services является схема каталога (Directory Schema). Схема каталога - это набор правил, определяющих характеристики информации по объектам, атрибуты и значения, которые можно добавить в дерево каталогов. Эти правила можно сохранить в специальной части DIB, и копия их хранится на каждом сервере имен. Все серверы имен в сети содержат одну и ту же информацию схемы.
Понимание принципов организации объектов должно помочь вам понять назначения и организацию схемы каталога. Если мы возьмем несколько объектов реального мира и начнем перечислять характеристики каждого, то обнаружим, что некоторые объекты имеют одни и те же характеристики. Одни объекты имеют ручки, другие красные, некоторые закрываются, а некоторые находятся далеко. Если мы соберем и объединим все характеристики в один список, то можем использовать его как справочник по всем выбранным для определения характеристикам. Таким образом, нам не нужно определять каждую карактеристику для каждого объекта отдельно. Ручка есть ручка, независимо от того, какая это ручка - двери, ящика стола или другого объекта.
Если бы мы перечисляли каждую характеристику каждого объекта, это список мог бы получиться слишком сложным и длинным. Некоторые характеристики слишком тривиальны и не подходят для наших целей. Мы хотели бы выбрать характеристики, которые говорят нам, что нужно знать об объектах.
Пусть, например, мы классифицируем объекты как сферы. По определению мы можем потребовать, чтобы сферы описывались характеристиками размера, и чтобы это размер (радиус) представлялся числом. Соотнесем это со схемой каталога. Тогда orb будет классом объекта, размер size - атрибутом, а число number - синтаксисом атрибута. (Иногда в документации Novell атрибуты объекта называются характеристиками. Мы выбрали в этой главе термин "атрибуты", так как в справочном руководстве программиста Directory Schema в качестве типов характеристик и синтаксиса характеристик определяет типы атрибута Attrubute Types и синтаксис атрибута Attrubute Sytaxes.)
Чтобы легче было идентифицировать объекты orb, вы можете определить другие атрибуты. Для каждой сферы orb вы можете отслеживать характеристику конструкции construction. Сфера может быть пустой, твердой или наполненной. Другим атрибутом может быть назначение purpose. Бейсбольный мяч - для игры, стальной шарик - для применения в механизмах (например, в шарикоподшипниках), а планета - для обитания. Вы можете также захотеть знать, кто является владельцем сферы - owner. Мы можем также ввести атрибут, используемый только для целей идентификации и назвать его именем - name. Если требуется, этот список можно продолжить. Пока же мы должны решить, что хотим отслеживать следующие характеристики каждого объекта-сферы:
Radius: расстояние от точки на поверхности объекта до центра объекта. Construction: структурное качество объектов. Purpose: возможное использование объекта. Owner: тот, кто отвечает за этот объект. Name: то, что мы используем для идентификации объекта.
Информацию, которую мы решили отслеживать, можно рассматривать в качестве правил построения информационной базы. Когда мы начинаем идентифицировать объекты как сферы, мы делаем это, задавая для них специальную информацию. Это дает вам представление о том, что представляет собой схема каталога (Directory Schema). Она охватывает правила для построения базы данных - дерева каталогов (Directory Tree).
Кроме определения объекта и правил атрибутов, схема включает в себя правила для построения значений заданных атрибутов. Например, атрибут радиуса сферы можно представить строкой символов ASCII с символами из подмножества "0,1,2,3,4,5,6,7,8,9". Его можно представить в виде двоичного значения или числа символов перед нулевым символом. Здесь можно использовать множество форм. Мы должны специфицировать ту форму, которую будем использовать. В схеме это делается с помощью определений синтаксиса атрибутов.
Схема каталога содержит спецификацию того, какая информация, требуется при идентификации объекта, что является необязательным, и какую форму должна принимать информация.
Определение схемы для каждого объекта включает в себя правила, которые управляют взаимосвязью объектов друг с другом в дереве каталога. Эти правила составляют определение включения. При создании объекта в дереве каталога он может быть подчиненным в дереве только тем объектам, которые находятся в определении включения его объектного класса. Если вернуться к примеру сфер, то мы можем определить объект с именем basketball - баскетбольный мяч. Если объекты класса orb ограничены своим отношением включения и должны подчиняться другим объектам класса room (комната), то можем обнаружить, что объект basketball содержится в объекте с именем closet (стенной шкаф), который представляет собой "маленькую комнату". Либо он обнаруживается в объекте с именем gymnasuim (спортзал), который является большой комнатой. Однако, согласно этому определению, мы не можем получить объект класса orb на футбольном поле, так как поле - это не комната.
Чтобы получить более полное представление об этом дереве, мы может рассмотреть его детальнее и обнаружить, что объект с именем gymnasium имеет родительский объект с именем West_High (название района), который, в свою очередь, имеет родительский объект Smalltown (городок). Полное имя объекта в Directory Services тогда будет иметь вид basketball.gymnasium.West_High.Smalltown. Каждое определение класса объекта включает в себя класс объектов, которые могут быть родительскими для данного объекта. Эта спецификация является определением включения.
Схема каталога задает также, какие атрибуты необходимы при создании объекта данного класса и какие необязательны. Это называется обязательными атрибутами и необязательными атрибутами.
В определении класса объектов вы должны задать, какие атрибуты будут использоваться для наименования объекта. В примере со сферами вы можете потребовать указания для наименования всех сфер владельца и имени. Одну сферу тогда можно идентифицировать как John's baseball (бейсбольный мяч Джона), а другую - как John's earth (Земля Джона).
По различным причинам для заданного объекта вам может потребоваться назначить другое имя (псевдоним). Такие псевдонимы представляют собой объекты, которые могут добавляться к дереву каталога и ссылаться на исходный объект. Эти псевдонимы разыменовываются в объект, псевдонимом которого они являются. Например, на John' earth можно ссылаться по псевдониму объекта с именем world (мир). Взглянув на объект с именем world, вы можете захотеть разыменовать его обратно к исходному объекту с именем John's earth.
Для каждого определенного в схеме атрибута задается синтаксис атрибута. Этот синтаксис может определять форму и тип. Объекты класса room может иметь атрибут с именем dimensions (размеры). Синтаксисом атрибута dimension будет три числа, представляющих высоту, ширину и длину. В данном случае синтаксисом значения являются три числа. Помните, что определение синтаксиса специфицирует тип значений, а не сами фактические значения.
Как мы уже упоминали, возможные взаимосвязи объектов в дереве определяются в схеме определением включения. В схеме определяются также отношение объектных классов друг к другу. Объект может классифицироваться как цветок, цветы классифицируются как растения, которые классифицируются как живые организмы. Схема каталога в этом случае потребовала бы отдельных определений классов для цветов, растений и живых организмов. В заданном определении схемы объекты, созданные как цветы, могли бы наследовать определения растений и живых организмов. Эта линия наследования задается через использование определений суперклассов каждого объектного класса.
Схема каталога должна проектироваться и создаваться до того, как объекты добавляются в дерево каталога. Определенная Novell схема каталога называется базовой схемой. Если базовая схема не полностью отвечает вашим нуждам, вы можете добавить к ней другие определения, используя подходящие функции API Directory Services, которые обсуждаются в данной главе ниже.
DIB может храниться в виде распределенных по сети фрагментов на различных серверных машинах. Схема представляет собой часть DIB, которая хранится на каждом сервере имен. Дерево каталогов Directory Tree - это часть DIB, которую можно разделить на фрагменты, называемые разделами. При создании раздела в качестве места разделения дерева выбирается объект. Это объект становится корнем раздела.
Не путайте корень раздела с корнем [root] дерева каталога. [root] - это имя самого верхнего раздела всего дерева. Каждый раздел - это другая часть дерева, но она может копироваться и храниться в нескольких местах. Это обеспечивает более быстрый доступ и гарантирует, что если один сервер имен выходит из строя, то вы сможете поддерживать доступ к информации дерева каталогов через другой сервер имен.
Разделы могут иметь три вида: основная копия, вспомогательная копия и копия, доступная только по чтению. Каждый из них позволяет выполнять клиентам Directory Services определенные функции. Например, сервер имен с копией, доступной только по чтению, не может использоваться для добавления к дереву новых объектов. Клиент должен связаться с сервером имен с основной или вспомогательной копией и дать запрос на обновление. Вскоре после добавления нового объекта к основной или вспомогательной копии все другие копии также будут обновлены в соответствии с этой новой информацией. Этот процесс обновления называется синхронизацией службы каталогов - DSS (Directory Services Synchronization).
Служба каталогов Directory Services будет обновлять разделы и синхронизировать данные без какого-либо вмешательства клиента или пользователя. Когда изменение вносится в DIB, то через несколько секунд (в большинстве случаев) это изменение отражается во всех копиях.
Вы можете получить доступ к серверам NetWare 4.0, используя предыдущие оболочки клиентных рабочих станций или использовать новую оболочку NetWare 4.0, которая называется реквестором. Лучший способ получить доступ к DIB с клиентной рабочей станции состоит в использовании реквестора NetWare 4.0. NLM становятся клиентами и получают доступ к Directory Services с помощью библиотеки DSAPI.NLM. Рабочая станция становится клиентом путем загрузки реквестора NetWare 4.0 и использования библиотеки интерфейса Си (CLIB). Спецификации функций API в DSAPI.NLM и в библиотеки интерфейса Си совпадают. И это неплохо, потому что один и тот же программный код на языке Си (с минимальными изменениями) можно скомпилировать в файл EXE для работы на вашей рабочей станции или в NLM для работы на сервере.
Клиент Directory Services по определению представляет собой рабочую станцию или NLM, имеющий доступ к DIB и способный давать запросы Directory Services. Чтобы стать клиентом службы, отличной от Directory Services, вы должны пройти проверку полномочий доступа к данным средствам. Контроль доступа Access Control - это одно из средств, предусмотренных в Directory Services, но оно используется для облегчения отслеживания и контроля доступа к другим сетевым средствам.
При работе в NetWare 4.0 существует три аспекта защиты: доступ к DIB, защита с помощью пароля и защита файловой системы. Защита файловой системы не является частью службы каталогов Directory Services, поэтому в данной главе мы ее обсуждать не будет.
Защита доступа к DIB определяет, кто может обращаться к информации каталога, и в какой степени он может влиять на данные. Ваша возможность добавлять объекты, считывать их и т.д. зависит от предоставленных вам полномочий (привилегий). Вы можете обращаться к таким типам данных как объекты, атрибуты и значения.
Тем, кто уже работал с базой объектов Bindery, полномочия доступа могут быть знакомы. Bindery имеет пять уровней защиты: Attached, Logged in, Object, Supervisor и Bindery. Эти уровни реализуют полезную и простую системы защиты Bindery.
Защита доступа DIB служит тем же целям, но она гораздо более гибкая и ориентированная на объекты, чем защита, реализованная для Bindery. Она значительно более мощная и позволяет вам управлять доступом практически любым нужным вам способом. Если вы знакомы с тем, как в NetWare 4.0 реализована защита файловой системы, вам не следует беспокоиться об изучении наследования полномочий доступа к DIB. Нужно только не забывать о разделении двух типов защиты. Защита каталога предназначена для ограничения доступа к каталогу, а защита файловой системы - для ограничения доступа к файлам.
Bindery организует доступ по уровням защиты. Неважно, к какому объекты вы пытаетесь обратиться, важно только, что этот объект имеет определенный уровень защиты. Защита Bindery достаточно эффективна, но она не такая гибкая как защита DIB. С помощью каталога отдельной группе пользователей можно предоставить полномочия доступа к объектам, отдельным атрибутам объекта или всем атрибутам.
Полномочия доступа DIB, допускающие обращение к объектам, отличны от тек, которые допускают обращение к атрибутам. Для объектов это следующие полномочия:
Просмотр (Browse)
Добавление (Add)
Удаление (Delete)
Переименование (Rename)
Супервизор (Supervisor)
а для атрибутов:
Сравнение (Compare)
Чтение (Read)
Запись (Write)
Сам (Self)
Супервизор (Supervisor)
Есть четыре способа получить любое из этих полномочий или их все: с помощью прямого назначения, путем наследования от родителей в дереве, из эквивалентных присваиваний полномочий и по членству в группе (Group Membership). Существует процесс фильтрации, который применяется к каждому из этих типов назначений для конкретного объекта. Давайте познакомимся с каждым из них поближе.
Назовем в нашем обсуждении те объекты, которым присваиваются полномочия доступа, субъектами. Субъект - это то, чему (или кому) дается право на действие, и часто это объект пользователя, объект сервера или объект группы, однако этом может быть любой объект в дереве. Целью является то, над чем этот субъект выполняет действия. Целью может быть заданный объект, конкретный атрибут объекта или все его атрибуты. Полномочия доступа назначаются с помощью атрибута целевого объекта, который называется списком управления доступом - ACL (Access Control List). ACL содержит список назначений полномочий доступа.
Прямое присваивание полномочий происходит, когда субъект специфицированный по имени и цели, идентифицируется явным образом. Эти прямые присваивания записываются в списки ACL. Прямое присваивание полномочий заменяет другие полномочия, которые могут наследоваться или получаться в противном случае. Если вы хотите быть уверенными, что субъект имеет определенные права, то можете назначить их с помощью прямого присваивания полномочий, которые требуются в ACL того объекта, к которому требуется обращаться. Не включенные в эти присваивания полномочия не разрешаются (блокируются).
Полномочия наследуются на основе структуры дерева каталога. Подчиненные объекты наследуют привилегии, которые даны их родительским объектам. На основе их взаимосвязей в древовидной структуре они используют полномочия, предоставленные родительским объектам (независимо от того, насколько удаленными они являются). Предположим, например, что подчиненными объектами в дереве объектов Novell являются Olga и Julia. Если мы предоставляем полномочия Novell, то Olga и Julia также будут иметь эти полномочия. Как это работает, показано на Рис. 3.2.
+----------------+
¦ Popurri ¦
+-----+-----+----+
+-----------+ +----------+
+--------+-------+ +--------+-------+
¦ Researching ¦ ¦ Marketing ¦
+--------+-------+ +-----+-----+----+
+-------+ +-----------+ +---+
+--------+-------+ +--------+-------+ +--------+-------+
¦ Olga ¦ ¦ Julia ¦ ¦ Kirill ¦
+----------------+ +----------------+ +----------------+
Access Control List =
права чтения Popurri
Olga и Kirill могут считывать атрибуты Julia
Некоторые типы объектов имеют атрибут равной защиты, который указывает, что в смысле полномочий доступа один объект равен другому (или другим). Таким образом, объект получит все назначения полномочий, присвоенный тому объекту, к которому он приравнен. Аналогично, объект получает все полномочия той группы, членом которой он является. Если объект Dina равен по защите объекту Lina, которому присвоены полномочия на Printserver, Dina имеет на Printserver те же полномочия, что и Lina.
Присваивание всех этих полномочий различным субъектам выполняется не только алгоритмом вычисления полномочий для данной цели. При отсутствии некоторого метода присваивания полномочий по умолчанию каждому объекту в дереве потребовались бы иметь конкретные присваивания для каждого намеченного объекта. Вместо явных присваиваний для каждого объекта в дереве лучше полагаться на привилегии, присвоенные выше по дереву и допустить избирательное их ограничение.
Процесс ограничения полномочий, присвоенный в дереве на более высоком уровне называется маскированием и реализуется через специальную запись в ACL - маску наследования (IM). Каждому объекту можно IM, которая будет использоваться в вычислении действующих полномочий. IM действует как фильтр, предотвращая назначения выбранных привилегий объекту на более низком уровне в дереве. Субъект может иметь полномочия доступа к заданной цели, даже если ему для этого не присвоены явные полномочия. Если субъекту даются полномочия доступа к объекту, который является родительским для целевого объекта, то субъект будет иметь те же полномочия доступа к цели, если фильтры IM не запрещают некоторые из них. При фильтрации будет разрешен установленный флаг полномочий IM.
Метод присваивания полномочий доступа предусматривает указание имени защищенного атрибута и предоставляемых полномочий. Эти три элемента образуют запись в списке ACL. Записи в ACL объекта ограничивают доступ к этому объекту и атрибутам этого объекта и подчиненных объектов.
Именем защищенного атрибута должно быть конкретное имя атрибута или [Entry Rights], [All Attributes Rights], либо [SMS Rights]. Если используется [Entry Rights], то полномочия будут влиять на объект и все подчиненные ему объекты. Если используется [All Attributes Rights], то полномочия влияют на все атрибуты объекта и атрибуты подчиненных ему объектов. При использовании [CMS Rights] полномочия влияют на объект, все атрибуты объекта, а также на подчиненные объекты и атрибуты подчиненных объектов. Если используется имя конкретного атрибута, то затрагивается конкретный атрибут.
Записи ACL можно использовать для ограничения тех полномочий, которые могут наследоваться. Это делается с помощью задания в качестве имени субъекта маски наследования [Inheritance Mask]. В качестве имени субъекта могут использоваться и другие значения. Эти значения применяют полномочия к определенным объектам, но не именуют объекты конкретно. Возможные значения: [Public] - для всех объектов, [Root] - для корня дерева каталога, [Creator] для создателя объекта и [Self] - для самого объекта. После создания объекта полномочия [Creator] и [Self] вы присваивать не можете. Эти назначения возможны только при добавлении объекта к дереву каталога.
К счастью, пошаговый процесс определения действующих полномочий для данного субъекта может выполняться службой каталога. Если вам нужно знать какие у вас действующие права, вы можете использовать функцию API NWDSGetEffectiveRights для получения прав уровня объекта и NWDSListAttrsEffectiveRights для получения действующих полномочий для всех атрибутов объекта.
Обеспечение надежной защиты пароля - не всегда легкая задача. NetWare 4.0 реализует средства защиты пароля, помогающие защититься от запросов и подключений злоумышленника.
Чтобы обеспечить защиту пароля, NetWare использует кодирование RSA с ключевой парой (личный и общий ключ). Это означает, что каждый пользовательский объект, найденный в дереве каталога, имеет личный и общий ключ, которые используются для кодирования и декодирования данных с проверкой подлинности. Такой метод применяется для проверки подлинности сообщений, передаваемых между клиентом и сервером. Для создания ключевой пары используется ваш пароль. Следовательно, без пароля проверка пользователя невозможна.
Единственный случай, когда пароль действительно передается по сетевому кабелю, это смена пароля. Но даже в этом случае пароль имеет кодированный вид. Пароль используется в алгоритме кодирования вашей ключевой пары и проверки подлинности данных. Если вы меняете пароль, то ваша ключевая пара изменяется, и данные переопределяются с новыми ключами, но принцип ключевой пары сохраняется.
Если вы чувствуете, что ваша пользовательская защита недостаточна, можно пойти еще дальше, чем простое изменение пароля. Вы можете сменить также ключевую пару. Это делается с помощью функции NWDSGenerateObjectKeyPair. К моменту написания данной книги полномочия на генерацию новой ключевой пары определялись вашей возможностью модифицировать общий и личный ключевые атрибуты объекта, для которого вы хотите задать новую ключевую пару.
Вы можете также потребовать канонизации имен. Канонизация это процесс расширения частичного имени в полное. Полное имя формируется на основе указанного частичного имени и контекстного имени, заданного при создании контекста. Если канонизация не действует, то указываемые имена будут рассматриваться как полные имена.
Например, CN=Olga.OU=Researching.O=Alpha - это полное имя с заданными типами. Olga - это безтиповое сокращенное имя того же объекта, если контекстом является OU=Researching.O=Alpha. Если задается канонизация, и имя контекста устанавливается в OU=Researching.O=Alpha, то при спецификации объекта можно использовать Olga. По умолчанию такие сокращения разрешаются. Они задаются с помощью флага DCV_CANONICALIZE_NAMES.
Не путайте сокращения канонических имен с использование кратких форм объектных типов. Common Name - это имя атрибута с краткой формой CN. Независимо от установок флагов, вместо Common Name вы всегда можете использовать CN. Если вы выберите полный тип спецификации имен, таких как Common Name, то следует убедиться в действии канонизации. Это связано с тем, что Directory Server при работе с полными именами использует краткую форму имени атрибута (такую как CN). Маршрут кода для выполнения канонизации - это маршрут кода, преобразующий длинные имена атрибутов в их краткую форму. Если длинные имена атрибутов, такие как Common Name, не конвертируются в краткую форму (в данном случае CN), то Directory Server не будет знать, как обрабатывать полное имя.
Если используется сокращенное имя, такое как Olga, и выполняется канонизация, то при расширении имени до полной формы соблюдаются определенные правила. Используемые по умолчанию правила для типизации объектов в полную именную форму, когда не задаются имена атрибутов, имеют следующий вид:
Если типы специфицируются, то данные используемые по умолчанию правила не применяются. Каноническое имя, такое как Olga.Researching.Aplha, может быть безтиповым, а используемые по умолчанию правила типизации применяются, если задан флаг контекста для безтиповых имен.
Существуют и другие пути влияния на способ построения полного имени, но знание данных правил типизации и построения будут отвечать практически всем вашим потребностям. Более подробные детали в этой области вы можете найти в комплекте документации для разработчика NLM.
Флаг конфиденциальности указывает вид копии каталога, который требуется при выполнении запроса к Directory Services. Вы можете задать высокий и низкий уровень конфиденциальности. Высокий уровень указывает, что возвращаемая в ответ на запрос информация должна извлекаться из основной копии, а не вспомогательной копии, доступной только по чтению. По умолчанию задается низкий уровень конфиденциальности, что позволяет получать ответы из копий соответствующего типа. Запросы на чтение могут обрабатываться копиями, доступными только по чтению, запросы на добавление требуют вспомогательной или основной копии и т.д.
Возможность доступа к объектам базы данных DIB (Directory Information Base) и ее атрибутам непосредственно зависит от полномочий, предоставленных каждому конкретному объекту. Для реализации и изменения средств защиты, достаточных для стоящей перед вами задачи, можно использовать Directory Access Services.
Служба каталогов Directory Services предлагает детально разработанные и специализированные средства защиты доступа. Любому объекту можно предоставить конкретные полномочия на доступ к любому другому объекту или атрибуту. Это делается с помощью атрибута ACL (Access Control List).
Иметь атрибут ACL может каждый объект. Значения этого атрибута определяют полномочия, которые имеют над этим объектам другие объекты. ACL содержит не только назначения полномочий, но также маски и в отдельных обстоятельствах ограничения полномочий.
Кроме присваивания полномочий непосредственно объекту, вы можете присваивать их с помощью эквивалентности защиты (Sequrity Equals) и назначений через членство в группе (Group Membership). Атрибуты ACL, Group Membarship и Security Equals. Если полномочия объектам в ACL не присваиваются, то полномочия доступа определяются путем наследования.
Ранее мы уже упоминали, что субъект - это объект, которому присвоены полномочия доступа к целевому объекту или атрибутам. Субъект, которому предоставлены полномочия просмотра, при выполнении функций перечисления и поиска может видеть целевой объект. Если просмотр данного целевого объекта для этого субъекта ограничен, то этот субъект не сможет видеть объект в списке, выполнять его поиск или использовать для него функции сравнения, даже если он может видеть все другие объекты в данной части дерева каталога. Чтобы видеть атрибуты, субъект должен иметь также привилегии Compare (сравнение) или Read (чтение). Чтобы считывать значения атрибутов, субъект должен иметь привилегии Read.
Полномочия Add (добавление) разрешает добавление подчиненных объектов.
Полномочия Delete (удаление) позволяют субъекту удалять сам объект.
Полномочия Rename (переименования) позволяет субъекту переименовыватьобъект.
Назначение Supervisor разрешает все полномочия доступа к объекту и его атрибутам.
Как можно ожидать, полномочия Supervisor не фильтруются маской наследования (IM). Фактически, маска наследования может использовать для фильтрации любого из указанных полномочий, исключая полномочия доступа Supervisor. Таким образом, если вы хотите предоставить объекту исключительный доступ к целевому объекту, вам следует отфильтровать все полномочия с помощью маски наследования и присвоить полномочия нужному объекту явным образом.
Интересным моментом во всей этой системы защиты является то, что сам список ACL является атрибутом. Это означает, что вы можете предоставить полномочия, позволяющие объектам изменять ACL. Объекты с такими полномочиями могут изменять ACL и ограничивать доступ к другим объектам. Поэтому предоставлять объекту полномочия Write на атрибут ACL нужно осторожно.
Сейчас это может уже быть достаточно очевидным, но пока об этом нигде не говорилось: способ задания для одного объекта защиты, эквивалентной другому объекту, и включение объекта в члены группы очень похоже на присваивание полномочий с помощью ACL. Так как эквивалентность защиты и членство в группе реализуется с помощью атрибутов, для получения нужного результата требуется только изменить соответствующий атрибут.
При изменении членства в группе нужно учитывать еще один момент. Список групп, членом которых объект является, и список членов группы - это разные списки. Оба списка должны обновляться приложением. Членство в группе (Group Membership) представляет собой атрибут объекта пользователя и содержит идентификацию групп, членом которых является пользователь. Атрибут член группы (Member) - это атрибут объекта группы, который содержит идентификацию объектов, являющихся членами группы.
В итоге, в дереве каталога полномочия доступа вы можете получить:
В какой-то момент может потребоваться сменить пароль. Возможно, вы являетесь администратором и не хотите, чтобы пользователь об этом знал. Возможно вы работаете с сервером в особом режиме, и каждый раз, когда вы действуете от имени клиента, то изменяете свой объект пользователя. Либо вам требуется просто написать собственную утилиты консоли, работающую в режиме командной строки и служащую для изменения паролей пользователей.
Смену кем-либо пароля предотвращает тот факт, что он не знает ваш текущий пароль, а полномочия доступа можно использовать для того, чтобы ваш объект не могли просматривать. Если не будет указан старый пароль, с помощью вызова функции NWDSChangeObjectPassword изменить пароль нельзя. Однако, пароль можно сменить другим способом. Изменение ключевой пары меняет пароль и не требует знания существующего пароля.
DIB (Directory Information Base) - это мощная база данных, централизующая операции в сети Novell. Она обладает встроенной гибкостью, облегчающей организацию и поддержку доступа пользователей и защиту. Разделы могут помочь вам улучшить эффективность и надежность вашей DIB путем размещения их на серверах ближе к пользователям, которые к ним обращаются, и создания копий, хранимых на разных машинах.
NDS (NetWare Directory Services) - это появившаяся в NetWare 4.0 служба каталогов, которая значительно облегчает доступ пользователя к сети. Directory Services включает в себя службы, предусмотренные для хранения и отслеживания всех объектов в сети. Вместе с Directory Services поставляется база данных DIB (Directory Information Base. DIB - это база данных, используемая для хранения информации о серверах и службах, а также пользователях, принтерах, шлюзах и др.
DIB представляет собой распределенную базу данных. Независимо от того, где хранятся данные, доступ к ним можно получить из любого места сети. Directory Services - это та часть NetWare, которая отслеживает эти данных и позволяет с ними взаимодействовать. Чтобы они могли работать, все серверы NetWare 4.0 должны иметь загруженное средство Directory Services. Это превращает каждый сервер NetWare 4.0 в сервер каталога. Поскольку он обслуживает именованные объекты каталога, NetWare-сервер называют иногда также сервером имен. Часто "сервер" означает машину, которой посылается запрос. Если вы запрашиваете средства NDS, то сервер означает сервер каталога. Если вы запрашиваете файловые средства, то сервер означает файловый сервер и т.д.
Вы можете подумать, что в версиях, предшествующих NetWare 4.0, уже предусматривались те же данные, которые можно найти в DIB. Во многом это соответствует истине. Такой вид информации традиционно хранился в NetWare Bindery. Для чего же потребовался переход на DIB? Ведь назначение Bindery совпадает с назначением Directory Services.
Различия заключаются в том, что DIB - это распределенная база данных, которую можно разбивать на несколько частей. Она обеспечивает более гибкий доступ и более специализированную защиту. Вместо простой файловой структуры DIB использует объектно-ориентированную структуру. Кроме того, в то время как доступ к базе объектов Bindery ориентирован на сервер, для доступа к DIB можно использовать всю сеть. Информация в Bindery на серверах относится в основном к самому серверу. Серверы с информацией DIB хранят данные о всей сети.
В мире развивающейся технологии очень важное значение имеет поддержание совместимости с предыдущими версиями продуктов. Поскольку технология Bindery будет продолжать использоваться еще достаточно долгое время, нужен, конечно, способ взаимодействия серверов с Bindery с серверами DIB и наоборот.
Независимыми разработчиками уже написаны некоторые программы и средства, обращающиеся к Bindery. Если бы NetWare 4.0 не имела в Directory Services средств эмуляции Bindery, они не смогли бы там работать. Основываясь на контексте Bindery для целевых серверов NetWare 4.0, эта эмуляция может быть активной или неактивной. (Эта тема обсуждается в инструкциях по установке NetWare 4.0). Не путайте контекст объекта (каким является контекст объекта Bindery) с контекстом нити (о котором мы говорили выше). Это два совершенно разных контекста.
При разрешении эмуляции Bindery служба каталогов NDS воспринимает запрос Bindery и отвечает на него таким же образом, как если бы на опрашиваемом NetWare-сервере был Bindery. Однако фактически информация, получаемая по запросу Bindery, может на сервере отсутствовать. Вспомните о том, что Directory - это разбитая на разделы и распределенная база данных. Даже если не сервере NetWare 4.0 не работает Bindery, приложение, давшее запрос Bindery, разницы не почувствует.
В новых программах следует использовать NDS. Хотя объекты в существующих базах Bindery и доступны черед NDS, но лучше обращаться непосредственно к NDS (к Directory).
В данной главе вы познакомились с тем, что представляет собой схема каталога, и как она используется. Здесь поясняется работа с разделами, так что вы должны получить хорошее представление об их природе и важности.
Познакомившись со средствами защиты и управления доступом к DIB, вы можете более смело применять эти средства в своих NLM-приложениях. Для программистов предусмотрен полный набор API, облегчающий программирование службы каталогов NetWare 4.0.
Здесь поясняется, что такое контекст каталога. Это позволяет понять, почему так важно уметь с ним работать. Мы рассказали о том, как можно обращаться к DIB и управлять ей. Это включает в себя применение к объекту защиты и уровней атрибутов, а также задание эквивалентов защиты. Описываются методы и требования доступа к схеме.
В этой главе мы познакомили вас с наиболее ценным для изучения инструментальным средством. Использование программы DSSCRIPT существенно поможет вам в совершенствовании своих навыков программирования с использованием службы каталога NetWare 4.0.