Вам, как сетевому администратору, будет предложено решить, когда уместно использовать AD LDS. Рассмотрите возможность использования AD LDS в следующих ситуациях:
■ Вам необходимо обеспечить поддержку приложений отдела, которым требуется дополнительная идентификационная информация, не имеющая отношения к какому-либо другому отделу в организации. Интегрируя дополнительную информацию в экземпляр AD LDS, вы можете гарантировать, что соответствующий отдел имеет к ней доступ, не затрагивая службу каталогов для всей организации.
■ Вам необходимо обеспечить поддержку распределенных приложений, которым требуется доступ к данным в нескольких местах. AD LDS предоставляет те же возможности репликации с несколькими хозяевами, что и AD DS, и может использоваться для поддержки распределенных приложений.
■ В вашей организации используются более ранние приложения, использующие каталог LDAp. Вы можете перенести более ранние данные в экземпляр AD LDS и стандартизировать их с помощью технологий Active Directory.
■ Ваши приложения полагаются на каталог LDAp. AD LDS часто может размещаться на том же сервере, что и приложение, обеспечивая высокоскоростной локальный доступ к данным каталога. Это снижает трафик репликации, поскольку все необходимые данные являются локальными. Кроме того, вы можете связать экземпляр AD LDS вместе с приложением при его развертывании. Например, если вы устанавливаете бухгалтерское приложение, которое полагается на настраиваемые политики, чтобы гарантировать, что пользователи могут получить доступ только к определенному контенту, когда их пользовательский объект содержит набор определенных атрибутов, вы можете сохранить эти атрибуты и политики в AD LDS.
■ Вам необходимо предоставить услуги аутентификации для веб-приложения, такого как сервер портала Microsoft Sharepoint, в демилитаризованной сети или экстрасети. AD LDS может запрашивать внутреннюю структуру AD DS через брандмауэр, чтобы получить информацию об учетной записи пользователя и безопасно сохранить ее в сети периметра. Это позволяет избежать развертывания AD DS по периметру. Обратите внимание, что в этом сценарии вы можете развернуть либо AD LDS, либо службы федерации Active Directory (AD FS).
■ Вам необходимо предоставить данные, связанные с учетными записями пользователей в Ad DS, и требовать расширения схемы Ad DS для поддержки этих данных. Используя AD LDS в этом сценарии, вы можете предоставить дополнительные пользовательские данные без изменения схемы AD DS. Например, если вы устанавливаете приложение, которое предоставляет биометрические данные для каждого сотрудника в вашей организации и связывает каждый набор данных с соответствующей учетной записью AD DS пользователя, вы можете хранить данные в экземпляре AD LDS в центральном расположении. Наборы данных связаны с учетными записями пользователей в AD DS, но поскольку они находятся в AD LDS, они не реплицируются с другими данными AD DS, что снижает требования к пропускной способности для репликации.
■ Вам необходимо обеспечить поддержку местного развития. AD LDS можно установить на клиентские рабочие станции. Это позволяет вам предоставить разработчикам приложений переносимые каталоги с одним экземпляром, которые они могут использовать для разработки пользовательских приложений, которым требуется доступ к данным идентификации.
Типичные приложения, в которых вы можете использовать AD LDS, включают каталоги с белой страницей, приложения, ориентированные на безопасность, и приложения хранилища политик. AD LDS более портативен и управляем, чем AD DS, и, если решение AD DS требует изменения схемы, рассмотрите возможность использования вместо этого AD LDS.
