В ту пору, когда я еще только начинал экспериментировать с первыми версиями служб каталогов, а было это лет 10 назад, поставщики такого рода изделий именовали их «X.500-подобными». Эта уловка была рассчитана на администраторов старой закваски, для которых протокол X.500 являлся идеальным воплощением службы каталогов. Но написать службу каталогов, соответствующую спецификации X.500, что называется, на 100%, было невозможно, и это обстоятельство стало одной из причин, побудивших разработчиков взяться за создание протокола облегченного доступа к каталогам LDAP (Lightweight Directory Access Protocol). Цель введения этого стандарта состояла в том, чтобы предоставить в распоряжение поставщиков служб каталогов унифицированный и простой в использовании протокол, позволяющий прикладным программам и службам каталогов взаимодействовать друг с другом.
Любопытно проследить путь развития от LDAP до службы Active Directory (AD), поскольку именно LDAP был той вехой, после которой многие представители мира информационных технологий взялись за реализацию служб каталогов. В частности, возникает вопрос: можно ли из всего процесса эволюции служб каталогов извлечь некие уроки, которые помогли бы корпорации Microsoft изменить нынешнее, мягко говоря, настороженное отношение потребителей к службе AD?
Из истории служб каталогов
Построить службу каталогов на базе добротного протокола, обеспечивающего связь и удобный доступ, еще недостаточно для того, чтобы служба получила признание пользователей (хотя, конечно, роль такого протокола весьма велика). Первые службы каталогов не завоевали популярности потому, что пользователи просто еще не имели ясного представления о том, чего же, собственно, следует ожидать от такой службы. Поставщики разъясняли потребителям, что служба каталогов - это что-то вроде телефонного справочника, содержащего исчерпывающие данные о сети. Чтобы получить информацию о любом пользователе и о любой системе, пользователю и администратору достаточно щелкнуть клавишей мыши, а чтобы такие данные стали доступными для любого приложения, достаточно написать простенькую программу. Слыша такие речи, администраторы сетей Banyan VINES лишь ухмылялись и потирали руки, поскольку у них подобные возможности уже были. Правда, прикладных программ для платформы Banyan к тому времени было не так много.
Разработчики компаний Novell и Microsoft стали действовать более избирательно и попытались как-то воздействовать на представления пользователей о том, чего следует ожидать от службы каталогов.
Разработав службу Novell Directory Services (NDS), специалисты Novell сумели обеспечить единую систему регистрации (single sign-on, SSO) для доступа к широкому спектру сетевых ресурсов. Представители Microsoft поняли, что Novell сделала блестящий ход, который позволит сплотить вокруг идеи службы каталогов большинство пользователей, и решили «оснастить» службой каталогов операционную систему Windows NT 4.0. На самом деле никаких добавлений в NT 4.0 сделано не было. Вместо этого разработчики Microsoft внесли изменения в описание доменной системы NT. Точнее говоря, в приложении к комплекту ресурсов Microsoft Windows NT 4.0 Resource Kit они документировали имеющиеся в системе ограниченные средства единой регистрации как службу каталогов.
Но даже если бы Microsoft не сделала ничего, кроме этого, надо признать, что выраженная хотя бы только на словах поддержка службам каталогов позднее сыграла важную роль в «легитимизации» последних, вследствие чего идея таких служб перестала быть достоянием одних только специализирующихся на сетях инженеров и вошла в обиход сетевых администраторов.
Фактор Exchange
Видя успех, выпавший на долю пакета Microsoft Exchange Server, обычные сетевые администраторы обратили внимание на дополнительные возможности, реализованные в службах каталогов. Благодаря способности Exchange генерировать информацию для новой учетной записи пользователя почтового сервера и связывать эту информацию непосредственно с учетной записью пользователя в домене NT, процесс создания учетных записей упростился. Администраторы сетей стали отдавать предпочтение изделиям, наделенным такими функциями, которые присущи приложениям, оснащенным средствами служб каталогов. Администраторам пришлись по вкусу такие типичные для служб каталогов характеристики, как простота использования и развертывания, а также хорошая управляемость. Но сделать эти характеристики стандартными для всех применяемых ими сетевых приложений оказалось непросто.
Дело в том, что реализованный в Exchange каталог не имел никакого отношения к созданию службы каталогов разработчиками Microsoft. Теперь-то, оглядываясь назад, так сказать, с высоты своего опыта, руководители Microsoft утверждают, будто они с самого начала предполагали строить службу AD иначе, нежели каталог Exchange, но я полагаю, что успех пакета Exchange был для них таким же сюрпризом, как и для всех остальных. И, между прочим, этот успех значительно «подрезал крылья» AD хотя бы потому, что возможности Exchange могли бы стать своего рода мостиком к службе AD и средством для ее развертывания, если бы в свое время Microsoft взяла за основу эту службу при разработке пакета Exchange.
Трудная задача
Как известно, Windows 2000 внедряется очень медленными темпами, и в компьютерной прессе постоянно появляются аналитические статьи, авторы которых пытаются объяснить причины этого явления. Так вот, в большинстве подобных статей ничего не говорится о том, что даже в тех подразделениях, которые начали переход на Windows 2000 (а сейчас обеспокоены предстоящей миграцией на Windows 2002), Windows 2000 Server настраивают как автономные серверы существующих доменов NT 4.0. После выхода в свет продуктов семейства .NET Enterprise Server, пользователям приходится разворачивать системы Windows 2000 Server для выполнения многих из этих приложений. И надо сказать, что все равно значительная часть администраторов предпочитает не связываться со службой AD.
Причин тому множество, но о некоторых стоит упомянуть особо. Прежде всего, разумеется, пользователи сомневаются в целесообразности перехода от NT 4.0 к Windows 2000. Подлила масла в огонь преждевременная рекламная кампания, развернутая корпорацией Microsoft вокруг платформы Windows XP (прежнее рабочее название Whistler). На пользователей, готовых было поддаться увлечению серверными продуктами семейства Win-dows 2000, она подействовала как холодный душ. Вторая причина заключается в том, что развертывание AD (как, впрочем, и любой другой службы каталогов) - дело непростое. Тут требуются немалые ресурсы для организации работы в масштабах всей корпорации, поскольку развернуть AD гораздо проще в тех случаях, когда администратор может идти «сверху вниз», охватывая при этом всю организацию. Наконец, Microsoft не извлекла уроков из горького опыта Novell, выпустившей в свое время службу NDS первого поколения. Напомним, что реакция пользователей средств Novell NetWare на появление новой службы была столь же вялой, как и реакция на AD со стороны пользователей сетей NT. В состав средств NDS не были включены простые в использовании графические инструменты, с помощью которых можно было бы модифицировать существующие деревья каталогов. И как только пользователи поняли, что внесение изменений в структуру существующих деревьев сопряжено с огромными трудностями, от их желания развернуть новое приложение не осталось и следа.
Разработка инструментальных средств для управления службой AD - трудная задача. Утилита командной строки Movetree дает представление о богатстве открывающихся возможностей, но работать с ней чрезвычайно сложно. И если специалисты Micro-soft знали, что такое средство необходимо, почему же они не позаботились о подготовке версии с графическим пользовательским интерфейсом? Ведь опытные пользователи знают, сколь важную роль может сыграть хорошая служба каталогов в деле улучшения управления и удержания преимущества в конкурентной борьбе. Но они не станут браться за такой проект, как развертывание службы AD, пока не удостоверятся, что у них имеются все необходимые инструменты для его удачного завершения. При этом совсем не обязательно, чтобы в роли разработчика этих инструментов выступала именно корпорация Microsoft. Главное - пользователи должны быть уверены, что AD будет достаточно надежной и сможет обслуживать используемую ими модель бизнеса. Кроме того, пользователи должны знать, что структура AD - достаточно гибкая, а потому способна обеспечить возможность быстрого изменения тактики ведения бизнеса, если в этом возникает необходимость.
Решение перечисленных вопросов - важная задача для корпорации Microsoft, особенно в свете ее планов по продвижению инфраструктуры .NET, призванной стать основой для организации служб Internet. Технология .NET может успешно функционировать только при наличии мощной и гибкой службы каталогов. И Active Directory еще предстоит доказать, на что она способна.
Дэвид Черников - главный технический редактор и директор тестовой лаборатории Windows 2000 Magazine. Пишет обзоры по компьютерам и продуктам уже более 15 лет, в том числе с 1992 г. и по теме Windows NT. С ним можно связаться по адресу: david@win2000mag.com.