Что такое "Azure AD"? Информация без маркетинга.

Служба каталогов Active Directory, наверно, самая популярная серверная технология от Microsoft, которая хорошо известна любому Ит-специалисту, независимо от его специализации. После ребрендинга 2008 года ее полное имя Active Directory Domain Services (ADDS). И хотя технология живее всех живых и скорее всего она доживет до пенсии всех, кто читает эти строки, можно с большой уверенностью сказать две вещи:

1.Технология остановилась в развитии и скорее всего никогда более развиваться не будет.

2. Технология будет жить ровно столько, сколько проживут "земные" серверные продукты Microsoft.

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

Прежде чем начнем, я хочу объяснить почему речь также пойдет о домыслах. Времена Windows NT давно прошли и такой документации, как делалась к ПО тогда, больше нет. Отчасти это связано с тем, что мир стал слишком быстрым, от части с тем, что мир стал ориентироваться на продажу, а это подразумевает, что лучше вложиться в маркетинг, нежели в технических писателей. Многое из того, что написано далее взято из отдельных выступлений, статей и просто получено "методом тыка". Поэтому я не претендую на на истину в последней инстанции и буду рад, если кто то дополнит мою информацию в комментариях.

1. Родственные связи Azure AD с Active Directory Domain Services.

Их нет. Все общее между двумя Active Directory это то, что они обе являются службами каталогов и обе имеют в названии Active Directory. Azure AD построена на совершенно другом движке, который базируется на Azure SQL. (вместо JET у ADDS) Более того, она использует Azure AD Graph API для работы с каталогом, а именно для создания экземпляров каталога, объектов, чтения, изменения, и.т.п. Несколько лет назад Microsoft анонсировал переход от Azure AD Graph к Microsoft Graph, как к единой платформе разработки под облачные сервисы Microsoft. Видимо это попытка причесать все API к одному знаменателю. Как вы понимаете никаких LDAP и вариантов развернуть Azure AD у себя на "виртуалке" нет и быть не может, т.к Azure AD это новый продукт не подразумевающий существование вне облаков MS.

Ниже изображение Microsoft Graph Explorer через который можно работать с каталогом.

2. Office 365 использует Azure AD как службу каталогов.

И да и нет. Получить Azure AD вы можете без каких либо покупок Office 365. Она бесплатна, с определенными ограничениями, но бесплатна. И по сути дальше вы можете ее использовать либо для аутентификации в собственных приложениях, либо для аутентификации в легионе сервисов Azure.

Так вот Azure AD не удовлетворяет потребностям всех облачных приложений, например почтовые атрибуты Exchange Online не хранятся в Azure AD. Да и в самой Azure AD просто нет таких атрибутов. Тоже самое можно сказать про SharePoint и про Lync. Все специфичные атрибуты отсутствую в Azure AD. И как тогда работает Office 365?

Все сложно. Используя обычную Active Directory DS, Microsoft развернула множество лесов, каждый под свой регион. В рамках этих лесов и хранится специфичная информация. Такие леса называются "workload specific directories". И хранят данные для группы сервисов Office 365.

• Exchange Online Directory Services. (EXODS)

• SharePoint Online Directory Services. (SPODS)

• Lync Online Directory Services. (LYODS)

• Yammer Directory

• Teams Directory

Поэтому когда вы создаете почтовый ящик через Powershell, то объект создается в EXODS и только потом "пушится" в Azure AD. Как вы понимаете синхронизация должна быть и в обратную сторону иначе работая в Exchange Online вы просто не увидите новые объекты. Однозначной технической схемы я не встречал, но есть полное ощущение, что EXODS является основным каталогом для Exchange Online.

Есть еще один интересный момент, технически пользователи одного тенанта могут быть распределены по регионам. А мы знаем, что для каждого региона свой лес Active Directory DS с "workload specific directories". Т.е получается, что синхронизация должна быть и межу лесами AD DS. Иначе не понятно как обеспечить хранение данных.

Я нашел интересную схему на сайте одного Вашингтонского университета. Собственно в ней подтверждается теория о том, что AD DS трудится как каталог для Office 365.

Немного крупиц информации также можно найти в книге Office 365 for IT Pros, но тоже все очень кратко. Видимо Microsoft не хочет, чтобы до простых смертных дошли масштабы используемых костылей.

3. Схема Azure AD.

Все давно привыкли к такому понятию как схема Active Directory, за которым скрывается описание классов, являющихся основой для создания объектов. Ну естественно все хотя бы раз расширяли схему перед установкой Exchange, SFB или SCCM. Как же обстоят дела со схемой в Azure AD. Она есть! Но опять совсем не то к чему вы привыкли.

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

Ниже список расширяемых ресурсов:

• Contact - контакты.

• Device - устройства, то что раньше было ПК, сейчас ОС, включая мобильные ОС.

• event - событие в календаре или календарь группы.

• post - элемент в другом ресурсе conversation.

• ThreadGroup - Azure Active Directory группа. (любого типа).

• Message - сообщение в mailFolder.

• Organization - объект тенанта.

• Azure Active DirectoryUser - то ради чего все создается - пользователь облачный.

Но вы не можете создать свои классы, вся модификация схемы сводится к добавлению для определенных расширяемых ресурсов дополнительных "extension attributes".

4. Функционал, который мы потеряли.

Как я уже написал ранее, отличий между AD DS и Azure AD больше чем общего. Из самых важных отличий стоит отметить плоскую структуру каталога, здесь нет и не будет организационных подразделений. Кроме этого Azure AD не содержит Group Policy, этот функционал отсутствует как класс. Kerberos более не используется для аутентификации, а вместо него набор из SAML, WS-Federation, OpenID Connect, ну и конечно Federated Services.

На вопрос - "зачем такой каталог?" ответ очень прост. Не воспринимайте Azure AD как замену AD DS. Ее создавали не для этого. Azure AD это прежде всего "identity solution" для обслуживания облачных-интернет сервисов доступ к которым обеспечивается по HTTP or HTTPS.

Для всего остального есть четыре пути:

1. Использовать локальную AD DS.

2. Использовать локальную AD DS и синхронизировать ее с Azure AD.

3. Использовать локальную AD DS, для верности разместить VM в облаке и синхронизировать ее с Azure AD. (вариант не сильно отличается от второго)

4. Использовать Azure Active Directory Domain Services.

Поймите правильно - сценарий "Переходим с AD DS на Azure AD" не является реальным. Это как переход с ложек на вилки, два продукта с разными сценариями использования. Один не интегрируется с облаком, другой не применим для On-premise.

5. Azure AD Connect. Синхронизация наше все!

Как только компания начинает использовать сервисы Azure или комплект Office 365 у нее появляется экземпляр Azure AD с учетками для доступа к облачным сервисам. Естественно вариант, когда у пользователя есть земная и облачная учетная запись одновременно мало кого устроит. Поэтому любые вариант подружить землю и небо начинаются с синхронизации локального каталога с облачным.

За редкими исключениями эта синхронизация односторонняя из AD DS в Azure AD. Синхронизацию выполняет отдельная утилита, которую естественно бесплатно поставляет Microsoft. Данная утилита пережила много ипостасей и является ответвлением продукта Microsoft Forefront Identity Manager (FIM). Называется она Azure AD Connect.

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

6. Аутентификация в облачных сценариях.

Когда вы настраиваете синхронизацию через Azure AD Connect? Когда у вас есть облачный сервис и вы хотите, чтобы люди с текущими учетными записями подключались к облаку. Синхронизировать учетные записи это половина дела, самое главное определиться как будет работать аутентификация. Есть три варианта аутентификации после синхронизации локального каталога в облако.

Первый вариант - Password hash synchronization.

Password hash synchronization – один из основных методов синхронизации. Хэш пароля из "он-према" синхронизируется в Azure AD. На самом деле там даже хэш хэша (double hashed), т.е никакой передачи пароля открыто не происходит. При этом аутентификацию делают две разных системы. Если вы подключаетесь к облачному сервису - аутентифицирует облако, а если локально к файловому серверу, то работает классическая система аутентификации через ADDS.

А если пароль синхронизировать нельзя? Ну бывают же люди, которые кладут свои данные за 8000 км в другую страну, никак не контролируют физическую безопасность этих данных, никак не могут влиять на поставщика сервиса, но при этом боятся "синка" пароля своих учетных записей.

Для таких людей есть альтернативный вариант - Pass-through Authentication.

Pass-through Authentication это альтернатива синхронизации паролей. Как и прошлый вариант он позволяет иметь один пароль и для облака и для локального использования, при этом пароль и его хэш никуда не передается.

Это работает так:

1. Компания ставит специального агента внутрь своей сети. Для отказоустойчивости мы можем поставить много агентов. Никакой настройки агенты не требуют.

2. Когда вы аутентифицируетесь на облачных ресурсах – вас аутентифицирует локальная АД. Пароль вводится на облачном сервисе. Пароль шифруется и передается агенту. Все взаимодействие по 443 порту.

3. Агент аутентифицирует через обычную ADDS и возвращает информацию - прошла аутентификация или нет.

Пароли не синхронизируются, но с точки зрения безопасности отличий мало. Люди сами каждый день будут отдавать пароли веб-формам при подключении к облачным сервисам Оffice 365 или Azure. Ну разве что эти данные не будут сохраняться в облаке. Наверно.

И есть еще один вариант - AD FS.

Вариант с AD FS это единственный сценарий, когда вся аутентификация всегда производится на стороне локальной AD. Ни в каком виде пароль не передается облаку, ни клиентом, ни репликацией. Все работает на клеймах (claim), где в качестве federate программы выступает AD FS.

Вы подключаетесь к облаку, он вас отправляет на ваш родной Web Application Proxy. Там вы аутентифицируетесь через ADFS и ADDS, получаете claim и возвращаетесь обратно. Классно? Да, но подход сильно все усложняет:

1. Нужен AD FS.

2. Нужен WAP.

3. Нужны сертификаты.

4. Нужна настройка.

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

6. Azure Active Directory (AD) Domain Services

Как я уже говорил ранее, Azure AD не замена ADDS и тем, кто имеет локальные серверы и сервисы придется держать локальную ADDS. Для того, чтобы еще сильней всех запутать Microsoft выпустила Azure Active Directory (AD) Domain Services.

Сразу скажу Azure Active Directory (AD) Domain Services или AADSS это отдельная сущность, отличная от AzureAD и AD DS. И это не контроллер домена, который вы развернули в облаке в виртуальной машине Azure.

Это сервис, который вы можете развернуть внутри Azure и получить, что то типа локальной ADDS по функционалу, т.е вы сможете получить:

1) Group Policy

2) NTLM and Kerberos authentication

3) Organizational Units

4) Ввод ПК в домен

5) LDAP

6) И все это интегрировать с AzureAD.

7) А при желании интегрировать и с AD DS.

Но это все красиво на бумаге, по факту AADDS далека от полноценной замены ADDS, так что не спешите удалять свои контроллеры домена. Количество ограничений, которые мало кто озвучивает сильно отодвигает использование этой технологии, вы не сможете расширить схему, вы ограничены одним доменом, вы обязаны синкать хэши паролей, вы ограничены одним регионом размещения, там большие вопросы по делегированию полномочий, по синку и интеграции с Azure AD, делегированию Kerberos и многому другому.

Т.е на бумаге это облачная замена ADDS, а по факту технология, которую еще "пилить" несколько лет до нормального использования. Главное - не путайте AADDS со всем остальным.

7. О хорошем в AzureAD или почему ADDS это дедушкин сундук.

Поймите правильно, заменить сейчас всем и сразу ADDS нельзя. Но отрицать, что она замерла в развитии около 10 лет назад глупо. Насколько она замерла особенно становится понятно, когда начинаешь работать с Azure AD.

Первое, что особенно актуально это мультифакторная аутентификация, которую "он-прем" уже устал ждать, для тех, кто использует Azure AD это "трехкликовая " технология, которая прекрасно проверяет второй фактор при подключении к … облачным сервисам. Осталось теперь дождаться нормального MFA для входа на ПК, который зарегистрирован в Azure AD. Пока это возможно только через "Windows Hello for Business", но хотелось бы, чтобы работало и без него.

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

Третий момент - все, что касается безопасности очень активно развивается в Azure AD. Забыли пароль и хотите сменить сами через другие факторы? Нет проблем. Запретить доступ к определенному сервису, если нет второго фактора - держите Conditional Access. Создать список простых слов, чтобы не использовали их в паролях - для этого есть Password protection. И такого довольно много и ждать его в AD DS бессмысленно.

Давайте подведем выводы:

1. ADDS, AzureAD, AADDS это три разных технологии, которые друг друга пока не заменяют.

2. AzureAD это прежде всего каталог и аутентификация для облачных продуктов.

3. AzureAD не бывает "он-премис", ее нельзя развернуть локально .

4. AzureAD абсолютно не похожа на ADDS и в ней очень много чего нет. (GPO и Kerberos как пример)

5. Вы можете синхронизировать из ADDS в AzureAD объекты, чтобы не создавать вторые четные записи для доступа к облачным сервисам.

6. Вы можете управлять тем, как будет работать аутентификация.

7. AzureAD очень далеко ушла вперед в плане безопасности и поддержки современных протоколов.

И самое главное - если у вас ВООБЩЕ нет облаков от Microsoft, то AzureAD вам не нужна.

Для тех, кто держит руку на пульсе, я сделал новый курс онлайн - "Администрирование Azure Active Directory". Посмотрев этот курс, вы получите ответы на все основные вопросы про Azure AD и сможете смело начать с ней работать и поддержать в умной компании разговор на эту тему) Для всех, кто дочитал статью до конца действует 30% скидка на данный курс. (Купон: AZAD30)

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

Илья Рудь.

P.S Понравилась статья - поделись в "чатике или фейсбуке". Это больше, чем спасибо.