Когда речь заходит об Azure AD, то многие представляют просто службу каталогов Active Directory, размещенную в облаке Microsoft. Это не совсем верно, потому что AAD — это огромная платформа, предоставляющая разнообразные возможности помимо идентификации пользователей.
Итак, основные блоки, из которых строится Azure AD это:
- аутентификация
- управление приложениями (SSO, публикация через reverse proxy, авторизация)
- политики условного доступа (Conditional Access Policies)
- управление устройствами (device management, Intune)
- гибридная идентификация для существующей локальной инфраструктуры AD (hybrid identity)
- защита и безопасность идентификации облачных объектов (identity protection)
- управление ролями и привилегиями пользователей (PIM)
- управление доступом к облачным ресурсам (managed identities: Data Lake, Azure SQL, Cosmos DB, VMs, Logic Apps, App Services, Data Factory, Containers)
- Azure AD Domain Services (AADDS)
Мы видим, что это не просто служба каталогов, а точнее, служба каталогов AADDS, GPO, пользователи, — это всего лишь маленькая часть огромной платформы. Причем, AADDS в практической плоскости мы не используем вообще, потому что она создает новый домен (managed domain), куда будет реплицироваться информация из Azure AD. То есть для начала вам надо иметь Azure AD тенант, который будет служить источником объектов.
Если у вас уже есть развитая локальная инфраструктура ADDS, которая синхронизуется через AD Connect в Azure AD, то вряд ли вы захотите с ней расставаться. Поэтому облачный AADDS — не такая уж и популярная опция для компаний с существующей инфраструктурой. А вот для развертывания нового домена это было бы неплохим решением.
Важно понимать, что сама платформа Azure AD — это не служба каталогов. Она не предоставляет для аутентификации классических протоколов Kerberos, LDAP и т.п., но она позволяет управлять объектами (пользователи, группы, приложения, девайсы) и применять к ним политики условного доступа (CAP).
Она имеет свои роли, не имеющие никакого отношения к правам в ADDS. То есть локальный доменный администратор ADDS не является глобальным администратором AAD. В AAD активно развита и применяется система RBAC (Role Based Access Control), которая позволяет назначать роли пользователям на основе тех действий, которые им надо выполнять.
В практической плоскости я очень часто сталкиваюсь с необходимостью интеграции аутентификации в приложениях и реализации single sign-on (SSO). К сожалению, девелоперы приложений очень часто не вдаются в технические особенности реализации протоколов аутентификации в той платформе, под которую они пишут приложение, в частности в Azure AD, поэтому администратору AAD приходится разбираться в использовании протоколов OAuth и OpenID Connect, на базе которых и реализована аутентификация приложений в конкретных случаях и в коде приложений. Получается, приходится читать чужой код…
Отдельная область интересов — это Single Sign-On (SSO) или единый вход. Для этого Azure AD предоставляет конечные точки (endpoints) для подключения по протоколу SAML, а также OAuth и OpenID Connect.
Для публикации локальных приложений Azure AD предлагает Azure Application Proxy (AAP), которая предоставляет бесплатно в рамках имеющейся корпоративной лицензии.
Также интересный момент заключается в использовании приложений несколькими Azure AD тенантами. Для всех тенантов точка входа единая, но отличаются области (scopes). Если приложение настроить как multitenant, то его можно использовать сразу для нескольких тенантов с одинаковой точкой входа.
Конечной точкой https://login.microsoftonline.com является конечная точка авторизации Azure AD, которая предоставляет страницу единого входа для входа в систему и аутентификации и получения кода авторизации. Другие точки, такие как https://graph.microsoft.com являются конечной точкой ресурса, которая построена на API REST и предоставляет ресурсы и услуги от Microsoft.
