Active Directory vs. Azure Active Directory

в 7:11, , рубрики: active directory, azure, azure active directory, microsoft, Microsoft Azure, single sign on, windows server 2012 r2, Блог компании Microsoft, облако, системное администрирование

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

Active Directory vs. 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. На схеме далее показано, как приложения, размещенные либо локально, либо в облаке, используют похожие методологии для доступа к данными удостоверений, которые хранятся в наиболее подходящей для них службе удостоверений.

Active Directory vs. Azure Active Directory

Но вернемся к нашему примеру. Компания приобрела подписку на 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 vs. 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.

Active Directory vs. Azure Active Directory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!

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

Автор: m_berzin

Источник

Поделиться

* - обязательные к заполнению поля