Службы Active Directory облегченного доступа к каталогам
В Windows Server 2008 R2 поставляется не только традиционная версия служб каталогов под названием Active Directory Domain Services (Доменные службы Active Directory), или, сокращенно, AD DS, но и версия, предназначенная специально для определенных приложений и меньших приложений с облегченным доступом. Эта версия служб каталогов называется Active Directory Lightweight Directory Services (Службы Active Directory облегченного доступа к каталогам), или AD LDS.
Поддержка информации и идентификационных данных между такими каталогами в синхронизированном состоянии — задача непростая. По этой причине в состав Windows Server 2008 R2 входит версия служб каталогов Active Directory Federation Services (Службы федерации Active Directory), или AD FS, и средство для синхронизации метакаталога под названием ForeFront Identity Manager (FIM), помогающее при работе с федерациями.
Обзор функциональных возможностей AD LDS
Ниже перечислены основные особенности AD LDS, о которых следует знать, прежде чем устанавливать эту технологию в организации.
Обзор служб Active Directory Lightweight Directory Services
Используя службы 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.
Глава 11. Службы Active Directory — Часть 01
В этой главе мы перемещаемся к третьей части данной книги, которая сосредоточена на ролях сервера Active Directory ( AD ). Имеется пять основных ролей Active Directory:
Active Directory Domain Services (AD DS)
Active Directory Lightweight Directory Services (AD LDS)
Active Directory Federation Services (AD FS)
Active Directory Rights Management Services (AD RMS)
Active Directory Certificate Services (AD CS)
Мы уже рассматривали многие компоненты, свойства и возможности Active Directory, но мы ещё пока не закончили. Службы Active Directory присоединены ко множеству различных компонентов, таких как DNS ( Domain Name System ), DFSR ( Distributed File System Replication ) и Групповые политики. Для сопровождения жизнеспособной среды Active Directory нам требуется управлять каждым из этих компонентов надлежащим образом и быть уверенными что они они делают то что должны. Однако, в некоторых ситуациях профессионалы ИТ и разработчики программного обеспечения интересуются лишь возможностями аутентификации и авторизации Active Directory. Это может быть обусловлено разработкой приложений, миграцией каталога, требованиями аутентификации приложения и прочими причинами. В подобных случаях мы можем применять AD LDS для предоставления служб LDAP ( Lightweight Directory Access Protocol ). Как и предполагает его название, это некая усечённая версия AD DS и она не зависит от многих прочих компонентов. Она также обладает меньшими требованиями к управлению. В данной главе мы более подробно изучим AD LDS.
Не может быть никаких жизнеспособных сред Active Directory без жизнеспособных репликаций Active Directory. Начиная с Windows Server 2008, Microsoft для репликации папки SYSVOL ввела DFS. Она лучше своей предшественницы, File Replication Service ( FRS , Службы репликации файлов), по множеству причин. В данной главе мы изучим различия между FRS и DFSR ( Distributed File System Replication , Репликацией распределённой файловой системы). Помимо технологий репликации, площадки Active Directory также имеют воздействие на репликацию Active Directory. Некая площадка Active Directory это логическое представление другой удалённой сетевой среды, которая обладает Контроллерами доменов и прочими ресурсами. В этой главе мы изучим площадки Active Directory, связи площадок, подсети и интервалы репликаций. Ближе к концу главы мы изучим то, как работают репликации Active Directory между площадками и внутри площадок. По причине объёма содержимого я разделил обсуждаемые темы на две главы, поскольку это поможет читателю более действенно впитывать получаемые сведения.
В этой главе мы охватим следующие вопросы:
Обзор AD LDS (Active Directory Lightweight Directory Services)
Мы намерены начать данную главу с рассмотрения AD LDS. Существует множество корпоративных приложений, которые поддерживают интеграцию и имеющейся средой Active Directory. Тем не менее, имеется ряд приложений, которым требуются хранилища данных только для сохранения данных аутентификации пользователя и данных приложения. В подобных ситуациях мы можем применять AD LDS, который способен предоставлять хранилища данных и соответствующие службы доступа к ним.
Обзор AD LDS
Когда мы обсуждаем AD, мы ссылаемся на него как на какую- то отдельную службу; тем не менее, AD DS это некий набор из множества прочих компонентов, таких как DNS, Групповые политики, репликация папки SYSVOL и тому подобного. Каждый из этих компонентов требует надлежащей работы для жизнеспособного функционирования среды AD. Управление этими компонентами не является простым; оно требует вложений в ресурсы, время и навыки. И это касается не только безостановочной работы и производительности службы; критически важную роль играет безопасность. Конкретный отказ или компрометация таких компонентов/ служб может иметь потенциальное воздействие на всю инфраструктуру Active Directory в целом.
К операционным системам также причисляются и Microsoft Windows Core. Она не обладает фантазией графического интерфейса или множеством запущенных приложений, но всё ещё выполняет необходимое задание Операционной системы. Это позволяет пользователям строить системы с нуля в соответствии с их требованиями. Это также увеличивают бесперебойное время работы системы (меньше обновлений), надёжность, производительность и безопасность. Вскоре после того как Microsoft выпустила самую первую версию Active Directory, инженеры ИТ, разработчики приложений и профессионалы ИТ начали запрашивать некую усечённую версию AD DS с чистыми возможностями LDAP.
Они жаждали прекратить все эти зависимости и требования управления с тем, чтобы иметь возможность сосредоточиться на разработке приложения поверх функций ядра Active Directory. Вслед за Windows Server 2003, Microsoft выпустила Active Directory Application Mode ( ADAM ), который позволил администраторам запускать усечённую версию Active Directory без таких моментов как Групповые политики и репликация файлов. Её можно было запускать на настольном компьютере или неком сервере участнике аналогично любой прочей службе Windows. Начиная с Windows Server 2008, Microsoft переименовала её в AD LDS (Active Directory Lightweight Directory Services) и разрешила пользователям устанавливать данную роль при помощи Диспетчера сервера. Данная версия предоставила администраторам дополнительный контроль и визуализацию для развёртывания экземпляров LDS и и управления ими. Это продолжилось во всех последующих выпусках AD DS после данной версии и входит также в состав Windows Server 2022.
Где применять LDS?
Если вы уже применяете AD DS, тогда основным вопросом будет зачем нам нужны AD LDS (Active Directory Lightweight Directory Services). В своём следующем разделе мы рассмотрим некоторые ситуации, в которых мы можем воспользоваться LDS.
Разработка приложений
Именно эта область получает большинство преимуществ от функциональных возможностей AD LDS. Разработка приложений содержит много исследований и проверок. Когда эти приложения интегрированы с Active Directory, очевидно, что им требуются разработка и проверки внутри некой среды Active Directory. На протяжении этого процесса вам может потребоваться построение множества сред для проверок. Когда они являются полноценными экземплярами AD DS, это потребует ресурсов, времени и усилий по их развёртыванию и сопровождению. AD LDS делает для вас возможным запуск множества своих экземпляров внутри одной и той же среды, причём независимо. Каждый экземпляр будет иметь свою собственную схему, а инженеры смогут поддерживать такой экземпляр для всякой среды проверки. Даже хотя она и выглядит как некая усечённая версия, она предоставляет те же самые возможности аутентификации и управления AD DS, делая возможной для инженеров простую её адаптацию.
Так как экземпляры AD LDS можно запускать на настольной версии Операционной системы, они требуют меньшего числа предварительных условностей. Таким образом, приложения также могут выпускаться с интегрированной LDS. Например, не все компании запускают Active Directory. Даже хотя функции приложения основываются на свойствах Active Directory, всё ещё не просто убедить всех что им следует иметь некую среду Active Directory для запуска такого приложения. Вместо этого, установка данного приложения может обладать интегрированным экземпляром LDS, который может устанавливаться в соответствующей гостевой системе как часть общего процесса установки.
Хостинг приложений
С ходом цифрового преобразования компании применяют для своих операций всё больше и больше приложений. Большинство таких приложений являются основанными на веб приложениями, поскольку они боле удобны для применения.
Конечным пользователям не приходится беспокоиться относительно установках программного обеспечения локально и всё что от них требуется, это выполнить доступ к соответствующему приложению через веб браузер.
В большинстве случаев такие обращённые интерфейсом через Интернет приложения развёртываются развёртываются в установленном периметре или в некой общедоступной сетевой среде. Такие приложения также могут обладать требованиями аутентификации, однако в имеющемся периметре или общедоступной сетевой среде не рекомендуется устанавливать AD DS. В подобном случае наиболее распространённым для предоставления федеративного доступа методом является развёртывание AD FS; однако когда для подобного приложения требуется полная изоляция, мы можем внутри своей сетевой среды периметра или общедоступной сети установить необходимый экземпляр AD LDS и предоставить приложениям службу аутентификации с включённым в неё каталогом. Это гарантирует что данному приложению не придётся иметь никакого подключения к локальной сети или прочим экземплярам LDS в данной сетевой среде периметра. Данное решение архитектурно предоставляет некую безопасную среду.
Распределённые хранилища данных для интегрированных с AD приложений
Большинство интегрированных с Active Directory приложений также требуют изменений схемы. При видоизменениях схемы такое приложение сохраняет определённые наборы данных в имеющейся базе данных Active Directory. При большом числе приложений схема Active Directory и данные также продолжат расти. В результате это приведёт к значительному воздействию на репликацию Active Directory, в особенности когда она происходит по медленным подключениям. Вместо хранения данных в самой базе данных Active Directory, дополнительные наборы данных приложений могут храниться в соответствующем экземпляре LDS. Экземпляр LDS всё ещё применяет для аутентификации AD DS. Хранящиеся в таком экземпляре LDS дополнительные наборы данных не будут реплицироваться ни в какие прочие Контроллеры домена.
Миграция из иных служб каталога
Существуют среды и приложения, которые применяют наследуемые службы каталога на основе X500, которые хотелось бы перенести в AD DS. В таком случае в качестве посредника можно воспользоваться AD LDS, которая также способна сопровождать приложения на основе X500. Она также будет очищать рухлядь и перемещать в AD DS только отфильтрованные сведения. AD LDS сделает возможным запуск необходимого экземпляра в стороне от AD DS, а привилегированные решения идентификации, такие как MIM смогут, когда это необходимо, выполнять синхронизацию данных между экземплярами LDS и AD DS.
Azure AD Connect является инструментом Microsoft, который позволяет нам осуществлять синхронизацию идентификации пользователей из локального Active Directory в AD Azure. Даже хотя AD LDS и обладает возможностями службы каталога, Azure AD Connect не поддерживает синхронизацию из экземпляров AD LDS в Azure AD.
Установка LDS
В Операционной системе Windows Server 2022 LDS может быть установлен при помощи Диспетчера сервера. Для установки LDS пользователю требуется зарегистрироваться в выбранных системах с полномочиями локального администратора .
После входа в систему, запустите Server Manager (Диспетчер сервера) и кликните по Add Roles and Features . После этого, следуя указаниям мастера, под Server Roles выберите Active Directory Lightweight Directory Services и продолжите включив данную роль:
Рисунок 11-1
Роль AD LDS
После установки этой роли кликните в Server Manager по мастеру Post-Deployment Configuration . LDS может быть настроен двумя способами: один заключается в применении A unique instance , а другой состоит в использовании A replica of an existing instance . Вариант с репликой аналогичен клонированию копии некого имеющегося экземпляра.
Это в особенности полезно для некой среды разработки приложения, в которой инженерами необходимо поддерживать какое- то число версий приложения:
Рисунок 11-2
Тип экземпляра AD LDS
В своём следующем окне мы можем определить значение названия и описание для создаваемого экземпляра LDS:
Рисунок 11-3
Название экземпляра AD LDS
В появляющемся следом окне мы можем задать значение порта LDS. По умолчанию значение порта LDS устанавливается в 389 , а портом SSL назначается 636 . Когда вы запускаете множество экземпляров, их следует изменять соответствующим образом.
После этого мы можем создать раздел каталога данного приложения. Это позволит приложениям использовать данный раздел в качестве некого репозитория данных для хранения связанных с таким приложением сведений. Когда само приложение способно создавать некий раздел, это шаг не является необходимым и мы можем создать относящийся к делу каталог в процессе развёртывания самого приложения. При задании Partition name данного приложения, нам требуется предоставить его в неком формате отличительных имён ( DN , Distinguished Name ):
Рисунок 11-4
Раздел каталога приложения AD LDS
Наш следующий шаг заключается в определении того места, в котором следует хранить необходимые файлы данных LDS. После этого мы получим возможность определения учётной записи некой службы для LDS. Когда вы работаете в среде рабочей группы, вы можете воспользоваться для этого соответствующей Network service account или учётной записью локального пользователя.
Когда это некая среда домена, это может быть любая учётная запись пользователя Active Directory:
Рисунок 11-5
Учётная запись AD LDS
После этого нам требуется определить учётную запись администратора AD LDS. По умолчанию, она выбирает учётную запись того пользователя, которая использовалась для данной установки. Если это необходимо, её можно изменить на иную учётную запись или группу.
Когда мы определим необходимую учётную запись администратора, наш следующий шаг состоит в задании того какой файл LDIF импортировать. Это некий текстовый файл, который представляет необходимые данные и команды, которые будут применяться данным экземпляром LDAP. Это может быть один или несколько файлов LDIF; данные файлы зависят от требований приложения. Например, для функциональных возможностей учётных записей пользователя, подходящим файлом LDIF будет MSUser :
Рисунок 11-6
AD LDS — импорт файлов LDIF
Этот шаг завершает нашу установку AD LDS и по её завершению мы можем создавать относящиеся к делу объекты и управлять ими. Для соединения с ними мы можем пользоваться двумя методами. Один способ состоит в применении инструмента ADSI Edit :
Рисунок 11-7
Настройка подключения AD LDS
Другой метод заключается в применении командлета PowerShell. Это те же самые команды, которые мы применяем для управления объектами пользователя AD DS с тем единственным отличием, что нам требуется задавать необходимое DN ( Distinguished Name , отличительное имя) и сервер:
Наша предыдущая команда создаёт некую учётную запись пользователя с именем tidris в данном локальном экземпляре LDS, который запущен по порту 389 . Его путём DNS является CN=webapp01,DC=rebeladmin,DC=com .
Приведённая выше команда перечисляет все учётные записи пользователей, имеющиеся в заданном экземпляре LDS, CN=webapp01,DC=rebeladmin,DC=com . Если вы желаете узнать дополнительно о командах, обратитесь, пожалуйста, к Главе 7, Управление объектами Active Directory.
AD LDS может устанавливаться в некой настольной Операционной системе при помощи свойств Windows из Program and Features . Сами шаги установки аналогичны версии сервера. После того как AD LDS включена, мастер его настройки можно будет найти в Administrative Tools :
Рисунок 11-8
Свойства AD LDS Windows
Этот вариант доступен во всех настольных ОС начиная с Windows Vista. Если это Windows 7, потребуется выгрузка с сайта Microsoft. Для управления объектами вам потребуется установить RSAT ( Remote Server Administration Tools ) или применять PowerShell.
Репликация AD
Для среды Active Directory требуется жизнеспособная репликация. Active Directory применяет базу данных со множеством хозяев, поэтому все Контроллеры домена в его среде должны знать обо всех изменениях в базе данных Active Directory. Помимо этого, они также должны быть осведомлены об изменениях в Групповых политиках, сценариях запуска, настройках предпочтений и прочем. Когда речь заходит о репликациях, за них отвечает не только сама служба репликаций. Между Контроллерами домена также должно иметься стабильное подключение. Такой средой взаимодействия могут быть медные кабели, оптические кабели или даже SDN ( Software- Defined Network , Программно- определяемая сетевая среда). В этом разделе мы намерены рассмотреть как мы можем применять интегрированные с Active Directory функциональные возможности для сопровождения жизнеспособных репликаций.
Сопоставление FRS и DFSR
Для реплицирования содержимого папки SYSVOL Windows Server 2000 и 2003 применяют FRS. Начиная с Windows Server 2008, FRS был признан устаревшим и для репликаций папки SYSVOL ввёл DFSR:
FRS это некий устаревший протокол и начиная с Windows Server 2003 R2 в нём не было никаких разработок и вложений. Не выпускались никакие исправления ошибок и обновления. Устаревшие протоколы способны приводить к уязвимостям в безопасности систем, поскольку они могли не проверяться на современные уязвимости безопасности.
В протокол DFSR продолжают вноситься улучшения и инвестиции и он непрерывно тестируется на предмет угроз.
FRS применял алгоритм выигрыша для последней записи. Когда ваша система обнаруживает некое изменение файла в одной из папок SYSVOL , она становится авторизованным сервером и будет реплицировать весь этот файл в прочие контроллеры домена. При этом на объединяются изменения, весь файл копируется целиком, что может вызывать проблемы с производительностью, в особенности когда контроллеры домена соединены медленными подключениями.
DFSR позволяет вам реплицировать частичные изменения файла применяя репликации на уровне блоков. Она также поддерживает асинхронную репликацию файлов поверх медленных соединений. Когда вы запускаете Корпоративную редакцию (Enterprise Edition), для создания файлов на стороне клиента при использовании общих блоков, применяемых схожими файлами, могут применяться межфайловые RDC ( Remote Differential Compression , Сжатия удалённых различий). Это снизит объём данных, которые требуется передавать по имеющимся подключениям.
FRS применяет файловое сжатие NTFS в промежуточной папке.
Сжатие файлов может контролироваться на основе типа файла.
Нет никакого интерфейса для мониторинга (API или WMI), а имеющиеся инструменты графического интерфейса для управления службами крайне ограничены. Эти инструменты графического интерфейса более не доступны после Windows Server 2003. Они не поддерживают мониторинг с применением Диспетчера System Center Operation.
Имеется современный инструментарий графический интерфейс для управления относящимися к теме службами, к тому же, этот графический интерфейс может применять WMI для отслеживания жизнеспособности данной службы. Также она имеет пакеты управления, разработанные для управления через имеющийся Диспетчер System Center Operation.
FRS не имеет системы составления отчётов для выработки диагностических отчётов когда они потребуются. Диагностика основывается лишь на событиях. Она к тому же ограничена счётчиками для просмотра производительности через PerfMon.
DFSR предоставляет поддержку выработки отчётов о жизнеспособности в формате XML или HTML Она также содержит множество счётчиков для просмотра состояний производительности при помощи PerfMon.
FRS не обладает системой самостоятельного восстановления в случае разрушения файла.
DFSR в случае выявления разрушений в данных способен самостоятельно восстанавливаться.
FRS не имеет полной поддержки среды RODC и она может обладать проблемами с синхронизацией данных.
DFSR целиком поддерживает репликации RODC.
FRS не обладает современными возможностями аудита, так как содержит лишь ограниченные записи в журналы событий и отладки.
DFSR вырабатывает богатые сведения о событиях и журналирование, которые могут применяться для аудита, поиска неисправностей и отладки отказов службы.
Даже хотя FRS и признана устаревшей начиная с Windows Server 2008, она всё ещё может применяться для репликаций когда вы мигрируете с Windows Server 2000 или 2003. В большинстве случаев инженеры забывают мигрировать к DFSR в рамках своих проектов обновления. Миграция с FRS в DFSR не может выполняться автоматически и включает несколько этапов, осуществляемых вручную. Это можно сделать при помощи утилиты Dfsrmig.exe . Для выполнения миграции с FSR в DFSR уровни функциональности ваших домена и леса должны быть как минимум Windows Server 2008.
Windows Server 2022 не способен поддерживаться в качестве Контроллера домена когда имеющийся домен всё ещё пользуется репликацией FRS для SYSVOL. Если мы попытаемся настроить Windows Server 2022 в качестве некого дополнительного Контроллера домена, мы получим следующую ошибку: The specified domain %1 is still using the File Replication Service (FRS) to replicate the SYSVOL share. FRS is deprecated. The server being promoted does not support FRS and cannot be promoted as a replica into the specified domain. You MUST migrate the specified domain to use DFS Replication using the DFSRMIG command before continuing. For more information, see https://bit.ly/30WjqPl .
Единственным обходным манёвром для этого выступает миграция имеющегося домена с FRS в DFSR.
Пошаговое руководство для миграции FRS в DFSR доступно в https://bit.ly/2Zj1huT .
Площадки AD и репликация
Компоненты Active Directory представляют физическую и логическую структуры компании. Леса, домены и Организационные единицы Active Directory, а также объекты Active Directory, такие как компьютеры и пользователи, представляют логическую структуру компании. Роли и свойства Active Directory, такие как AD CS, AD RMS и AD FS, могут применяться для представления операций и требований безопасности организации. В некой инфраструктуре все эти компоненты соединены воедино при помощи физических соединений, таких как медь или оптика. Основываясь на имеющихся требованиях бизнеса, Active Directory может нуждаться в расширении на удалённые географически места. Они могут разниться начиная с прочих корпусов в том же самом месте, до расположения на разных континентах. Такие удалённые сетевые среды могут использовать для поддержки соединений друг с другом могут использовать различные соединения. Это могут быть VPN, выделенные медные линии, оптические подключения или даже соединения через спутник. По умолчанию Active Directory не разбирается с лежащей в его основе топологией. Если мы придерживаемся модели OSI ( Open Systems Interconnection ), Active Directory работает на уровне Приложений (Application level), а физические соединения представлены на Сетевом уровне. Имеются три основные причины зачем Active Directory должен также иметь сведения об этой физической топологии, и они таковы:
Из всего представленного предыдущим перечнем, я бы хотел выделить репликацию в качестве наиболее важного момента для её рассмотрения.
Репликация
Собственно успех имеющейся инфраструктуры по большей степени зависит от жизнеспособности репликации. Каждый Контроллер домена в вашей сетевой среде должен знать обо всех изменениях в конфигурации. Когда некий Контроллер домена включает синхронизацию, он передаёт данные через установленную физическую сетевую среду своему получателю. Он потребляет определённую часть полосы пропускания для этих данных. В зависимости от применяемого носителя и доступной полосы пропускания, такое воздействие от выполняемого обмена данными репликации будет различаться. Когда имеются высокоскоростные соединения, такие как 40 Gbps, 10 Gbps, 1 Gbps или 100 Mbps, тогда создаваемое обменом репликации воздействие будет очень низким. Однако для медленных соединений, таких как 128 Kbps или 256 Kbps, это воздействие будет значительно выше.
В большинстве случаев соединения между удалёнными сетевыми средами являются медленными. В подобных ситуациях должен иметься некий способ оптимизации самой репликации н основании доступной полосы пропускания. Позднее в этой главе мы подробно рассмотрим его.
Аутентификация
Когда некая персона пытается выполнить аутентификацию, получаемый запрос должен быть обработан неким контроллером домена. Когда все контроллеры домена расположены в одном географическом местоположении, не имеет значения какой из доступных контроллеров запрашивается. Однако когда он выполняется между удалёнными сетевыми средами, то время, которое потребует данный процесс будет зависеть от величины полосы пропускания доступного подключения и общего числа прыжков (hops), которое должно произойти.
Как пример, давайте предположим, что Rebeladmin Corp. имеет некую инфраструктуру AD, причём она растянута между двумя офисами в Лондоне и Сиэтле. Она обладает Контроллерами домена, находящимися в обоих местах. Когда некий пользователь входит в систему некого ПК в своём офисе в Лондоне, бессмысленно иметь процесс аутентификации, обрабатываемый Контроллером домена в его офисе в Сиэтле. Это обусловлено тем, что такому запросу потребуется проходить несколько сетевых прыжков и медленные соединения. Когда обрабатывается большое число запросов, такими запросами будет использоваться большое число полос пропускания медленных подключений. В идеале они должны обрабатываться самым ближним Контроллером домена, который расположен в том же самом месте. Тогда нет никаких дополнительных прыжков для прохода и нет никаких ограничений полосы пропускания. Кроме того, не будет зависимости от доступности соединения между двумя расположениями для обработки таких запросов. Следовательно, Active Directory обязан принудительно выполнять идентификацию расположений в удалённых сетях для выполнения аутентификации в самых ближних Контроллерах домена.
Местоположения службы
В некой удалённой сетевой среде могут иметься различные роли сервера и запущенные приложения, которые интегрированы с Active Directory. Аналогично запросам на аутентификацию, когда пользователи или компьютеры пытаются применять какую- то службу или приложение, они должны обрабатываться самым ближним сервером приложения. Это улучшит практику работы пользователя и устойчивость таких приложений или служб. Когда это происходит через медленные соединения, это будет иметь множество зависимостей и связанных с производительностью ограничений. Для этого должен иметься некий способ обработки подобных запросов служб и точек пользователей в ближайших серверах.
Надлежащим ответом на все приведённые выше требования являются соответствующие площадки (sites) Active Directory и относящиеся к ним компоненты. Они позволяют нам представлять имеющуюся физическую топологию сетевой среды внутри установленной инфраструктуры Active Directory. Тогда Active Directory будет осведомлена о том, где расположены её компоненты и как они связаны друг с другом. На основании этих сведений AD позволит вам контролировать репликации поверх медленных подключений и указывать запросам аутентификации и служб ближайшие серверы.
Итак, давайте двинемся далее и рассмотрим далее площадки Active Directory и связанные с ними компоненты.
Площадки
Площадки можно рассматривать как некие физические местоположения, которые содержат различные объекты Active Directory. Мы должны иметь возможность описания этих объектов при помощи их границ. Как пример, пользователи, компьютеры и сетевые устройства, расположенные в каком- то офисе в Лондоне могут рассматриваться как некая площадка, причём они должны идентифицироваться как уникальные, в отличии от аналогичных объектов, расположенных в офисе Сиэтла. Общая топология площадки Active Directory может быть разделена на четыре основные конструкции:
Единственный домен- единственная площадка : Это наиболее распространённая настройка для компаний малого и среднего размера. При такой установке существуют лишь единственная площадка и единственный домен. Когда мы устанавливаем в своей инфраструктуре самый первый Контроллер домена, по умолчанию он настраивается как единственный домен- единственная площадка. Эту настройку просто поддерживать.
Единственный домен- множество площадок : При данной настройке общая инфраструктура имеет только один домен и он расширяется на множество площадок. Они могут основываться на различных зданиях одного и того же кампуса или в различных географических местоположениях. Площадки связываются при помощи физических сетевых подключений.
Множество доменов- единственная площадка : В одной физической площадке может иметься множество установленных доменов. Репликации между доменами будут зависеть от его логической топологии. Значение воздействия репликации на полосу пропускания минимальное, поскольку Контроллеры домена взаимодействуют друг с другом применяя быстрые соединения локальной сетевой среды.
Множество доменов- множество площадок : При данной настройке домены будут размещены на множестве площадок. При такой установке репликации будут зависеть от имеющейся логической топологии, а также от установленной физической топологии. В некоторых установках домены будут ограничены определёнными площадками, а в прочих домены будут расширятся на множество площадок.
После того как мы определились с топологией площадок, наш следующий шаг состоит в настройке подсетей.
Подсети
Подсети представляют ассоциированные с диапазонами адреса IP в каждой площадке. Они эквивалентны значениям подсетей, расположенных в сетевых устройствах, но не обязательно должны быть в точности теми же самыми. Например, когда некая площадка применяет 10-20 подсетей класса C, тогда вместо добавления их всех в общую подсеть Active Directory данной площадки мы можем суммировать их в некую подсеть класса B и пользоваться ею. На основании таких сведений подсети Active Directory делает возможным для объектов определять местоположение ближайшего Контроллера домена. При добавлении или удалении физических подсетей они должны обновляться также и в общей настройке площадки Active Directory, в противном случае они будут передаваться неуправляемым образом обменом по медленным подключениям.
Подключения площадки
Подключения площадки представляют собой физические соединения между площадками; они однако не контролируют определённый сетевой уровень маршрутизации или соединениями между площадками. Это всё ещё будет обрабатываться лежащими в основе подключениями WAN и сетевыми устройствами. Подключения площадок делают возможным планирование заданий репликаций и контроль над полосой пропускания (стоимость подключения).
Мосты подключений площадки
Мосты подключений площадок содержат множество подключений площадок. Это делает возможным прозрачное взаимодействие между всеми подключениями площадки под таким мостом. По умолчанию, все подключения площадок рассматриваются в качестве мостов. В некоторых случаях не всем площадкам требуется общаться друг с другом. Это контролируется установленными в их сетевых устройствах правилами маршрутизации; когда они настроены таким образом, устанавливаемое по умолчанию поведение подобных мостов подключений следует изменить и убедиться что Bridge all site links отключено:
Рисунок 11-09
Образец мостов соединений площадок
Лучше всего пояснить мосты подключений площадок применяя этот простой пример. Согласно приведённой схеме, для достижения Площадкой Лондона Площадки Канады существует два пути: один применяет A , а другой пользуется B и C . Таким образом, на Площадке Сиэтла мы можем создать некий мост подключения площадки, который содержит подключения площадок B и C и представить его как некий альтернативный путь достижения Площадки Канады .
Управляемые площадки AD и прочие компоненты
Существует два способа управления площадками AD и связанными с ними компонентами. Один вариант состоит в применении Консоли управления (MMC) Площадки и службы Active Directory (AD Sites and Services), а другой заключается в использовании командлетов PowerShell. Чтобы добавлять/ изменять/ удалять площадки и связанные с ними настройки, нам требуется обладать полномочиями Администратора домена/ Администратора предприятия.
MMC Площадки и службы Active Directory будет доступна в любом сервере, который имеет включённой службу AD DS или в любом сервере/ компьютере с установленным RSAT.
Модуль Active Directory PowerShell также будет доступен в любом сервере, который имеет включённой роль AD DS или имеет установленным инструменты RSAT.
Управление площадками
Когда в устанавливаемую инфраструктуру вводится самый первый Контроллер домена, данная система создаёт свою самую первую площадку с названием Default-First-Site-Name . Это можно изменить на основании задаваемых требований. Мы можем просмотреть настройки имеющихся площадок при помощи следующего командлета PowerShell:
Она отобразит перечень сведений о площадках для имеющейся среды Active Directory.
Наш пример имеет лишь одну установленную по умолчанию площадку Active Directory. На данном самом первом этапе нам требуется изменить название её на более осмысленное, чтобы мы могли назначать объекты и выполнять настройку как подобает. Для этого мы можем применить командлет Rename-ADObject :
Наша предыдущая команда переименовывает название площадки Default-First-Site-Name на LondonSite . В своей имеющейся площадке мы способны изменять значения при помощи командлета Set-ADReplicationSite :
Приведённая выше команда изменила описание площадки на UK AD Site .
Новую площадку Active Directory мы можем создать при помощи командлета New-ADReplicationSite . Полное описание данной команды можно просмотреть воспользовавшись Get-Command NewADReplicationSite -Syntax .
Данная команда создала некую новую площадку с названием CanadaSite .
После того как необходимые площадки созданы, нам требуется переместить требующиеся Контроллеры домена в соответствующие площадки. По умолчанию все контроллеры домена помещаются в устанавливаемую по умолчанию же площадку, Default-First-Site-Name .
В своей следующей команде мы перечисляем все имеющиеся в текущей инфраструктуре Active Directory Контроллеры домена с фильтрацией сведений для отображения значений атрибутов Name , ComputerObjectDN , Site :
Теперь у нас имеется полный список Контроллеров домена; на своём следующем шаге мы можем переместить соответствующий контроллер домена на подходящую ему площадку:
Предыдущая команда переместит указанный Контроллер домена REBEL-SDC-02 на CanadaSite .
В процессе установки дополнительного контроллера домена мы можем задавать какой именно площадке он назначается. Когда такая площадка уже имеет контроллеры домена, с них будет выполнена необходимая первоначальная репликация. Когда это не так, будет осуществляться репликация с любого из выбранных контроллеров доменов, а когда и их нет, с любого из доступных контроллеров домена. Если некой проблемой является полоса пропускания подключения, рекомендуется предлагать именно тот контроллер домена, который обладает быстрым соединением, а уже затем перемещать этот контроллер домена на надлежащую площадку.
Управление подключениями площадки
Теперь, когда у нас настроены необходимые площадки, наш следующий шаг заключается в создании подключений площадок. Применяя подключения площадок мы способны управлять необходимым расписанием площадок и величиной полосы пропускания.
Стоимость подключения площадки
Стоимость подключения площадки определяет ближайшие ресурсы когда недоступны локальные ресурсы. В имеющейся сетевой топологии конкретные подключения площадок в основном базируются на значении полосы пропускания подключения. Но здесь стоимость подключения площадки основывается на значениях полосы пропускания, задержек и устойчивости. Например, допустим, площадки A и B соединяются через некое подключение 100 Mbps. Площадки A и C соединены подключением 512 kbps. Когда мы рассматриваем лишь значение полосы пропускания, площадка A предпочтёт в качестве ближайшей площадку B. Однако, в последние месяцы это подключение имело ряд отказов, а потому соединение в 512 kbps более устойчивое. Изменяя значение стоимости подключения я способен заставить площадку A применять площадку C как более предпочтительную ближайшую площадку ресурсов.
В нашем следующем примере у нас имеются три площадки, причём каждая из них обладает двумя подключениями для соединения друг с другом:
Рисунок 11-10
Образец стоиомсти соединения площадки
Если задержки и доступность линии не проблема, тогда Площадка Лондона в первую очередь должна предпочесть Площадку Канады . Когда это подключение отказывает, она всё ещё пользуется Площадкой Сиэтла . Для Площадки Канады первым предпочтением выступает Площадка Лондона , а следующим Площадка Сиэтла . Для Площадки Сиэтла первым предпочтением является Площадка Лондона , а вслед за ней идёт Площадка Канады . Но при этом мы рассматриваем лишь значение полос пропускания. Предпочтения имеющихся подключений могут меняться изменением величины стоимости подключения. По умолчанию, каждое подключение площадки добавляет стоимость 100.
Первым предпочтением будет выступать то подключение площадки, которое содержит наименьшую стоимость. Когда система определяет значение кода получателя, она не принимает во внимание имеющиеся прямые подключения. Аналогично, некая сетевая топология обнаружит наилучший маршрут. В нашем предыдущем примере, когда Площадка Лондона желает достичь Площадку Канады , имеются два пути: один это прямой путь, а второй пролегает через Площадку Сиэтла . Поэтому, когда мы ищем наилучший путь, будет вычислена стоимость прямого подключения и оно сопоставится со значением стоимости Площадка Лондона | Площадка Сиэтла | Площадка Канады .
Приводимый ниже перечень содержит значения предпочтительных стоимостей площадок на основании величины полосы пропускания. Это значение стоимости вычисляется делением 1 024 на значение логарифма доступной полосы пропускания (кбит/с).
Например, значение логарифма 512 это 2.09. При делении 1 024 на 2.09 мы получаем 377.999. Таким образом, значение стоимости линии 512 Kbps составляет 378:
Народ я правильно понимаю, что такое AD LDS и FIM или нет?
Заголовок из серии «Я твой дом труба шатал». Прочитал со второго раза.
Служба AD LDS осуществляет хранение и поиск данных для приложений, работающих с каталогами, но без зависимостей, которые требуются для служб каталогов Active Directory (AD DS). AD LDS предоставляет практически те же возможности, что и AD DS, но не требует развертывания доменов или контроллеров доменов. На одном компьютере можно одновременно запустить несколько экземпляров AD LDS с независимо управляемой схемой для каждого экземпляра AD LDS. Подробнее.
Если по FIM вы подразумевали Forefront Identity Manager, это основное слово тут Identity — если образно, то это система управления полномочиями или паролями. Но это прям совсем образно, одним словом управление доступом. Только ему на замену пришел MIM Microsoft Identity Manager 2016, вроде как.