Общие сведения о правилах утверждений AD FS в сочетании с Azure AD

Опубликовано: 6 Марта, 2023

Azure AD Connect помогает администраторам создать собственную ферму AD FS и подключить ее к Azure AD. Но когда вы используете Azure AD Connect в сочетании с AD FS для аутентификации пользователей или администраторов в Azure AD, вам будет очень сложно понять правила утверждений, установленные Azure AD Connect. Для «новичков» в AD FS правила утверждений в целом сложны для понимания. И нет ничего труднее понять для новичков, чем так называемые правила нестандартных требований. Давайте углубимся в автоматически созданные правила утверждений, чтобы вы могли получить общее представление об архитектуре AD FS. В этом руководстве вы узнаете, как работают правила утверждений и что они делают, когда удостоверение проходит проверку подлинности в Azure AD.

Архитектура

Взгляните на следующую архитектуру:

В этой архитектуре показан рабочий процесс проверки подлинности и синхронизации, а также задействованные компоненты, которые будут настроены при установке Azure AD Connect (см. прямоугольник «Локально»). Здесь описываются различные части Azure, которые задействованы или могут быть задействованы, например веб-приложения. В этом примере мы рассматриваем лес с одним доменом, который имеет тот же домен DNS, зарегистрированный в Azure.

Рабочий процесс

Зарегистрированный DNS-домен в Azure является федеративным, поэтому поставщиком утверждений или удостоверений является локальная Active Directory, а не Azure AD. Это означает, что после входа пользователя на портал Azure или в веб-приложение, размещенное в Azure, настроенное для аутентификации с помощью Azure AD, он будет перенаправлен на ферму AD FS. Когда пользователь вводит имя пользователя в специальное текстовое поле и оставляет текстовое поле пароля, происходит так называемое обнаружение домашней области, как вы можете видеть ниже:

Azure ищет подходящего поставщика удостоверений с помощью доменного суффикса «propassig.com» и оказывается на ферме AD FS. Если вы хотите узнать больше о другой архитектуре идентификации, вы можете найти дополнительные ресурсы на Microsoft Technet.

Давайте начнем строить и вдохнем жизнь в эту архитектуру!

Ферма AD FS

С помощью установщика Azure AD Connect легко создать простую ферму AD FS, как показано ниже. На канале 9 вы можете найти очень хорошее руководство, представленное @ArturoLucatero, по настройке фермы AD FS с помощью Azure AD Connect.

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

Полезно знать термины AD FS:

Проверяющая сторона — это не что иное, как приложение (в нашем случае Azure AD), которому вы хотите отправлять утверждения для аутентификации пользователей или администраторов.
Поставщик утверждений обычно представляет собой Active Directory, в котором хранятся атрибуты, необходимые для проверки подлинности. В некоторых случаях это также может быть другой поставщик удостоверений, например поставщик удостоверений SAML 2.0, который отправляет ответ SAML в AD FS.
Однако утверждение — это атрибут, который может идентифицировать личность. Например, атрибут Active Directory User-Principal-Name (UPN).

Обзор правил претензий

Внутренние правила утверждений AD FS действуют на стороне поставщика утверждений и на стороне проверяющей стороны.

В целом существует пять типов правил претензий:

Отправка атрибутов LDAP в виде утверждений: правила такого типа просто выдают атрибуты LDAP, такие как или Они будут добавлены в ответ на претензию, отправленный проверяющей стороне.

Отправить членство в группе как утверждение: почти то же самое, что и первый тип правила, но оно выдает членство в группе AD на ответ, отправленный проверяющей стороне.

Преобразование входящего утверждения: это правило преобразует уже установленные утверждения. Например, в ответе Claim от поставщика утверждений (AD) выдан утверждения, но проверяющая сторона ожидает, что значение будет в утверждения. Затем я могу использовать это правило для передачи значений из одного утверждения в другое.

Пропускать или фильтровать входящие утверждения: это правило может проходить через утверждения, отправленные поставщиком утверждений, или фильтровать/редактировать значения, например изменять суффикс домена.

Пользовательские правила утверждений: самые сложные правила — это настраиваемые правила, поскольку они могут объединять все предыдущие правила и работать с регулярными выражениями.

Правила утверждений поставщика утверждений по умолчанию

Давайте посмотрим на правила утверждений по умолчанию для поставщика утверждений:

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

Правила утверждения проверяющей стороны по умолчанию

С другой стороны, набор правил проверяющей стороны намного сложнее:

Правило утверждения первого поставщика утверждений

Обратите внимание, что все правила являются пользовательскими. Давайте посмотрим на первое правило:

Начнем сверху:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

Это мы ожидаем входящего требования типа , которое в основном имеет следующее значение:

Вторая часть:

issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID")

означает, что с помощью утверждения, определенного в первом абзаце ( ), мы хотим создать два новых утверждения ( и ), используя Active Directory в качестве хранилища атрибутов. — это атрибут, который ранее был выбран в качестве исходной привязки в настройке Azure AD Connect. Этот идентификатор используется в качестве уникального идентификатора для проверки подлинности удостоверения в клиенте Azure AD.

Третья часть правила — это запрос, который мы используем для просмотра AD и поиска желаемых значений. Я выделил два параметра, которые будут использоваться в запросе:

, query = "samAccountName= {0} ;userPrincipalName,objectGUID; {1} ", param = regexreplace(c.Value, "(?<domain>[^\]+)\(?<user>.+) ", "${user}"), param = c.Value );

Я думаю, что это лучше всего объяснить с помощью SQL. Тот же запрос в SQL будет выглядеть примерно так:

ИЗМЕНИТЬ АВТОРИЗАЦИЯ НА БАЗЕ ДАННЫХ:: 'Active Directoy' НА ' ДОМЕНИмя пользователя '; ВЫБЕРИТЕ userPrincipalName, objectGUID FROM 'Active Directoy', ГДЕ samAccountName = ' Имя пользователя ';

Полученные значения затем будут сохранены в утверждениях и

Второе правило утверждения поставщика утверждений

Следующее правило является последним, которое нам нужно для аутентификации пользователей. Все остальные правила, определенные в наборе, используются для аутентификации/идентификации компьютеров Windows 10, присоединенных к Azure AD. Дополнительные сведения см. в разделе Присоединение к Azure AD на устройствах с Windows 10.

В этом правиле мы просто выдаем утверждение с именем и устанавливаем значение этого утверждения таким же, как значение, хранящееся в утверждении . Кроме того, мы добавляем еще одно свойство к этому утверждению. Это делается с помощью ключевого слова «Свойства». Это задает формат утверждения «urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified», который ожидает Azure AD.

Кстати: вы также можете определить свои собственные типы утверждений, такие как , чтобы сохранить в них значения/атрибуты!

Вот оно! Все выданные нами утверждения ( будут отправлены в Azure AD. Azure AD проверяет, разрешено ли удостоверению просматривать портал Azure, и авторизует удостоверение, если оно настроено. AD FS использует формат токена SAML для отправки ответа в Azure AD, что можно увидеть при отслеживании потока с помощью fiddler.

Теперь вы готовы использовать настраиваемые правила утверждений в AD FS в сочетании с Azure AD/Connect.

Облачные вычисления