Одного каталога недостаточно

Управление идентификацией и службы каталогов.

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

Службы каталогов приобрели популярность после того, как Novell добрых десять лет назад представила первую версию NetWare Directory Services (NDS). Впрочем, начало истории каталогов было положено намного раньше — с появлением X.500, с одной стороны, и «Желтых страниц» — с другой. Когда Microsoft в конце 90-х гг. выпустила на рынок свою Active Directory, споры вспыхнули с новой силой. Чаще всего обсуждалось, что следует предпочесть пользователям — NDS от Novell, известную также под названием eDirectory, или Active Directory от Microsoft. Однако с сегодняшней точки зрения такая постановка вопроса учитывает только одну часть проблематики, потому что касается в основном инфраструктуры каталогов для сетевых операционных систем.

МНОЖЕСТВО КАТАЛОГОВ

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

Рисунок 1. Классификация различных типов каталогов на предприятии.

Вторую группу представляют каталоги приложений, используемые специфическими приложениями; к их числу принадлежат Domino Directory, а также SAP User Management. Но в эту же группу могут быть отнесены и приложения кадрового учета (Human Resources, HR), и управляемая ими информация. Кроме того, на большинстве предприятий имеется множество собственных разработок с отдельным управлением пользователями, из-за чего сегмент каталогов приложений оказывается чрезвычайно гетерогенным.

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

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

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

РАЗЛИЧНЫЕ ТРЕБОВАНИЯ

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

Наибольший объем функций должны обеспечивать сетевые каталоги, участвующие в решении разнообразных задач, вплоть до конфигурации клиента. Но и в области аутентификации требования достаточно высоки. Так, Active Directory предоставляет объекты групповой политики (Group Policy Object, GPO) для конфигурации клиента, а также поддержки Kerberos. В eDirectory от Novell может храниться информация от ZENworks, а Novell Modular Authentication Services (NMAS) дополняют эту систему модульной аутентификацией. Часто служба каталогов используется другими приложениями, например Microsoft Exchange Server и ISA Server в случае Active Directory или Novell GroupWise и BorderManager в случае eDirectory, поэтому в каталогах находится множество специфических для приложений данных. В таком случае схемы соответственно усложняются.

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

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

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

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

ОДНОГО КАТАЛОГА СЛИШКОМ МАЛО — НО ДОСТАТОЧНО ЛИ ОДНОГО ПРОДУКТА?

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

Даже если большого количества экземпляров избежать нельзя, то рано или поздно встает вопрос о возможности их создания с помощью службы каталогов одного и того же производителя. Только Novell и Microsoft в полной мере охватывают область сетевых каталогов, поэтому речь может идти лишь о eDirectory или Active Directory. Но Microsoft не без причин представила недавно Active Directory in Application Mode (ADAM) как облегченный вариант Active Directory (см. врезку «Microsoft сотворила ADAM»). ADAM не поддерживает Kerberos, функции управления клиентами, а также некоторые другие службы, что позволяет использовать этот продукт — в урезанном виде — более эффективно, как каталог приложений. Novell eDirectory также предлагает определенную гибкость для поддержки различных областей применения. Но на рынке имеются и такие продукты, как Sun Directory Server или Siemens Dirx, причем они специально нацелены на удовлетворение требований к нагрузке со стороны корпоративных справочников и каталогов электронного бизнеса.

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

СТОЛЬКО, СКОЛЬКО НУЖНО — И КАК МОЖНО МЕНЬШЕ

На первый взгляд при выборе каталогов для предприятия представляется вполне реальной возможность приобретения одного продукта и его максимального использования в качестве стандартного. Но уже Active Directory и ADAM являются фактически двумя различными продуктами. До сих пор не ясно, имеет ли смысл так жестко придерживаться одного направления. В большинстве случаев рекомендуется сохранить открытость, чтобы, например, иметь возможность выбора корпоративных справочников или каталогов электронного бизнеса с особенно высокими требованиями к нагрузке. Впрочем, и этот ассортимент надо ограничить. Только так администраторы и интеграция могут оставаться под контролем. В конце концов, всегда проще интегрировать два экземпляра каталогов на базе одной и той же технологии, чем те, которые основаны на различных продуктах с неизбежными различиями в реализации (см. Рисунок 2).

Рисунок 2. Microsoft ADAM — это «облегченный» вариант Active Directory. Интеграция между различными объектами ADAM и Active Directory может, например, осуществляться с помощью MIIS 2003 или Identity Integration Feature Pack.

ОСНОВНЫЕ ИГРОКИ

Некоторые из ведущих поставщиков каталогов уже были названы: Microsoft, Novell, Sun и Siemens давно обосновались в различных сегментах рынка, причем Siemens имеет опыт успешных масштабных внедрений для поддержки электронного правительства. Наряду с этими именами следует назвать и IBM, где очень серьезно относятся ко всему, что касается управления идентификацией. В некоторых нишах так же активно, как и Oracle с ее Oracle Internet Directory (OID) — последняя служит каталогом для приложений Oracle, работает компания Critical Path. Кроме того, как пример реализации с открытыми кодами следует назвать OpenLDAP.

КОНТРОЛЬ НАД НЕСКОЛЬКИМИ КАТАЛОГАМИ

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

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

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

Мартин Куппингер — независимый автор. С ним можно связаться по адресу: redaktion@Lanline.awi.de.

Microsoft сотворила ADAM

В середине 2003 г. Microsoft выпустила на рынок Active Directory in Application Mode (ADAM), бесплатное дополнение к Windows Server 2003. За основу взята технология Active Directory — в ней используются, например, те же самые механизмы тиражирования. Однако многие функции отсутствуют, включая поддержку групповых политик и Kerberos. Это сделано для снижения непроизводительных затрат с целью создания эффективного каталога приложений.

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

Хотя ADAM имеет ту же базовую технологию, что и Active Directory, это не означает, что возможно общее управление ADAM и Active Directory. По крайней мере, в последней из имеющихся версий все еще почти полностью отсутствуют графические инструменты администрирования. Администраторы вынуждены прибегать к сложным утилитам. В частности, работу с запросами LDAP помогает организовать такой инструмент, как ldp.exe.

Если необходимо даже частичное согласование информации в экземплярах ADAM и Active Directory, то без технологий мета-каталога не обойтись. Такое согласование понадобится уже в процессе применения Active Directory для аутентификации пользователей, однако ADAM содержит дополнительные сведения о пользовательских объектах. Identity Integration Feature Pack компании Microsoft является базовой версией Microsoft Identity Integration Server 2003 (MIIS) и одновременно «бесплатным» дополнением к Windows Server 2003. Впрочем, в качестве хранилища данных нужен еще и Microsoft SQL Server, который позволит синхронизировать информацию в экземплярах ADAM и Active Directory. И последнее: нельзя недооценивать затраты на реализацию Identity Integration Feature Pack, ведь речь идет об исключительно сложном продукте.

? AWi Verlag