Служба Lightweight Directory Service очень полезна в ситуациях, когда приложениям нужен доступ к службе каталогов, но вы не хотите подвергать свою базу данных Active Directory риску взлома. В этой статье мы познакомимся со службой Lightweight Directory Services, ее использованием и возможностями.
Когда компания Microsoft представила Active Directory в Windows 2000, не потребовалось много времени на то, чтобы люди начали понимать, что Active Directory была чем-то большим, чем просто централизованная база данных, и что Active Directory может использоваться для тех целей, для которых они и не предназначалась.
В течение некоторого времени казалось, что практически каждый производитель программного обеспечения создавал свои продукты для интеграции с Active Directory. Многие из таких приложений хранили информацию о своей конфигурации в Active Directory, а некоторые даже действительно воспринимали Active Directory, как альтернативу базе данных SQL и хранили действительные данные приложения в базе данных Active Directory.
Сегодня большинство поставщиков продукции сторонних производителей использует менее инвазивный подход к работе с Active Directory. Многие приложения читают данные Active Directory, но уже гораздо меньше приложений хранит данные в базе Active Directory, как это было несколько лет назад. Хотя я могу лишь делать предположения на этот счет, полагаю, что это как-то связано с тем фактом, что Active Directory стала критическим компонентом сетевой инфраструктуры, и многие администраторы не проявляют особого желания в выполнении расширений схемы без необходимости (а такие расширения требуются практически во всех случаях, когда приложения хранят данные в Active Directory).
Несмотря на то, что поставщики ПО могут и не использовать Active Directory в той степени, как это было ранее, думаю, будет вполне уместным сказать, что Active Directory может быть очень полезна для поддержки различных приложений. Для демонстрации того, что я имею в виду, давайте рассмотрим хотя бы тот факт, что компания Microsoft все еще разрабатывает многие из своих серверных приложений с высокой степенью интеграции с Active Directory. Exchange Server 2007 и Exchange Server 2010 являются примерами таких продуктов, и они разработаны так, что вся информация о конфигурации серверов хранится в базе Active Directory, а не локально на сервере. Преимуществом такого подхода является то, что это позволяет воссоздавать поврежденные серверы сходу.
Допустим, жесткий диск на сервере Exchange 2010, содержащем роль транспортного сервера-концентратора, был поврежден без возможности восстановления. В силу способа хранения сервером Exchange своей информации о настройках в Active Directory вам даже не придется восстанавливать его из резервной копии для исправления проблемы. Вместо этого вы просто сбрасываете учетную запись компьютера для рухнувшего сервера в Active Directory. Затем вы устанавливаете Windows и все применимые пакеты обновления на новый сервер. После этого вы назначаете этому серверу то же имя компьютера, что и у поломавшейся машины, и присоединяете новый сервер к Active Directory. Поскольку вы сбросили учетную запись компьютера в Active Directory, новый сервер сможет ее использовать.
С этого момента устранение проблемы сводится к запуску программы установки сервера Exchange со специальным ключом. Программа установки копирует необходимые исполняемые файлы, а затем настраивает сервер в соответствие с информацией о конфигурации, хранящейся в Active Directory. Новый сервер можно подготовить и запустить менее чем за час без необходимости восстановления с резервной копии.
Я веду к тому, что Active Directory может быть очень полезна для поддержки приложений, но многие производители ПО не желают использовать ее в той мере, в которой использует компания Microsoft, по причинам трудностей, связываемых с расширением схемы Active Directory.
Еще одна причина, почему производители ПО не хранят данные в Active Directory, связана с репликацией Active Directory. Говоря в общем, любые данные, хранящиеся в Active Directory, должны копироваться (реплицироваться) на все контроллеры домена в домене (а, возможно, даже все контроллеры домена в лесу). По этой причине, если бы приложение хранило большие объемы информации в Active Directory, эти данные могли бы воздействовать на скорость нормального процесса репликации – особенно если эти данные быстро и часто меняются.
Несмотря на эти трудности, есть способ воспользоваться преимуществами интеграции с Active Directory без последствий для базы данных Active Directory. Windows Server 2008 и Windows Server 2008 R2 включают службу под названием Active Directory Lightweight Directory Service, или AD LDS. Подобная служба также существует и в Windows Server 2003, но там она называется Active Directory Application Mode (или ADAM).
Если вы не знакомы с AD LDS, то скажу, что она предоставляет вам среду, очень схожую с Active Directory, но полностью от дельную от нее. AD LDS представляет собой отдельную службу, не зависящую от службы каталогов Active Directory Directory Service. На самом деле, установка службы AD LDS распространена в средах, в которых не существует доменов Active Directory.
Отличным примером такой ситуации является Microsoft Exchange Server. Ранее я говорил, что Exchange Server 2007 и 2010 разработаны под хранение информации о своей конфигурации в базе данных Active Directory. Однако здесь есть одно большое исключение.
Exchange Server определяет ряд ролей, диктующих способ настройки сервера Exchange, а также выполняемые им задачи. Все роли сервера, кроме одной, хранят свою информацию о конфигурации в Active Directory.
Роль сервера, не использующая Active Directory, известна под названием транспортного пограничного сервера (Edge Transport Server). Транспортный пограничный сервер располагается в демилитаризованной зоне и предотвращает прямой доступ к остальным ролям сервера Exchange непосредственно из интернета.
Поскольку сервер Edge Transport открыт для разного рода угроз интернета, включение его в домен Active Directory может быть потенциальным риском безопасности. Если кому-то удалось бы скомпрометировать транспортный пограничный сервер, они бы могли использовать его для получения информации о Active Directory.
Чтобы это предотвратить, пограничный транспортный сервер не может быть членом домена, и он не может содержать никаких других ролей сервера Exchange. Но даже в этом случае серверу Edge Transport требуется доступ к минимальному количеству информации Active Directory, чтобы он мог выполнять свою работу. Вместо предоставления серверу прямого доступа к Active Directory компания Microsoft разработала роль сервера Edge Transport так, что он использует AD LDS.
Один из серверов Exchange заднего плана читает необходимую информацию в Active Directory и отправляет эту информацию в раздел AD LDS на сервере Edge Transport. Таким образом, сервер Edge Transport имеет доступ к необходимой информации, но не имеет доступа к Active Directory. Волею случая, сервер Edge Transport также хранит информацию о своей конфигурации в AD LDS разделе, так же как и другие роли сервера Exchange хранят свою информацию в Active Directory.
Заключение
После рассказа о том, что собой представляет AD LDS и для чего используется, я хочу перевести свое внимание на использование этой службы в организации. Во второй части мы начнем разговор о требования к аппаратным средствам и ПО при использовании AD LDS.