- Стив Сайфухс (@Stevesyfuhs)
Оказывается, создание новой формы hybrid authentication(гибридной аутентификации) является сложной задачай.
Как мы сделали так, чтобы протокол платформы, такой как SMB, работал на компьютерах с Windows, не требуя Active Directory?
Легко(очень!!!!): мы превратили Azure AD в KDC для Kerberos. Что я имею в виду под этим? Вы превратили AAD в KDC? А? Что ты сделал?!
Давайте немного разберёмся в этом. У вас есть виртуальный рабочий стол Azure, и выхотите хоанить профили пользователей в централизованном месте. Вуаля: RSLogix. Не новый. Но вы не хотите размещать свой собственный общий файловый ресурс.
Ах.... Замечательно!
Хорошо...ах....хорошо, у нас есть такая штука, каоторая называется Azure Files, которая является SMB поверх хранилища Azure, поэтому поместите туда профили. Это...на самом деле действительно круто.
Как вы аутентифицируетесь в нем? Полегче! NTLM. Ждать. Нет....дальше автор немного ругается.
Поэтому в AzFiles появилась поддержка Active Directory.
В принципе это несколько просто. Вы создаёте участника-службу в своём собственном объявлении и присваиваете ему имя участника-службы в своём собстенном объявлении и присваиваете ему имя участника-службы
cifs/your.file.core.windows.net и всяки раз, когда вы вводите \\your.file.core.windows.net ваш клиент Windows послушно просит у AD ticket, и вы уходите.Всё что нужна знать файлам Azure - это пароль участника службы, и он может расшифроавть ticket, получивший вашу личность, получит ваши индентификаторы безопасности, и все будут счастливы.
За исключением токо.... как хост AVD связывается с AD? Он должен быть писоединён к домену или ему должна быть оказана помощь. И ему нужна постоянная связь с DC.
Хорошо...хорошо....ваши хосты AVD нахоядтся в облаке, а ваши контроллеры домена находятся в вашей локальной сети, и это означает, что VPN или перемещение контроллеров домена(DC) в облаке всё ещё нуждаются в VPN для репликации и так далее....Почему файлы Azure не могут просто использовать AAD для аутентификации пользователей?
Давайте назовём это несоответствием импеданса. Windwos понимает SMB. SMB понимает NTLM или Kerberos. AAD понимает OAuth.
Ах!
Ну а что, если создадим AAD и принем Kerberos? Как вы азставляете крупнейшего в мире [веб-провайдера] провайдера идентификации изначально понимать наиболее используемый в мире [не веб-протокол] аутентификации?
И так началось двухлетнее путешествие автора данного материала.....
Давайте для начала установим некоторые основные правила. Kerberos хорош по многим причинам, но он также неудобен для других. У него две ноги: AS и TGS. это и есть двухлетнее путешествие.
AS обменивает первичнае креды на тикеты.
TGS обменивает тикеты на тикеты.
Нога AS может быть немного дёрганной.
AS требуется, чтобы обе стороны знали пароль клиента(или ассеметричные ключи) и AAD не обязательно знает какой-то из них, покрайне мере, не в формате необходимым для работы протокола. Кроме того, как насчёт поддержки новых аутентификаторов, таких как FIDO? Хммм..
Подожди! Мы уже решили эту проблему. Что, если AAD выдаст нам TGT во время входа в систему? Вот как мы заставили FIDO работать.
Как оказалось, этого было недостаточно. TGT, который мы выдаем для FIDO, нацелен на наши серверы on-perm и не содержит таких вещей, как PAC и предназначен для обмена на TGT on-perm в ту минуту, когда он получен, так что это просто странно...
Хорошо, а что если мы дадим отдельный TGT? Облачный TGT, если хотите. Я вошёл в Windwos. Он отправил запрос на AAD чтобы получить мой PRT и мой PRT возвращает мой FIDO TGT(необязательно) а также облако TGT.
Вот это уже становиться интересным....
Сейчас у нас есть несколько инетесных проблем, с которыми нужно бороться. Пользователь принадлежит к одной области. Когда вы входите в систему, вы получаете один основной TGT, и это более или менее определяет с кем вы связываетесь, чтобы получить тикеты. Что ж, моё цартсво находится on-prem. Облако TGT не может растоптать это, иначе мы разрушим мир.
Так что теперь я принадлежу к двум мирам: on-prem и meta-realm KERBEROS.MICROSOFTONLINE.COM. Каждый принадлежит ему. Чтобы сразу прояснить: это не изолированная вещь, это просто глобальное название. Все ещё существует изоляция арендаторов.
Эта meta-realm концептуально проста: когда вы хотите получить тикет Kerberos на облачный ресурс, вы спрашиваете KERBEROS.MICROSOFTONLINE.COM real. Это просто!
Хорошо, я вошёл в систему. получил свою PRT, получил свой облачный TGT, и теперь AVD просит FSLogix загрузить мой профиль с \\mystuff.file.core.windows.net. FSLogix не знает ничего лучшего, поэтому он срашивает Windows, Windows спрашивает SMB, SMB говорит:"Эй, мне нужен тикет?". Старый добрый SSO.
Теперь у стека Kerberos есть запрос на cifs/mystuff.file.core.windows.net, как он узнает какую область использует пользователь, какой TGT использован? Это так сбивает с толку. Это оказывается довольно просто: во время этой PRT при входе в систему мы возвращаем сопоставление суффиксов имён области.
Что это значит? Пример:
*.windows.net => KERBEROS.MICROSOFTONLINE.COMЕсли мя участника-службы заканчивается значением слева, это означает что вы должны использовать TGT из области справа.
Итак, стек Kerberos теперь знает, что cifs/myfiles.core.windows.net принадлежит облаку KERBEROS.MICROSOFTONLINE.COM realm. Как вы получите тикет от этой штуки с туманным названием?
Ещё во время входа в систему мы зарание связались и сделали то, что нужно для PRT. В ответ мы получили:
- The PRT
- Cloud TGT
- FIDO TGT (опционально)
- Realm mapping
- AAD tenant details
Часть Windows, которая выполняла аутентификацию AAD, знает достаточно о Kerberos, чтобы сказать:"Опасно ходить в одиночку! Возьмите это!", собирает информацию о TGT, сопоставлении и арендаторе и передает её в стек Kerberos.
Стек Kerberos достаточно просвещён, чтобы понять, что если он получит этот набор вещей, он должен сделать с ним что-то особенное. Что он сделает?
- Stuff the TGT into the cache
- Cache the realm mapping
- Add a KDC Proxy map between (2) and the endpoint in the tenant details
Хорошо. Вернёмся к запрому на тикет. Kerberos видит cifs/mystuff.file.core.windows.net, sees *.windows.net maps to KERBEROS.MICROSOFTONLINE.COM realm и видит сопоставление проски-сервера KDC этой области с .
Кстати, вы можете найти эту конечную точку в списке хорошо известных конечных точек: https://login.microsoftonline.com/common/.well-known/openid-configuration(замените common своим идентификатором арендатора).
Поэтому мы отправляем запрос TGS по протоколу прокси-сервера KDC для AAD и теперь это дейстивтельно старый добрый Kerberos, и мы готовим на огне.
Оказывается, это самая лёгкая часть. AAD получает запрос TGS-REQ, проверят соответствует ли облачный TGT клиенту в коннечной точке, ищет пользователя, ищет запрошенное имя участника-службы, генерирует тикет, шифрует его в основной ключ службы, объединяет все это в TGS-REP и возвращает его.
Ах да, директоры службы. Это просто AD рекламной службы. У него есть ключи. Вы настроили его, когда настраивали...В файлах Azure есть свои ключи хранения, жти ключи синхронизируются с AD, и когда вы забираете тикет, он шифруется на эти ключи.
В любом случае, стек Kerberos получает TGS-REP, удаляет тикет, генерирует запрос на доступ, возвращает его SMB, SMB помещает его в заголовок, отправляет привет SMB, файлы Azure получают привет, расшифровывают тикет, и посмотрите на жто - идентифицирован!
SMB не занл ничего лучшего. Файлы Azure в основном не знали ни чего лучшего. FSLogix определённо не знал ничего лучшего, и тперь вы вошли в ADV с централизованным и перемещаемым профилем, не защищённые AD.
Источник: https://syfuhs.net/how-azure-ad-kerberos-works
Первод: BuyKall xss.pro