Блог

Главная - Вопросы по программированию - Как получить билет Kerberos для другого пользователя?

Как получить билет Kerberos для другого пользователя?

#azure #oauth-2.0 #kerberos

#azure #oauth-2.0 #kerberos

Вопрос:

Есть ли способ получить билет Kerberos для другого пользователя домена из Azure AD? Сценарий может заключаться в использовании OAuth2 в веб-приложении и подключении этого приложения к серверу SQL в качестве веб-пользователя.

  1. Пользователь abc@mydomain.com контакты веб-сайта с помощью браузера
  2. Веб-сайт отправляет обратно ошибку 401 (неавторизованный) и заголовок с запросом аутентификации токена на предъявителя (« WWW-Authenticate: Bearer «).
  3. OAuth2 выполняется на клиентском сайте с помощью браузера, связавшись с центром OAuth (например, Azure Active Directory для mydomain.com ).
  4. Пользователь снова обращается к веб-сайту, теперь используя заголовок auth в HTTP-запросе (« Authorization: Bearer ey... «).
  5. Теперь веб-сервер связывается с контроллером домена Kerberos (который, возможно, должен быть Active Directory), говоря: «пожалуйста, дайте мне билет Kerberos для abc@mydomain.com . Вот токен носителя OAuth, который пользователь только что прислал мне, чтобы доказать, что я должен сделать это сейчас «.
  6. KDC доверяет веб-серверу (и учетной записи, под которой он запущен) и отправляет обратно тикет Kerberos.
  7. Веб-сервер использует только что полученный билет Kerberos для входа в SQL Server в качестве пользователя abc@mydomain.com .

Шаги 5-7 можно заменить использованием учетных данных пользователя (например, хранящихся на вкладке ключей) для запроса билета Kerberos из KDC. Но мне интересно, может ли это быть достигнуто путем переноса аутентификации с одного типа на другой (например, с токена OAuth2 на билет Kerberos), а не путем сохранения учетных данных пользователя.

Похоже, что шлюз Power BI от Microsoft делает это. Технический пользователь используется для подключения к серверу SQL. Похоже, что этот пользователь может получить билет Kerberos для любого другого пользователя домена. Шлюз проверяет удостоверения пользователей с помощью аутентификации OAuth2. Поэтому я предполагаю, что весь процесс основан на доверии к техническому пользователю и / или Azure AD, доверяющему токену OAuth2.

К сожалению, я не смог найти конкретную документацию по этому вопросу. Какие разрешения потребуются?

Комментарии:

1. Вы можете использовать определенного поставщика удостоверений (IDP). В OAuth вы можете указать разных поставщиков удостоверений (например, login password, google, facebook для входа на один сайт). Если бы вы создали свой собственный IDP, вы могли бы проверить идентификатор в базе данных sql и подключить свой IDP к Azure AD.

2. Существует протокол, называемый «protocol transition» или S4U-Proxy, который делает это. В Windows это называется ограниченным делегированием с использованием «любого протокола».

3. Насколько я понимаю, ограниченное делегирование можно использовать после получения билета Kerberos. Итак, если я вхожу в веб-приложение с помощью Kerberos, и это веб-приложение выполняется в контексте пользователя, для которого (на этом компьютере) включено ограниченное делегирование, веб-приложение может войти в систему на сервере SQL, выдающем себя за меня. Я изо всех сил пытаюсь получить первый билет Kerberos (который должен поступать от контроллера домена) на основе билета OAuth, используемого для входа в систему.

Метки: