Настройка службы каталогов Active Directory Lightweight Directory Service (часть 2)

В первой части этого цикла статей мы рассматривали службу каталогов Active Directory Lightweight Directory Service (AD LDS) и сферу ее использования. В этой части мы рассмотрим планирование и установку службы AD LDS.

Процесс планирования

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

Так что же Microsoft говорит здесь? Думаю, что в общих чертах вышеуказанное предложение можно интерпретировать следующим образом:

Для развертывания AD LDS необходим только тот сервер, который может работать под управлением Windows Server 2008. Однако в зависимости от того, как AD LDS будет использоваться, серверу, возможно, придется быть достаточно мощным для обработки значительных рабочих нагрузок. По этой причине необходимо провести замеры в обеспечение того, что аппаратное оборудование вашего сервера соответствует требованиям.

Если это утверждение верно, то наиболее логичным подходом к планированию AD LDS будет рассмотрение типов ресурсов, потребляемых AD LDS, и базирование всех работ по планированию мощностей с учетом таких типов потребляемых ресурсов.

Учитывая это, создается впечатление, что компания Microsoft не предоставляет достаточно четких рекомендаций к планированию мощностей AD LDS, я склоняюсь ко мнению о том, что одним из лучших подходов к этому является восприятие процесса планирования мощностей так же, как вы относитесь к процессу планирования мощностей для контроллеров домена. В конце концов, сервер AD LDS очень схож с сервером контроллеров домена. Серверы AD LDS, как и контроллеры домена, являются очень идентичными службами каталогов. Конечно, в них есть отличия, которые следует учитывать. При планировании объемов Active Directory обычно во внимание принимается количество пользователей, в то время как при планировании AD LDS большее внимание уделяется предполагаемому количеству LDAP запросов, которые будут поступать на сервер. Однако, планирование объемов Active Directory, равно как и AD LDS часто требует принятия во внимание таких вещей, как топология и репликация.

Различия между контроллерами доменов и AD LDS серверами

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

Одним таким отличием является то, что AD LDS не использует концепцию лесов, в отличие от Windows Active Directory. В среде Active Directory лес представляет собой собрание доменов. Каждый лес является абсолютно независимым, хотя леса можно объединять, используя федеративные отношения доверия.

AD LDS не использует концепцию лесов и доменов в отличие от контроллеров доменов Windows. Вместо этого, основным структурным элементом, используемым в AD LDS, является экземпляр службы (часто называемый в Microsoft экземпляром). Экземпляр означает один AD LDS раздел. Каждый экземпляр имеет свое индивидуальное название службы, хранилище данных каталогов и описание службы.

Вы, наверняка, уже знаете, что контроллер домена Windows может обслуживать только один домен. В отличие от него, один сервер на базе AD LDS может принимать несколько экземпляров. Это означает, что один AD LDS сервер может содержать несколько каталогов.

Конечно, в этой связи возникает интересный вопрос. В среде Active Directory клиенты взаимодействуют с контроллерами домена посредством протокола Lightweight Directory Access Protocol (LDAP). Как и большинство других протоколов, LDAP предназначен для использования определенных номеров портов. Например, LDAP обычно использует порт 389 для запросов каталогов. Если LDAP взаимодействия нужно зашифровать, то используется порт 636. Контроллеры доменов, функционирующие в роли серверов глобальных каталогов, используют порты 3268 и 3269 для операций, связанных с глобальными каталогами. Учитывая все вышесказанное, вам, возможно интересно, какие порты использует AD LDS.

Поскольку AD LDS не стоит заботиться о выполнении каких-либо функций глобальных каталогов, мы можем исключить использование портов 3268 и 3269 сразу. Однако AD LDS все же использует порты 389 и 636 таким же образом, как и контроллеры домена.

Так что же произойдет, если сервер содержит несколько AD LDS экземпляров? Обычно, первому создаваемому экземпляру будут назначены порты 389 и 636. Когда создается второй экземпляр, Windows видит, что эти порты уже используются, и начинает сканирование неиспользуемых портов, начиная с порта 50,000. Если предположить, что порт 50,000 доступен, он будет использоваться для стандартных LDAP взаимодействий на втором экземпляре AD LDS. Порт 50,001 будет использоваться для SSL зашифрованных LDAP взаимодействий на втором экземпляре AD LDS.

Если вам нужно создать третий экземпляр AD LDS на сервере, Windows увидит, что порты 389 и 636 заняты, и начнет поиск неиспользуемых портов, начиная с порта 50,000. Так как порты 50,000 и 50,001 уже назначены, третий раздел LDAP займет порты 50,002 и 50,003.

Требования DNS

Еще одним различием между Active Directory и AD LDS является то, что Active Directory полностью зависит от DNS серверов. Без DNS служба Active Directory не сможет функционировать. AD LDS, с другой стороны, не требует DNS.

В некоторых случаях это имеет смысл. Служба Active Directory использует DNS в качестве механизма поддержания иерархии доменов. Однако в AD LDS нет иерархии доменов, поэтому DNS не требуется.

Установка службы каталогов Active Directory Lightweight Directory Service

Установка AD LDS является очень простым процессом. Для этого нужно открыть диспетчер сервера (Server Manager) , затем перейти по ссылке добавления ролей (Add Roles) . После этого Windows запустит мастера добавления ролей Add Roles Wizard. Нажмите Далее (Next) , чтобы пропустить приветственную страницу мастера, и у вас откроется страница, на которой будет отображен список доступных ролей.

Отметьте флажком опцию Active Directory Lightweight Directory Service , как показано на рисунке A.

Рисунок A: Active Directory Lightweight Directory Service.

Нажмите Далее , в результате чего у вас откроется вводная страница, в которой будет разъяснение того, что собой представляет AD LDS и для чего используется. Нажмите Далее , и Windows отобразит сообщение о подтверждении, говорящее о том, что будет установлена роль сервера AD LDS. Нажмите кнопку Установить (Install) , чтобы начать процесс установки.

Весь процесс установки обычно занимает около 30 секунд. После окончания процесса установки роли сервера нажмите кнопку Закрыть (Close) для завершения процесса установки. В отличие от некоторых ролей сервера Windows 2008 роль AD LDS не требует перезагрузки сервера.

Заключение

В этой статье я объяснил некоторые различия между Active Directory и AD LDS. В следующей части этого цикла мы начнем рассматривать основы работы с AD LDS.

Помощь

	Задать вопрос
программы
обучение
экзамены
компьютеры
	ICQ-консультанты
	Skype-консультанты
Общая справка
Как оформить заказ
Тарифы доставки
Способы оплаты
Прайс-лист
Карта сайта

О нас

Интернет-магазин ITShop.ru предлагает широкий спектр услуг информационных технологий и ПО. На протяжении многих лет интернет-магазин предлагает товары и услуги, ориентированные на бизнес-пользователей и специалистов по информационным технологиям. Хорошие отзывы постоянных клиентов и высокий уровень специалистов позволяет получить наивысший результат при совместной работе. Обзор служб Active Directory Lightweight Directory Services

Посетителей: 20813 | Просмотров: 29785 (сегодня 1)

Шрифт:

Используя службы Active Directory облегченного доступа к каталогам Windows Server® 2008 (Active Directory® Lightweight Directory Services, AD LDS), ранее известные как Active Directory Application Mode (ADAM), Вы можете производить развертывание служб каталогов для приложений, ориентированных на работу с каталогами. При этом Вы избавляетесь от необходимости развертывания доменов и лесов, а также использования единой схемы каталога в пределах всего леса.

В этом документе содержатся дополнительные сведения о роли AD LDS сервера Windows Server 2008, о функциональных возможностях службы AD LDS, а также некоторые замечания относительно программного и аппаратного обеспечения, необходимого для ее установки.

Что представляет собой роль AD LDS сервера Windows Server 2008

AD LDS – это служба каталогов, работающая по протоколу LDAP (Lightweight Directory Access Protocol – облегчённый протокол доступа к каталогам) и обеспечивающая гибкую поддержку приложений, ориентированных на работу с каталогами, избавляя Вас от требований, предъявляемых к традиционной службе каталогов Active Directory (Active Directory Domain Services, AD DS). Служба AD LDS включает в себя большинство функциональных возможностей AD DS, однако для ее работы не требуется производить развертывание доменов или использовать контроллеры доменов. Вы можете запускать сразу несколько экземпляров AD LDS на одном компьютере, при этом каждый экземпляр будет использовать свою собственную, независимо управляемую схему.

Служба каталогов Active Directory обеспечивает поддержку как серверов под управлением ОС Microsoft® Windows Server, так и приложений, ориентированных на работу с каталогами. Для каждой серверной операционной системы служба AD DS хранит важную информацию о сетевой инфраструктуре, пользователях и группах, сетевых службах и так далее. В таком режиме работы служба AD DS должна использовать единую схему для всего леса доменов.

С другой стороны, роль AD LDS, установленная на сервере, обеспечивает поддержку служб каталогов специально для приложений, ориентированных на работу с каталогами. Для работы AD LDS не требуется наличия доменов или лесов Active Directory. Тем не менее, в окружениях с развернутыми службами AD DS служба AD LDS может использовать информацию AD DS для проверки подлинности участников безопасности Windows.

Когда следует использовать роль AD LDS

В следующих разделах описаны основные сценарии использования каталогов AD LDS на предприятиях.

Организация хранилища данных корпоративных приложений

AD LDS является полноценным решением для работы с каталогами LDAP на предприятиях. Все корпоративные приложения, ориентированные на работу с каталогами, могут использовать AD LDS в качестве хранилища своих данных.

AD LDS может хранить в локальном каталоге (возможно, на том же самом сервере, на котором установлено приложение) «закрытую» информацию, относящуюся только к определенному приложению, не требуя при этом никакой дополнительной настройки каталога Active Directory на этом сервере. Эта информация хранится в каталоге AD LDS, связанном исключительно с каждым конкретным приложением. Такой подход уменьшает сетевой трафик репликации между контроллерами домена, обслуживающими каталог Active Directory. Тем не менее, при необходимости Вы можете настроить репликацию данных между несколькими экземплярами службы AD LDS.

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

Организация хранилища данных клиентов экстрасети

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

Эти серверы и веб-портал нуждаются в своих собственных хранилищах информации о взаимодействующих с ними объектах. На роль такого хранилища хорошо подходит каталог AD LDS, поскольку он может хранить информацию об объектах, не являющихся участниками безопасности Windows, но способных проходить проверку подлинности на основе атрибутов LDAP. Другими словами, внешние клиенты могут обслуживаться веб-порталом, работающим на любой платформе, тогда как в качестве простого хранилища с доступом по протоколу LDAP используется каталог AD LDS.

Если развернутый в экстрасети веб-портал должен обслуживать внутренние учетные записи службы AD DS, расположенной за корпоративным брандмауэром, Вы все равно можете использовать каталог AD LDS для хранения информации об этих учетных записях. В этом случае данные будут синхронизироваться между внутренней службой AD DS и экземплярами службы AD LDS, развернутыми в экстрасети. Эта схема изображена на следующем рисунке.

Вы также можете развернуть хранилище учетных данных клиентов экстрасети на основе AD LDS совместно со службами федерации Active Directory (Active Directory Federation Services, ADFS). Эта конфигурация позволяет проводить проверку подлинности пользователей с помощью технологии единого входа (Single-sign-on, SSO), когда один набор учетных данных используется сразу в нескольких веб-приложениях в течение сетевого сеанса. Для получения дополнительной информации обратитесь к статье Обзор ADFS на веб-узле Microsoft Windows Server TechCenter.

Консолидация идентификационных данных из нескольких систем

Бывают случаи, когда корпоративное приложение, ориентированное на работу с каталогами, может работать только с одним каталогом LDAP или организационным подразделением (OU), однако должно использовать данные, связанные с пользователями, программами или сетевыми ресурсами Active Directory, находящимися в нескольких лесах, доменах или организационных подразделениях предприятия. Для таких приложений должна быть консолидирована информация об объектах, находящихся в нескольких лесах, доменах и организационных подразделениях Active Directory, а также информация из различных систем, таких как базы данных по сотрудникам, базы данных SAP, телефонные справочники и так далее.

Служба AD LDS представляет собой решение по консолидации идентификационных данных, поскольку с ее помощью Вы можете развернуть централизованный метакаталог. Метакаталоги, такие как Microsoft Identity Integration Server (MIIS) или Microsoft Identity Integration Feature Pack (IIFP), являющийся бесплатной облегченной версией MIIS, обеспечивают для ориентированных на работу с каталогами приложений единую модель представления информации обо всех известных учетных записях корпоративных пользователей, программ и сетевых ресурсов. Это достигается путем объединения информации об учетных записях, синхронизации каталогов, инициализации и деинициализации учетных записей, а также путем синхронизации паролей между службами AD DS и AD LDS. Эта схема изображена на следующем рисунке.

Организация среды разработки приложений для AD DS и AD LDS

Служба AD LDS использует ту же самую модель программирования, и виртуально предоставляет такой же способ администрирования, что и AD DS, поэтому она хорошо подходит для разработчиков, которые подготавливают и тестируют различные приложения, интегрированные с Active Directory. Например, если создаваемое приложение должно использовать схему, отличную от текущей схемы службы Active Directory, разработчик может использовать AD LDS для того, чтобы настроить собственную схему приложения в соответствии с требованиями бизнеса, организации данных и рабочего процесса. При этом конфигурация существующей корпоративной схемы Active Directory остается без изменений. Разработчики приложений могут работать с локальными экземплярами AD LDS на своих рабочих станциях, а затем настраивать приложения на работу со схемой AD DS по мере необходимости.

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

Организация хранилища данных конфигураций для распределенных приложений

У Вас может иметься распределенное приложение, для которого необходимо использовать хранилище данных конфигурации с возможностью обновления и репликации в режиме MultiMaster, что позволяет обслуживать несколько компонентов этого приложения. Таким приложением может являться, например, брандмауэр, осуществляющий доступ к данным сетевого окружения и портов, фильтр нежелательной почты, осуществляющий доступ к спискам адресов электронной почты, или же программа, осуществляющая доступ к корпоративным данным и параметрам политики. Для таких приложений Вы можете развернуть каталог AD LDS в качестве облегченного хранилища данных конфигураций. Эта схема изображена на следующем рисунке.

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

Перенос старых приложений, ориентированных на работу с каталогами

В Вашей организации могут использоваться уже существующие каталоги со стандартом присвоения имен X.500 (O= ,C= ), обслуживающие различные старые приложения. Вы можете захотеть перенести эти каталоги в каталог службы AD DS. В этом случае Вы можете использовать службу AD LDS в качестве промежуточного решения. Вы можете развернуть службу AD LDS для обслуживания и поддержки старых приложений, использующих стандарт присвоения имен X.500, тогда как развернутая на предприятии служба AD DS будет обеспечивать общую инфраструктуру безопасности. Вы можете использовать метакаталог, такой как MIIS, для автоматической синхронизации информации AD DS и AD LDS, что обеспечит полностью согласованный перенос данных. Эта схема изображена на следующем рисунке.

Функциональные возможности роли AD LDS

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

Мастер создания экземпляра AD LDS

Инструменты командной строки для выполнения автоматической установки и автоматического удаления экземпляров AD LDS

Оснастки консоли Microsoft Management Console (MMC) для настройки и управления экземплярами и схемами AD LDS

Специальные инструменты командной строки для управления, заполнения и синхронизации экземпляров AD LDS

Помимо всего вышеперечисленного, Вы также можете использовать многие инструменты Active Directory для администрирования экземпляров AD LDS.

Операционная система Windows Server 2008 включает в себя ряд дополнительных функциональных возможностей AD LDS, перечисленных в следующей таблице.

Создание установочного дистрибутива (Install from Media, IFM)

Эта функциональная возможность позволяет Вам использовать инструменты Ntdsutil.exe или Dsdbutil.exe, позволяющие за один шаг создать установочный дистрибутив экземпляров службы AD LDS.

Аудит изменений AD LDS

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

Эта функциональная возможность также применима к службе AD DS. Для получения дополнительной информации обратитесь к статье AD DS: Аудит (EN).

Интеллектуальный анализ данных с помощью инструмента Database Mounting Tool

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

Примечание:

Эта функциональная возможность также применима к службе AD DS. Для получения дополнительной информации обратитесь к статье AD DS: Database Mounting Tool (EN).

Поддержка оснастки Active Directory – сайты и службы

Эта функциональная возможность позволяет Вам использовать оснастку Active Directory – сайты и службы для управления репликацией между экземплярами служб AD LDS. Для использования этой оснастки Вы должны импортировать классы, перечисленные в файле MS-ADLDS-DisplaySpecifiers.LDF (этот файл необходимо импортировать с помощью мастера Active Directory Lightweight Directory Services Setup Wizard), чтобы расширить схему набора конфигурации, которым Вы хотите управлять. Для подключения к экземпляру службы AD LDS, содержащему набор конфигурации, укажите имя и номер порта сервера, на котором он запущен.

Динамическое предоставление доступа к LDIF-файлам (LDAP Data Interchange Format) во время установки экземпляра AD LDS

Эта функциональная возможность позволяет Вам предоставлять доступ к собственным LDIF-файлам во время установки экземпляра службы AD LDS, размещая их в папке «%systemroot%\ADAM». Эти файлы будут являться дополнением к LDIF-файлам, предоставляемым службой AD LDS по умолчанию.

Рекурсивные запросы с вложенными связями атрибутов

Эта функциональная возможность позволяет Вам создавать LDAP-запросы, формирующие вложенные связи атрибутов, и может оказаться очень полезной при определении членства в группах, а также родительских объектов. Для получения дополнительной информации обратитесь к статье 914828 (EN) базы знаний Microsoft.

Замечания относительно программного и аппаратного обеспечения

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

Примечание:

Для ОС Windows Server 2008, установленной в режиме Server Core, а также для ОС Windows Server 2008 for Itanium-Based Systems доступен ограниченный набор ролей сервера.

Установка роли AD LDS

После завершения установки операционной системы появляется список задач по начальной конфигурации сервера. Для установки роли AD LDS щелкните в списке задач ссылку Add roles, а затем щелкните ссылку Active Directory Lightweight Directory Server.

После того как Вы установите на Вашем сервере роль AD LDS, Вы можете создавать экземпляры службы AD LDS. Для этого в меню Start раскройте папку Administrative Tools и щелкните значок Active Directory Lightweight Directory Services Setup Wizard.

Управление экземплярами AD LDS

Вы можете управлять экземплярами AD LDS с помощью оснастки ADSI Edit. Для этого в меню Start раскройте папку Administrative Tools и щелкните значок ADSI Edit.

Дополнительная информация

Для получения дополнительной информации о службе AD LDS щелкните ссылку AD LDS Help в окне диспетчера управления сервером Server Manager.

Примечание: