Традиционно, для управления элементами доменной сети используется 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:
- Сценарий синхронизации каталога позволяет автоматически синхронизировать с облаком новые учетные записи пользователей и групп, обновления к существующим учетным записям в локальной Active Directory, настроить клиент для работы в комбинированных сценариях с использованием Office 365 и включить решения многофакторной проверки подлинности в облаке.
- Синхронизация Active Directory с помощью сценария синхронизации паролей в дополнение к возможностям синхронизации каталога дает возможность пользователям задействовать пароль от локальной учетной записи для доступа к облачным приложениям и службам, что, в свою очередь, сокращает расходы на администрирование паролей и позволяет управлять политиками паролей из локального каталога Active Directory.
- Синхронизация 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:
- Сценарий синхронизации каталога
- Синхронизация Active Directory с помощью сценария синхронизации паролей
- Синхронизация Active Directory с помощью сценария единого входа
Спасибо!
Полезные ссылки
- Попробовать Azure бесплатно на 30 дней!
- Изучить курсы виртуальной академии Microsoft по облачным и другим технологиям
- Загрузить бесплатную или пробную Visual Studio
- Центр разработки Microsoft Azure (azurehub.ru) – сценарии, руководства, примеры, рекомендации по разработке
- Twitter.com/windowsazure_ru — последние новости Microsoft Azure
- Сообществе Microsoft Azure на Facebook – эксперты, вопросы
- Стать разработчиком универсальных приложений Windows
Автор: m_berzin
