Интеграция удостоверения AD FS с центром обработки данных Azure Stack Hub

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

Службы федерации Active Directory и Graph

Развертывание AD FS позволяет удостоверениям в существующем лесу Active Directory проходить аутентификацию в ресурсах, размещенных в Azure Stack Hub. Этот существующий лес Active Directory требует развертывания AD FS, чтобы можно было создать отношения доверия с федерацией AD FS.

Аутентификация является одной частью применения удостоверения. Для управления доступом на основе ролей (RBAC) в Azure Stack Hub необходимо настроить компонент Graph. При делегировании доступа к ресурсу компонент Graph ищет учетную запись пользователя в существующем лесу Active Directory, используя протокол LDAP.

Существующие службы AD FS представляют собой службу токенов безопасности (STS) учетных записей, которая отправляет утверждения в AD FS для Azure Stack Hub (STS ресурсов). В Azure Stack Hub служба автоматизации создает отношения доверия с поставщиком утверждений при помощи конечной точки метаданных для существующих служб AD FS.

В существующих AD FS должны быть настроены отношения доверия с проверяющей стороной. Этот шаг не выполняется службой автоматизации и должен быть настроен оператором. Конечную точку с виртуальным IP-адресом Azure Stack Hub для AD FS можно создать в формате https://adfs.<Region>.<ExternalFQDN>/.

Конфигурация отношений доверия с проверяющей стороной также требует настройки правил преобразования утверждений, которые предоставляются корпорацией Майкрософт.

Для конфигурации Graph должна быть предоставлена учетная запись службы с разрешением на чтение в существующей службе Active Directory. Эта учетная запись необходима в качестве входных данных службе автоматизации для реализации сценариев RBAC.

Для выполнения последнего шага для подписки поставщика по умолчанию настраивается новый владелец. Эта учетная запись получает полный доступ ко всем ресурсам после входа на портал администрирования Azure Stack Hub.

Требования

Настройка интеграции Graph

Graph поддерживает только интеграцию с отдельным лесом Active Directory. Если существует несколько лесов, только лес, указанный в конфигурации, будет использоваться для получения пользователей и групп.

Необходимо указать следующие сведения в качестве входных данных для параметров службы автоматизации.

Настройка сайтов Active Directory

В случае развертываний Active Directory с несколькими сайтами настройте ближайший к вашему развертыванию Azure Stack Hub сайт Active Directory. Такая конфигурация позволяет избежать необходимости в разрешении запросов службой Graph в Azure Stack Hub через сервер глобального каталога на удаленном сайте.

Добавьте подсеть Public VIP network (Общедоступная сеть VIP) Azure Stack Hub на сайт Active Directory, ближайший к Azure Stack Hub. Для примера предположим, что в вашей среде Active Directory есть два сайта: для Сиэтла и для Редмонда. Если экземпляр Azure Stack Hub развернут на сайте для Сиэтла, следует добавить к сайту Active Directory для Сиэтла подсеть сети Azure Stack Hub с общедоступными виртуальными IP-адресами.

Дополнительные сведения о сайтах Active Directory см. в разделе Проектирование топологии сайтов.

Создание учетной записи пользователя в существующей службе Active Directory (необязательно)

При необходимости можно создать учетную запись для службы Graph в существующей службе Active Directory. Выполните этот шаг, если у вас еще нет подходящей для использования учетной записи.

1. В существующей службе Active Directory создайте следующую учетную запись пользователя (рекомендация).

   • Имя пользователя: graphservice.
   • Пароль. Настройте надежный пароль без ограничения срока действия.

   Особые разрешения или членство не требуются.

Активация службы автоматизации для настройки Graph

Для выполнения этой процедуры используйте компьютер в сети центра обработки данных, который может взаимодействовать с привилегированной конечной точкой в Azure Stack Hub.

1. Откройте сеанс Windows PowerShell с повышенными правами (запуск от имени администратора) и подключитесь к IP-адресу привилегированной конечной точки. Используйте учетные данные CloudAdmin для аутентификации.

   $creds = Get-Credential
   $pep = New-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
   

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

   Выполните приведенный ниже сценарий для Сборки Azure Stack Hub 2008 и более поздней версии
   

    $i = @(
           [pscustomobject]@{ 
                     CustomADGlobalCatalog="fabrikam.com"
                     CustomADAdminCredential= Get-Credential -Message "Do not include the domain name of the graphservice account in the username."
                     SkipRootDomainValidation = $false 
                     ValidateParameters = $true
                   }) 
   
    Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -customCatalog $using:i} 
   
   
   

   Выполнение приведенного ниже скрипта для сборки Azure Stack Hub до 2008 г.
   

   Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -CustomADGlobalCatalog contoso.com} 
   
   
   

   При появлении запроса укажите данные учетной записи пользователя, которую требуется использовать для службы Graph (например, graphservice). Для командлета Register-DirectoryService нужно указать имя леса и корневой домен в лесу, а не другие домены в лесу.

   Важно!

   Дождитесь появления всплывающего элемента для ввода учетных данных (Get-Credential не поддерживается на привилегированной конечной точке) и укажите учетные данные учетной записи службы Graph.

3. Командлет Register-DirectoryService имеет необязательные параметры, которые можно использовать в определенных сценариях при сбое существующей проверки Active Directory. При выполнении этот командлет проверяет, что предоставленный домен является корневым доменом, к серверу глобального каталога можно подключиться и предоставленная учетная запись обеспечивает доступ на чтение.

   Параметр	Описание
   SkipRootDomainValidation	Указывает, что вместо рекомендуемого корневого домена следует использовать дочерний домен.
   ValidateParameters	Обход всех проверок.

Протоколы и порты Graph

Служба Graph в Azure Stack Hub использует перечисленные ниже протоколы и порты для связи с доступным для записи глобальным сервером каталога (GC) и центром распространения ключей (KDC), который может обрабатывать запросы на вход в целевом лесу Active Directory.

Служба Graph в Azure Stack Hub использует приведенные ниже протоколы и порты для связи с целевой службой Active Directory.

Настройка интеграции AD FS путем скачивания метаданных федерации

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

Активация автоматизации для настройки доверия с поставщиком утверждений в Azure Stack Hub (путем скачивания метаданных федерации)

Для выполнения этой процедуры используйте компьютер, который может взаимодействовать с привилегированной конечной точкой в Azure Stack Hub. Ожидается, что сертификат, используемый для учетной записи AD FS службы токенов безопасности, является доверенным для Azure Stack Hub.

1. Откройте сеанс Windows PowerShell с повышенными правами и подключитесь к привилегированной конечной точке.

   $creds = Get-Credential
   Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
   

2. Подключившись к привилегированной конечной точке, выполните следующую команду, указав параметры, подходящие для используемой среды.

   Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataEndpointUri "https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml"
   

3. Выполните следующую команду, чтобы изменить владельца подписки поставщика по умолчанию, указав актуальные параметры для используемой среды.

   Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
   

Настройка интеграции AD FS путем предоставления файла метаданных федерации

Начиная с версии 1807, используйте этот метод, если выполняется какое-либо из следующих условий:

• Цепочка сертификатов для AD FS отличается по сравнению с другими конечными точками в Azure Stack Hub.
• Нет сетевого подключения между экземпляром AD FS Azure Stack Hub и существующим сервером AD FS.

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

Создание файла метаданных федерации

Для выполнения следующей процедуры необходимо использовать компьютер с сетевым подключением к существующему развертыванию AD FS, которое становится службой токенов безопасности для учетной записи. Кроме того, нужно установить необходимые сертификаты.

1. Откройте сеанс Windows PowerShell с повышенными правами и выполните следующую команду, указав актуальные параметры для используемой среды.

    $url = "https://win-SQOOJN70SGL.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml"
    $webclient = New-Object System.Net.WebClient
    $webclient.Encoding = [System.Text.Encoding]::UTF8
    $metadataAsString = $webclient.DownloadString($url)
    Set-Content -Path c:\metadata.xml -Encoding UTF8 -Value $metadataAsString
   

2. Копируйте файл метаданных на компьютер, который может взаимодействовать с привилегированной конечной точкой.

Активация автоматизации для настройки доверия поставщика утверждений в Azure Stack Hub (с помощью файла метаданных федерации)

Чтобы выполнить эту процедуру, используйте компьютер, который может взаимодействовать с привилегированной конечной точкой в Azure Stack Hub и имеет доступ к файлу метаданных, созданному на предыдущем шаге.

1. Откройте сеанс Windows PowerShell с повышенными правами и подключитесь к привилегированной конечной точке.

   $federationMetadataFileContent = get-content c:\metadata.xml
   $creds=Get-Credential
   Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
   

2. Подключившись к привилегированной конечной точке, выполните следующую команду, указав параметры, подходящие для используемой среды.

   Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent
   

3. Выполните следующую команду, чтобы изменить владельца подписки поставщика по умолчанию. Укажите актуальные параметры для используемой среды.

   Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
   

   Примечание

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

Настройка проверяющей стороны в существующем развертывании AD FS (службе токенов безопасности для учетной записи)

Корпорация Майкрософт предоставляет сценарий, который настраивает отношения доверия с проверяющей стороной, включая правила преобразования утверждений. Использовать этот сценарий необязательно, можно вручную выполнить необходимые команды.

Вспомогательный сценарий можно скачать в разделе средств Azure Stack Hub на сайте GitHub.

Если вы решили вручную выполнить команды, сделайте следующее.

1. Скопируйте приведенное ниже содержимое в TXT-файл (например, сохраните этот файл как c:\ClaimIssuanceRules.txt) в экземпляре AD FS или элементе фермы своего центра обработки данных.

   @RuleTemplate = "LdapClaims"
   @RuleName = "Name claim"
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
   => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"), query = ";userPrincipalName;{0}", param = c.Value);
   
   @RuleTemplate = "LdapClaims"
   @RuleName = "UPN claim"
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
   => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);
   
   @RuleTemplate = "LdapClaims"
   @RuleName = "ObjectID claim"
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
   => issue(Type = "http://schemas.microsoft.com/identity/claims/objectidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
   
   @RuleName = "Family Name and Given claim"
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
   => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"), query = ";sn,givenName;{0}", param = c.Value);
   
   @RuleTemplate = "PassThroughClaims"
   @RuleName = "Pass through all Group SID claims"
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
   => issue(claim = c);
   
   @RuleTemplate = "PassThroughClaims"
   @RuleName = "Pass through all windows account name claims"
   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
   => issue(claim = c);
   

2. Подтвердите, что проверка подлинности на основе Windows Forms для экстрасети и интрасети включена. Вы можете проверить, включена ли она, с помощью следующего командлета.

   Get-AdfsAuthenticationProvider | where-object { $_.name -eq "FormsAuthentication" } | select Name, AllowedForPrimaryExtranet, AllowedForPrimaryIntranet
   

   Примечание

   Поддерживаемые строки пользовательских агентов службы WIA (встроенная проверка подлинности Windows) могут устареть для развертывания службы федерации Active Directory (AD FS), и в этом случае для поддержки современных клиентов потребуется их обновить. Подробнее об обновлении поддерживаемых строк пользовательских агентов в WIA можно прочитать в статье Настройка интрасети на основе форм проверки подлинности для устройств, не поддерживающих WIA.
   
   В статье Настройка политик аутентификации описана процедура включения политики проверки подлинности на основе форм.

3. Чтобы добавить отношения доверия с проверяющей стороной, выполните следующую команду Windows PowerShell на экземпляре AD FS или элементе фермы. Обязательно обновите конечную точку AD FS и укажите файл, созданный на шаге 1.

   Важно!

   Для клиентов, использующих Azure Stack Hub версии 2002 и более поздних, протокол TLS 1.2 применяется к конечной точке ADFS Azure Stack Hub. Таким образом, tls 1.2 также должен быть включен на клиентских серверах ADFS. В противном случае при запуске Add-ADFSRelyingPartyTrust на узле или ферме ADFS, принадлежащем клиенту, возникнет следующая ошибка:

   Add-ADFSRelyingPartyTrust : The underlying connection was closed: An unexpected error occurred on a send.

   Для AD FS 2016 и 2019

   Add-ADFSRelyingPartyTrust -Name AzureStack -MetadataUrl "https://YourAzureStackADFSEndpoint/FederationMetadata/2007-06/FederationMetadata.xml" -IssuanceTransformRulesFile "C:\ClaimIssuanceRules.txt" -AutoUpdateEnabled:$true -MonitoringEnabled:$true -enabled:$true -AccessControlPolicyName "Permit everyone" -TokenLifeTime 1440
   

   Для AD FS 2012 и AD FS 2012 R2

   Add-ADFSRelyingPartyTrust -Name AzureStack -MetadataUrl "https://YourAzureStackADFSEndpoint/FederationMetadata/2007-06/FederationMetadata.xml" -IssuanceTransformRulesFile "C:\ClaimIssuanceRules.txt" -AutoUpdateEnabled:$true -MonitoringEnabled:$true -enabled:$true -TokenLifeTime 1440
   

   Важно!

   Чтобы настроить правила авторизации выдачи при использовании AD FS на основе Windows Server 2012 или Windows Server 2012 R2, необходимо использовать оснастку MMC AD FS.

4. При использовании браузера Internet Explorer или Microsoft Edge для доступа к Azure Stack Hub необходимо игнорировать привязки токенов. В противном случае попытка входа завершится сбоем. На экземпляре AD FS или элементе фермы выполните следующую команду.

   Примечание

   Эта инструкция неприменима при использовании Windows Server 2012 или 2012 R2 AD FS. Для этих сред можно безопасно пропустить эту команду и продолжать интеграцию.

   Set-AdfsProperties -IgnoreTokenBinding $true
   

Создание имени субъекта-службы

Существует множество сценариев, в которых требуется использовать имя субъекта-службы для проверки аутентификации. Ниже приводятся некоторые примеры:

• Использование Azure CLI с развертыванием AD FS Azure Stack Hub.
• использование пакета управления System Center для Azure Stack Hub при развертывании с AD FS;
• использование поставщиков ресурсов Azure Stack Hub при развертывании с AD FS;
• разные приложения;
• требуется поддержка неинтерактивного входа.

Дополнительные сведения о создании имени субъекта-службы см. в разделе Создание субъекта-службы для AD FS.

Устранение неполадок

Откат конфигурации

Если возникла ошибка, которая оставила среду в состоянии, в котором аутентификация невозможна, можно выполнить откат.

1. Откройте сеанс Windows PowerShell с повышенными правами и выполните следующие команды.

   $creds = Get-Credential
   Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
   

2. Затем выполните следующий командлет.

   Reset-DatacenterIntegrationConfiguration
   

   После выполнения отката откатываются все изменения конфигурации. Возможна будет только аутентификация с использованием встроенного пользователя CloudAdmin.

   Важно!

   Необходимо настроить первоначального владельца для подписки поставщика по умолчанию.

   Set-ServiceAdminOwner -ServiceAdminOwnerUpn "azurestackadmin@[Internal Domain]"
   

Сбор дополнительных журналов

В случае сбоя при выполнении какого-либо из командлетов можно собрать дополнительные журналы, выполнив командлет Get-Azurestacklogs.

1. Откройте сеанс Windows PowerShell с повышенными правами и выполните следующие команды.

   $creds = Get-Credential
   Enter-pssession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
   

2. Затем выполните следующий командлет.

   Get-AzureStackLog -OutputPath \\myworkstation\AzureStackLogs -FilterByRole ECE
   

Дальнейшие действия

Интеграция внешнего решения для мониторинга с Azure Stack