- PVSM.RU - https://www.pvsm.ru -
Традиционно, для управления элементами доменной сети используется Active Directory. Но все чаще организации внедряют в свою работу различные облачные службы, которые требуют создания своих учетных записей. Инструментом для создания и управления учетными записями пользователей, применыемых в различных облачных службах Microsoft, которые приобретает организация, является Azure Active Directory [1]. В этой статье мы поговорим о некоторых отличиях между 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:
Все это, кончено, замечательно звучит, но более интересно посмотреть, как каждый из сценариев синхронизации работает и в чем заключается его принципиальная особенность.
Сценарий синхронизации каталогов используется для синхронизации локальных объектов доменной сети в облако. При реализации этого сценария в итоге вы получите учетную запись пользователя в Azure Active Directory, которая будет совпадать с локальной учетной записью во всем, кроме пароля. Пароли при реализации сценария синхронизации каталога НЕ синхронизируются. Поэтому теперь вы говорите вашим пользователям, что для доступа, например, к Windows Intune можно использовать свой обычный логин, а вот пароль нужно будет придумать другой. В этом случае, пользователь при доступе к облачной службе будет аутентифицирован с помощью именно Azure Active Directory. Примерная схема того, как работает этот процесс, представлена ниже.
После того, как настройка выполнена, администраторы могут управлять объектами каталога, используя локальную Active Directory, и эти изменения будут синхронизированы с клиентскими компьютерами. Синхронизация службы каталогов выполняется по расписанию и синхронизируются с Azure AD.
Среди преимуществ сценария синхронизации каталога можно выделить:
Все-таки больным местом учетных записей пользователей являются не логины, а пароли. Логин обычно запомнить не сложно, а вот иметь разные пароли для доступа к разным ресурсам – испытание для пользователя. Поэтому он либо придумывает простые пароли, либо пишет их на стикерах и клеит на монитор, либо догадывается использовать везде один и тот же пароль. Существует расширение сценария синхронизации каталога – сценарий синхронизации паролей. Если на компьютере с уже реализованной синхронизацией каталогов включить синхронизацию паролей, то сотрудники вашей организации смогут подключаться к облачными службам Microsoft (например, Office 365, Dynamics CRM, Windows InTune), используя пароль от локальной учетной записи. Изменение пароля в локальной корпоративной сети будут синхронизированы с облаком, причем пароли синхронизируются чаще, чем другие данные каталогов.
Ниже приведена схема синхронизации Active Directory с помощью сценария синхронизации паролей. Чтобы пароль был синхронизирован, средство синхронизации каталогов извлекает хэш пароля пользователя из локальной службы Active Directory и синхронизирует его с Azure Active Directory.
Теперь со спокойной душой говорим пользователям, что мы используем новую облачную службу, доступ к которой можно получить со своим обычным логином и паролем. Все довольны, все счастливы.
При использовании данного сценария синхронизации среди преимуществ нужно отметить:
Тем не менее, при реализации сценария синхронизации паролей, пользователь все равно проходит процесс аутентификации с помощью учетной записи Azure Active Directory, а мы хотим пойти дальше, и использовать для аутентификации именно локальную Active Directory. Для того, чтобы нашу задумку осуществить, необходимо использовать сценарий синхронизации 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 и Azure Active Directory и сценариях их синхронизации.
Подробные инструкции о том, как реализовать каждый из описанных здесь сценариев, вы можете посмотреть на портале TechnNet:
Спасибо!
Автор: m_berzin
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/microsoft/72485
Ссылки в тексте:
[1] Azure Active Directory: http://l.techdays.ru/go/azuretrial
[2] Сценарий синхронизации каталога: http://technet.microsoft.com/ru-ru/library/hh967642.aspx
[3] Синхронизация Active Directory с помощью сценария синхронизации паролей: http://technet.microsoft.com/ru-ru/library/dn246918.aspx
[4] Синхронизация Active Directory с помощью сценария единого входа: http://technet.microsoft.com/ru-ru/library/hh967643.aspx
[5] Изучить курсы: http://l.techdays.ru/go/mva
[6] Загрузить: http://l.techdays.ru/go/getvs
[7] Центр разработки Microsoft Azure (azurehub.ru): http://www.azurehub.ru/
[8] Twitter.com/windowsazure_ru: http://www.twitter.com/windowsazure_ru
[9] Сообществе Microsoft Azure на Facebook: http://www.facebook.com/groups/azurerus/
[10] Стать разработчиком: http://l.techdays.ru/go/winstart
[11] Источник: http://habrahabr.ru/post/241313/
Нажмите здесь для печати.