Active Directory vs. Azure Active Directory

Традиционно, для управления корпоративной сетью используется Active Directory. Но все чаще организации внедряют в свою работу различные облачные службы, которые требуют создания своих учетных записей. Инструментом для создания и управления учетными записями пользователей, применяемых в различных облачных службах Microsoft, которые приобретает организация, является Azure Active Directory. В этой статье мы поговорим о некоторых отличиях между Active Directory и Azure Active Directory, а также рассмотрим основные сценарии их синхронизации.


Увеличить

Я уверена, что подавляющее большинство тех, кто читает эту статью, знакомы с Active Directory, которая является частью операционных систем Windows Server и представляет собой службу каталогов, предлагаемую компанией Microsoft. Имея учетную запись AD, пользователь аутентифицируется в системе и получает доступ к приложениям, файловым службам, принтерам и другим локальным ресурсам.

Так же, как и локальная Active Directory, Azure Active Directory аутентифицирует пользователей и предоставляет им доступ к приложениям. Однако, Azure Active Directory предназначена для работы пользователь не в локальной инфраструктуре, а при работе со сторонними облачными приложениями, такими как Office365 и Windows Intune.

Например, ваша организация приобретает подписку на Windows Intune. При этом вы, как администратор, получаете доступ к порталу управления Windows Intune и должны предоставить доступ другим пользователям в вашей сети (всем или нескольким – это уже детали). Windows Intune – это облачная служба Microsoft, которая не работает с локальной Active Directory. Для того, чтобы создать учетные записи пользователей для доступа к облачным службам, которые внедряет и использует организация, необходимо использовать Azure Active Directory.

C технической точки зрения, нужно отметить, что для доступа к данным в локальной службе Active Directory бизнес-приложения могут использовать LDAP, а сторонние облачные приложения могут взаимодействовать с данными с помощью API Graph. Для аутентификации в AD DS используется протокол Kerberos, а в Azure Active Directory – OAuth 2.0. На схеме далее показано, как приложения, размещенные либо локально, либо в облаке, используют похожие методологии для доступа к данными удостоверений, которые хранятся в наиболее подходящей для них службе удостоверений.


Увеличить

Но вернемся к нашему примеру. Компания приобрела подписку на Windows Intune, и теперь системный администратор должен создать в Azure AD учетные записи для пользователей. Сделать он это может конечно ручками через графический интерфейс или даже использовать командлеты и скрипты PowerShell. Но, используя этот вариант добавления пользователей, вы создаете абсолютно самостоятельных пользователей, никак не связанных с теми, что давно уже существуют в вашей локальной сетке. Да, логины могут совпадать, но могут и отличаться; пароли – тем более. Все это – огромный источник потенциальной головной боли для админа и регулярных обращений от пользователей в службу поддержки. Для того, чтобы эти проблемы минимизировать, предлагается три сценария синхронизации AD и Azure AD, о которых мы поговорим далее.

Синхронизация Active Directory и Azure Active Directory

Выделяют три основных сценария синхронизации каталогов Active Directory и Azure Active Directory:

1. Сценарий синхронизации каталога позволяет автоматически синхронизировать с облаком новые учетные записи пользователей и групп, обновления к существующим учетным записям в локальной Active Directory, настроить клиент для работы в комбинированных сценариях с использованием Office 365 и включить решения многофакторной проверки подлинности в облаке.
2. Синхронизация Active Directory с помощью сценария синхронизации паролей в дополнение к возможностям синхронизации каталога дает возможность пользователям задействовать пароль от локальной учетной записи для доступа к облачным приложениям и службам, что, в свою очередь, сокращает расходы на администрирование паролей и позволяет управлять политиками паролей из локального каталога Active Directory.
3. Синхронизация Active Directoryс помощьюсценария единого входа, в отличие от первых двух сценариев, не поддерживает возможность включения решения многофакторной аутентификации в облаке, но зато поддерживает эту возможность в локальной среде, а также обеспечивает проверку подлинности пользователей в локальном каталоге Active Directory и позволяет реализовать сценарии единого входа с использованием корпоративных учетных данных, настроить страницу для единого входа и ограничить доступ к облачным службам и приложениям по местоположению, типу клиента или конечной точке Exchange-клиента.

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

1. Сценарий синхронизации каталога

Сценарий синхронизации каталогов используется для синхронизации локальных объектов доменной сети в облако. При реализации этого сценария в итоге вы получите учетную запись пользователя в Azure Active Directory, которая будет совпадать с локальной учетной записью во всем, кроме пароля. Пароли при реализации сценария синхронизации каталога НЕ синхронизируются. Поэтому теперь вы говорите вашим пользователям, что для доступа, например, к Windows Intune можно использовать свой обычный логин, а вот пароль нужно будет придумать другой. В этом случае, пользователь при доступе к облачной службе будет аутентифицирован с помощью именно Azure Active Directory. Примерная схема того, как работает этот процесс, представлена ниже.


Увеличить

После того, как настройка выполнена, администраторы могут управлять объектами каталога, используя локальную Active Directory, и эти изменения будут синхронизированы с клиентскими компьютерами. Синхронизация службы каталогов выполняется по расписанию и синхронизируются с Azure AD.

Среди преимуществ сценария синхронизации каталога можно выделить:

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

2. Синхронизация Active Directory с помощью сценария синхронизации паролей

Все-таки больным местом учетных записей пользователей являются не логины, а пароли. Логин обычно запомнить не сложно, а вот иметь разные пароли для доступа к разным ресурсам – испытание для пользователя. Поэтому он либо придумывает простые пароли, либо пишет их на стикерах и клеит на монитор, либо догадывается использовать везде один и тот же пароль. Существует расширение сценария синхронизации каталога – сценарий синхронизации паролей. Если на компьютере с уже реализованной синхронизацией каталогов включить синхронизацию паролей, то сотрудники вашей организации смогут подключаться к облачными службам Microsoft (например, Office 365, Dynamics CRM, Windows InTune), используя пароль от локальной учетной записи. Изменение пароля в локальной корпоративной сети будут синхронизированы с облаком, причем пароли синхронизируются чаще, чем другие данные каталогов.

Ниже приведена схема синхронизации Active Directory с помощью сценария синхронизации паролей. Чтобы пароль был синхронизирован, средство синхронизации каталогов извлекает хэш пароля пользователя из локальной службы Active Directory и синхронизирует его с Azure Active Directory.


Увеличить

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

При использовании данного сценария синхронизации среди преимуществ нужно отметить:

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

Тем не менее, при реализации сценария синхронизации паролей, пользователь все равно проходит процесс аутентификации с помощью учетной записи Azure Active Directory, а мы хотим пойти дальше, и использовать для аутентификации именно локальную Active Directory. Для того, чтобы нашу задумку осуществить, необходимо использовать сценарий синхронизации Active Directory с помощью единого входа.

3. Синхронизация Active Directory с помощью сценария единого входа

Для реализации единого входа должен быть реализован сценарий синхронизации каталога и построена инфраструктура службы токенов безопасности (STS). Azure AD поддерживает сценарии единого входа, которые используют одну из следующих служб токенов безопасности: Active Directory Federation Services, поставщик удостоверений Shibboleth, а также сторонние поставщики удостоверений.

Процесс работы сценария единого входа представлен на следующей схеме.

Увеличить

При реализации сценария единого входа настраиваются федеративные отношения между службой STS (Security Token Service) и системой проверки подлинности Azure Active Directory. Пользователь при попытке подключения к облачной службе будет перенаправлен на сервер службы STS. Например, при использовании службы ADFS, пользователь будет перенаправлен на ADFS-сервер, что можно будет увидеть по изменению адреса в браузере:

Увеличить

После успешной аутентификации, пользователь с учетной записью локального каталога Active Directory получит токен проверки подлинности от локальной службы STS, с помощью которого получит доступ к облачной службе. Принципиальным отличием от первых двух сценариев является то, что в сценарии единого входа пользователь аутентифицируется с помощью Windows Server Active Directory.

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

• Управление политиками.Администратору не нужно выполнять какие-либо дополнительные задачи в облаке для того, чтобы контролировать политики учетных записей Active Directory.
• Управление доступом.Администратор может ограничить доступ к облачным службам так, чтобы доступ можно было получить только через среду организации или через интернет-сервер.
• Снижение количества обращений за поддержкой. Тут всё то же: меньше паролей запоминать – меньше обращений от пользователей.
• Безопасность. Так как все серверы и службы, используемые в рамках реализации сценария единого входа, управляются и контролируются локально, то удостоверения пользователей и информация о них защищены.
• Поддержка строгой проверки подлинности. Сценарий единого входа позволяет реализовать многофакторную проверку подлинности для доступа к облачной службе или приложению.

Надеюсь, данная статья дала вам представление о разнице между Active Directory и Azure Active Directory и сценариях их синхронизации.

Подробные инструкции о том, как реализовать каждый из описанных здесь сценариев, вы можете посмотреть на портале TechnNet:

1. Сценарий синхронизации каталога
2. Синхронизация Active Directory с помощью сценария синхронизации паролей
3. Синхронизация Active Directory с помощью сценария единого входа