Microsoft Azure AD Pass-Through Authentication и Seamless Single Sign-on
Одним из важнейших аспектов перехода организации в облако является необходимость предоставить пользователям проходить проверку подлинности при использовании облачных ресурсов. Предприятия часто стремятся сократить административные расходы и неудобства пользователей используя для этого только один каталог, опираясь на локальную Active Directory или ее облачный аналог Azure AD.
Хотя ваша компания может быть создана в облаке, вероятнее всего вы начнете с гибридной конфигурации, где существующие объекты Active Directory (а возможно и хэши паролей) будут безопасно синхронизированы в Azure AD используя Azure AD Connect. Если вы используете более старые продукты, такие как DirSync или AAD Sync, вам, безусловно, стоит дочитать статью до конца и задуматься об обновлении на AAD Connect, поскольку все новые технологии требуют новых версий ПО.
Когда AAD Connect установлен, вы можете сконфигурировать аутентификацию следующим образом:
- Аутентификация напрямую в ** Office 365** – В этом сценарии у нас два пути управления паролями пользователей.
- Первый вариант - управлять паролями раздельно, и на земле. Это позволит иметь разные пароли на земле и в облаке, но сценарий далек от совершенства, и вряд ли пользователи и отдел поддержки оценят его по достоинству.
- Второй вариант заключается в использовании AAD Connect и синхронизации хэша пароля. Поскольку в облако передается хэш хэша пароля, а не сам пароль, все звучит прилично, да и пользователи смогут использовать в Office 365 тот же самый пароль, с которым они вошли в сеть. В этом сценарии изменения пароля пользователей синхронизируются каждые две минуты.
- Аутентификация с использованием AD FS – Active Directory Federation Services (AD FS) это ваш локальный провайдер аутентификации на основе утверждений или требований (claims) проверка условий которых опирается на локальный каталог Active Directory.Облачные сервисы, такие как Office 365 перенаправляют запрос аутентификации локальным серверам AD FS. Поскольку все такие запросы будут сильно зависеть от доступности этих серверов, обычно их стараются сделать высоко доступными. Это усложняет нагрузку на администраторов и может быть одной из причин, почему вы можете задуматься о переносе этого добра в облако. Типичное развертывание AD FS включает в себя два сервера Windows Application Proxy (WAP) и ферму AD FS серверов, тоже минимум двух. Итак, четыре сервера и возможно, один, а лучше конечно два балансировщика, и все это только для проверки подлинности. Добавим сюда еще SSL сертификаты, требования к портам и DNS. Но, тем не менее, многих четырьмя серверами не напугаешь, и новые развертывания происходят довольно часто.
- Аутентификация с использованием AAD Premium или другого стороннего поставщика (third-party claims-based solution) – AAD Premium, Okta, Ping Identity, и многие, многие другие провайдеры за которых вы проголосовали. Эти решения заменяют вашу локальную инфраструктуру AD FS своим сервисом в облаке. AAD Premium использует, как это ни странно AAD Connect для синхронизации атрибутов пользователей, а продукты третьих фирм используют для этого своих агентов. (в дополнение к AAD Connect). Обычно провайдеры предоставляют красивый веб портал для аутентификации пользователей, которые заходят на него, и затем запускают облачные приложения, используя SSO. Плюсы здесь очевидны: не надо обслуживать свою инфраструктуру AD FS, а вместо этого управлять всем из красивого портала.
- Аутентификация с использованием Azure Pass-Through Authentication – Сквозная аутентификация Azure (PTA) новый метод аутентификации, появившийся в последнем релизе Azure AD Connect 1.1.377.0. Сейчас он имеет статус предварительной версии, но скоро станет общедоступным. В чем отличия:
- Возможности SSO улучшены для использования on prem.
- Не требует большой нагрузки, такой как AD FS.
- Не требует конечных точек для аутентификации Internet.
- Один дополнительный клик при развертывании
Что такое Pass-Through Authentication и как она работает?
Сквозная аутентификация маршрутизирует запросы аутентификации Office 365 через дополнительный коннектор, развернутый на базе локальной инсталляции Active Directory. Коннектор использует только безопасные исходящие соединения, поэтому не требуется отдельного сегмента DMZ или конечной точки подобного рода. Принцип работы коннектора схож с протоколом Exchange ActiveSync, в котором создаются длительные исходящие запросы к Azure AD для обслуживания запросо�� аутентификации. Это исходящий туннель зашифрован с использованием SSL сертификатов Azure AD, и поскольку коннектор использует только исходящее подключение, никаких дополнительных сертификатов или изменений в DNS с вашей стороны не потребуется.
Сквозная аутентификация использует аутентификацию по протоколу Керберос между коннектором Azure и локальным каталогом AD, и поэтому предлагает использование SSO для пользователей на компьютерах, принадлежащих к домену. Например, пользователи выполнившие вход на сайт portal.office.com или outlook.office365.com используя свои учетные данные домена, не будут повторно аутентифицированы. А пользователи в рабочей группе по прежнему, как и раньше просто получат привычный запрос учетных данных.
PTA развертывается как часть Azure AD Connect 1.1.377.0 и выше. Вся установка сводится к выбору "Pass-through authentication" во время установки и конфигурирования AАD Connect. Дополнительно мы можем включить SSO чекбоксом "Enable single sign on" . Если вы делаете обновление с предыдущей версии, просто выберите эти опции.
https://fromreallife.files.wordpress.com/2017/01/4.png
https://fromreallife.files.wordpress.com/2017/01/5.png
Следует понимать, что если PTA включена, пользователи не смогут пройти проверку подлинности, если коннектор не сможет контактировать с Azure AD. По этой причине вам, возможно, потребуется развернуть несколько дополнительных коннекторов для отказоустойчивости. Рекомендуется использовать облачную учетную запись от тенанта при конфигурации, таким образом, вы сможете изменять настройки если что-то пойдет не так.
PTA самостоятельно балансирует запросы аутентификации между коннекторами без требования вмешательства администратора. Коннектор очень нетребовательный к ресурсам и может быть установлен на любом рядовом сервере, и даже на контроллере домена. Инсталлятор находится по пути
C:\Program Files\Microsoft Azure Active Directory Connect\SetupFiles\AADApplicationProxyConnectorInstaller.exe на том сервере, где вы установили AAD Connect.
https://fromreallife.files.wordpress.com/2017/01/2.png
*
*
Просто запустите инсталлятор и приготовьте учетные данные глобального администратора, есть даже поддержка MFA. По окончанию установки будет доступна опция Connector Troubleshooter, который представляет собой загружаемое облачное приложение.
Когда применима PTA?
Сквозная аутентификация Azure идеально подходит для тех, кто хочет управлять аутентификацией внутри своей сети и не хочет устанавливать полноценную инфраструктуру AD FS.
AD FS лучше подойдет тем организациям, для который аутентификация на основе заявок (claims-based rules) всё еще требуется, поскольку PTA опирается на Керберос а не на заявки. Например, если возникнет необходимость запретить кому-нибудь доступ за пределами корпоративной сети, это потребует правил на основе заявок.
Далее, PTA сейчас работает только с Office 365. Если вашей организации требуется работа с другими облачными приложениями, такими как, например Salesforce, то пока придется все также использовать AD FS и провайдеров третьих фирм.
Вы уже настроили AD FS или Password Synchronization?
Если вы хотите перейти от AD FS к прозрачной аутентификации, вы должны переконфигурировать тенант из федеративного обратно в управляемый при помощи командлета Convert-MsolDomainToStandard. Этот процесс может занять длительное время, в зависимости от размеров тенанта. Сквозная аутентификация не выполняет синхронизацию паролей через AAD Connect, существующие хэши паролей так и останутся в облаке, просто не будут использоваться и обновляться, пока работает данная опция.
Обновление AAD Connect и включение Pass-Through Authentication
Скачиваем последнюю версию и настраиваем http://aka.ms/aadconnect
Обновление обычно занимает не больше минуты. Далее настроим Azure pass-through authentication. Запустите AD Connect , выберите "Change user sign-in".
Введите учетные данные глобального администратора для своего тенанта и MFA если потребуется. Далее выберем "Pass-through authentication radio button" и отметим "Enable single sign on". Если вы выбрали эту опцию, мастер потребует учетные данные от пользователя, входящего в группу администраторы домена.
Забегая вперед скажу, это нужно для создания учетной записи компьютера с именем AZUREADSSOACC и регистрации для него двух SPN:
HOST/autologon.microsoftazuread-sso.com
HOST/aadg.windows.net.nsatc.net
https://fromreallife.files.wordpress.com/2017/01/6.jpg
Именно к этим узлам и будет обращаться коннектор с запросом.
https://fromreallife.files.wordpress.com/2017/01/3.jpg
Подробнее об этих уздах можно прочитать по ссылкам в конце статьи. Билеты. как я заметил, шифруются RC4-HMAC, надеемся что когда-нибудь и до AES шифрования доберемся.
Итоги
Сквозная аутентификация Azure предоставляет легкий и удобный путь для единого входа Office 365, без использования инфраструктуры AD FS. Это идеальное решение для тех организаций, которые стремятся управлять и хранить свои пароли внутри корпоративной сети. Если вам требуется предоставить SSO (single sign-on) для других облачных сервисов, вам понадобятся другие решения, такие как AD FS, AAD Premium или поставщики третьих фирм.
Что на данный момент не поддерживается (январь 2017)
Не поддерживается alternate Login ID (будет доступен в течение ближайших месяцев)
Компьютеры присоединенные к домену Azure AD под управлением Windows 10 пока не поддерживаются.
Не поддерживается браузер Microsoft Edge.
Помните, что федерация все еще нужна в сценарии когда:
- Вам нужен доступ к ресурсам другого партнера
- Когда партнеру требуется доступ к вашим ресурсам
- Вы используете решения SaaS, которые не поддерживаются (пока) Azure AD и для которых требуется федеративный SSO
Важной особенностью, которая пока не поддерживается PTA, является Extranet Account Lockout в ADFS. Extranet Account Lockout это мягкая блокировка, предотвращающая возможность атак на учетную запись снаружи корпоративной сети.
/en-us/azure/active-directory/active-directory-aadconnect-pass-through-authentication