10 фактов о Azure AD Connect и Azure AD Sync


Azure-Active-DirectoryДля решения задач идентичности Microsoft Online Services предлагает использовать возможности Azure Active Directory, начиная от Office 365 и заканчивая Intune. Хотя такой подход может и усложнить управление, Microsoft предлагает использование гибридных сценариев, работающих совместно с развернутой на своей площадке Windows Server Active Directory  и «растягиваемых» в облако.

Инструмент от Microsoft для поддержки гибридных сценариев работы называется Azure AD Connect, который стал публично доступен 24 июня 2015. Azure AD Sync вышел в свет 16 сентября 2015. (Предварительные версии были доступны и ранее)

За последний год я отвечал за дизайн, внедрение и управление этими инструментами в нескольких организациях, и они стали полноценными и проверенными боевыми товарищами в моем арсенале. Ниже несколько фактов, которые администратор должен хорошо знать при работе с этими приложениями:

1. Azure AD Connect и Azure AD Sync не высокодоступные решения (HA)

Если Вы хотите сделать Azure AD Sync высокодоступным, то вам не слишком повезло: Azure AD Connect и Azure AD Sync не поддерживают кластеризацию и обработку отказа (Failover Clustering). Единственное поддерживаемое решение иметь один экземпляр  Azure AD Sync, подключенный к единственному каталогу Azure Active Directory.

Azure AD Connect не поддерживает множество инсталляций, только одна может успешно синхронизироваться с Azure Active Directory. Любая дополнительная инсталляция должна быть сконфигурирована в Staging Mode.  В этом режиме движок синхронизации импортирует и синхронизирует данные как обычно, но не экспортирует ничего из Active Directory в Azure Active Directory. Синхронизация паролей и обратная запись паролей в нем отключена.

На данный момент это лучший вариант обеспечить сценарий синхронизации каталогов  и переключения после отказа.

2. Azure AD Sync поддерживает кластеризацию SQL

Вы можете выбрать: использовать выделенный экземпляр SQL Server, или локальную инсталляцию SQL Server 2012 Express по умолчанию.

SQL Server предполагает использование High Availability. SQL Server поддерживает 4 сценария высокой доступности (HA):

  1. AlwaysOn Failover Cluster Instances
  2. AlwaysOn Availability Groups
  3. Database mirroring
  4. Log shipping

В рассматриваем нами сценарии поддерживается только AlwaysOn Failover Cluster Instances (SQL Server). Если Вы развернули отдельный или выделенный экземпляр SQL Server, и хотите его использовать для Azure AD Sync, убедитесь, что он сконфигурирован как AlwaysOn Failover Cluster.

3. Staging Mode не синхронизирует настройки

Поскольку Staging Mode не предполагает общей конфигурации, нет автоматической возможности поддерживать все  специфические настройки в  едином состоянии для экземпляров Azure AD Sync. Изменения в конфигурации Azure AD Sync  должны быть обновлены на обоих хостах для надежной обработки отказа. Это отностися к настройкам фильтрации, опций синхронизации дополнительных расширений каталога, несмотря на то что такие настройки могут хранится в  Azure Active Directory.

image

4. Azure AD Sync не использует (g)MSA

Хотя Active Directory Federation Services (AD FS) в Windows Server 2012 R2 имеют возможность использовать для  работы своей службы Управляемые учётные записи служб (gMSA), Azure AD Sync не способна задействовать такую учетную запись для подключения к среде(ам) Windows Server Active Directory.

С точки зрения безопасности, Azure AD Sync берет на себя риск безопасности при подключении служебной учетной записи и локальной среды Windows Server Active Directory.

По умолчанию, Azure AD Sync создает служебную учетную запись с минимальными привилегиями, но с бессрочным паролем и локально , и в облаке тенанта Azure Active Directory:

    • SERVERNAME\AAD_<GUID>
      Эта учетная запись конфигурируется как локальная на машине Windows Server, где запущена Azure AD Sync и для запуска службы Microsoft Azure AD Sync service и для фонового задания  DirectorySyncClientCmd.exe. Она имеет права Allow log on locally, Log on as a batch job и Log on as a service, назначенные в локальной политике безопасности.
    • DOMAIN\MSOL_<GUID>
    • Эта учетная запись конфигурируется как член группы Domain Users в локальной среде Active Directory где разворачивается Azure AD Sync. Она имеет дополнительные делегируемые права, в зависимости от настроек обратной синхронизации паролей.
    • Sync_SERVERNAME_<GUID>@tenant.onmicrosoft.com
    Эта учетная запись конфигурируется с ролью пользователь в вашем тенанте Azure Active Directory.

Хотя и нет поддержки (group) Managed Service Account, первые две учетные записи на них по поведению очень похожи.

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

 

5. Azure AD Connect требует прав Global Admin в Azure AD

Для подключения тенанта Azure Active Directory, Azure AD Connect и Azure AD Sync  требуется учетная запись с назначенной ролью Global Administrator.

Рекомендации Microsoft  здесь такие: сконфигурировать такой аккаунт с суффиксом UPN  по умолчанию, равным tenant.onmicrosoft.com, с бессрочным паролем и без Многофакторной Аутентификации (MFA). Если пароль просрочится в Azure Active Directory то синхронизация Azure AD Connect сломается.

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

6. Azure AD Sync хранит базу синхронизации по умолчанию на системном томе

Azure AD Connect по умолчанию помещает базу синхронизации по пути C:\Program Files\Microsoft Azure AD Sync.

Лучшие практики говорят о том, что нехорошо хранить динамические данные на системном томе. Будете использовать SQL Server совместно с Azure AD Sync, нужно будет запустить directorysynctool.exe с ключом /sqlserver.

7.В некоторых сценариях, Azure AD Connect предлагает очень мало информации в журналах событий

При управлении несколькими экземплярами инсталляций Azure AD Connect очевидностью становится появление ошибок. И, что печально, журналы событий здесь почти не помогают.

К примеру, была ситуация, когда Azure AD Connect частично потеряла связь с Azure Active Directory, и хотя синхронизация работала между Windows Server Active Directory и Azure Active Directory, смена паролей и сброс пароля из Azure Active Directory обратно на площадку Windows Server Active Directory не работала вовсе. Ну, и разумеется, ни события об этом в журнале…

Пришлось применить старый трюк с ежедневной перезагрузкой сервера с запущенным экземпляром Azure AD Connect в 3:00 утра для исправления ситуации.

8. Azure AD Connect не мониторятся решениями от Microsoft

Microsoft предлагает три решения для мониторинга среды:

  1. Microsoft System Center Operations Manager (OpsMgr)
  2. Microsoft Operations Management Suite (OMS)
  3. Microsoft Azure AD Connect Health

Эти три решения могут быть использованы для мониторинга AD FS (и первые два для других служб), ни одно из них не может похвастаться мониторингом Azure AD Sync.

Примечание:
Мониторинг Azure AD Sync анонсирован для Azure AD Connect Health.

Сейчас, в ситуации описаной выше, хотя и не было информации в журналах событий, хочется надеяться что новый сервис отследит такую ситуацию («Обычно, в среднем три пользователя ежедневно меняют свой пароль, но сегодня никто не изменял его. Наверное, что-то пошло не так.»)

9. Azure AD Sync включает только один движок синхронизации

Azure AD Sync использует только один движок синхронизации. Если он ломается, ломается и Azure AD Sync.

Когда это происходит частично (как в ситуации выше), он будет частифно функционален, до тех пор. пока вы не перезапустите синхронизацию.

10. Azure AD Connect и Azure AD Sync полагаются на SSL/TLS

Azure AD Connect и Azure AD Sync взаимодействуют с Azure AD используя TCP 443. SSL/TLS используется для шифрования данных, которыми обмениваются инсталляция Azure AD Sync и Azure Active Directory.

Однако, шифрование на основе сертификатов и особенно методы понижения для согласования протоколов и силы используемого шифрования подвергались в последние годы массированным атакам (и весьма успешно). По моему мнению, сейчас SSL/TLS больше не представляют собой реальный слой безопасности.

 

Полезные ссылки:

https://msdn.microsoft.com/ru-ru/library/azure/dn578280.aspx

https://msdn.microsoft.com/en-us/library/azure/dn757602.aspx

How To Run Manual DirSync / Azure Active Directory Sync Updates
AAD Sync installation failure when using external SQL Server
Custom installation of Azure AD Connect
DirSync Accounts

Примечание: В интернетах многие считают, что  Azure AD Connect требует для запуска учетную запись с правами Enterprise Admin. Если немного подумать над этим утверждением с чашкой чая, то можно прийти к парадоксальному для многих выводу: в среде со множеством доменов- да, нужен ЕА. А для единственного домена- разумеется, хватит и Domain Admin. Лично я с тревогой смотрю на такие утверждения и все жду того дня, когда мне будут приводить доказательства, потрясая священными текстами технетов.

 

Одна большая разница между учетной записью Global Administrator в Azure AD и Enterprise Admin в Windows Server Active Directory в требовании Microsoft — содержать первую учетную запись в чистоте без срока действия пароля и без Multi-Factor Authentication (MFA). Хотя в настоящий момент Azure AD Connect не поддерживает MFA, Microsoft не настаивает с подобными требованиями для дальнейших учетных записей.

Одна из самых больших проблем, с которой мне приходилось сталкиваться у заказчиков- учетная запись Enterprise Admin, используемая для интерактивного входа. С корпоративной политикой, запрещающей такой тип входа и повышение привилегий например Windows Server 2012 R2 Authentication Policies, запрещающие ЕА действия исключительно на контроллерах домена это действительно превращалось в настоящую проблему. Следует однако отметить, что Azure AD Connect каждый раз запрашивает учетные данные при запуске и не хранит или кэширует учетные данные Enterprise admin.

Полезная ссылка

https://support.microsoft.com/en-us/kb/2855271

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s