Настройка AD FS для проверки подлинности пользователей, хранящихся в каталогах LDAP в Windows Server 2016 или более поздней версии
В следующем разделе описывается настройка, необходимая для конфигурирования инфраструктуры AD FS таким образом, чтобы она могла проверять подлинность пользователей, удостоверения которых хранятся в каталогах, совместимых с протоколом LDAP версии 3 (v3).
Во многих организациях решения по управлению удостоверениями состоят из сочетания каталогов Active Directory, AD LDS или сторонних каталогов LDAP. Благодаря добавлению поддержки AD FS для проверки подлинности пользователей, хранящихся в каталогах, совместимых с LDAP версии 3, вы можете воспользоваться всеми наборами функций AD FS корпоративного класса независимо от того, где хранятся удостоверения пользователей. AD FS поддерживает любой каталог, совместимый с LDAP версии 3.
Примечание.
Некоторые функции AD FS включают единый вход (SSO), проверку подлинности устройств, гибкие политики условного доступа, поддержку работы из любого места через интеграцию с прокси-сервером веб-приложения и простую федерацию с Microsoft Entra, которая, в свою очередь, позволяет вам и пользователям использовать облако, включая Office 365 и другие приложения SaaS. Дополнительные сведения см. в обзоре служб федерации Active Directory.
Чтобы AD FS аутентифицировал пользователей из каталога LDAP, необходимо подключить этот каталог LDAP к ферме AD FS, создав доверенные отношения локального поставщика утверждений. Доверие локального поставщика утверждений — это объект доверия, представляющий каталог LDAP в ферме AD FS. Локальный объект доверия поставщика утверждений включает в себя различные идентификаторы, имена и правила, которые идентифицируют этот каталог LDAP для локальной службы федерации.
Вы можете поддерживать несколько каталогов LDAP, каждый из которых имеет собственную конфигурацию, в одной ферме AD FS, добавив несколько доверенных поставщиков локальных утверждений. Кроме того, леса AD DS, которые не являются доверенными лесом, в которых живет AD FS, также можно моделировать как доверие локального поставщика утверждений. Вы можете создать доверие локального поставщика утверждений с помощью Windows PowerShell.
Каталоги LDAP (доверительные отношения локальных поставщиков утверждений) могут сосуществовать с каталогами AD (доверительные отношения поставщиков утверждений) на одном сервере AD FS в одной и той же ферме AD FS. Следовательно, один экземпляр AD FS способен аутентифицировать и авторизовать доступ для пользователей, которые хранятся как в каталогах AD, так и в некаталогах AD.
Для проверки подлинности пользователей из каталогов LDAP поддерживается только проверка подлинности на основе форм. Проверка подлинности на основе сертификатов и встроенная проверка подлинности Windows не поддерживается для проверки подлинности пользователей в каталогах LDAP.
Все протоколы пассивной авторизации, поддерживаемые AD FS, включая SAML, WS-Federation и OAuth, также поддерживаются для удостоверений, хранящихся в каталогах LDAP.
Протокол WS-Trust активной авторизации также поддерживается для удостоверений, хранящихся в каталогах LDAP.
Настройка AD FS для проверки подлинности пользователей, хранящихся в каталоге LDAP
Чтобы настроить ферму AD FS для проверки подлинности пользователей из каталога LDAP, выполните следующие действия.
Сначала настройте подключение к каталогу LDAP с помощью командлета New-AdfsLdapServerConnection :
$DirectoryCred = Get-Credential $vendorDirectory = New-AdfsLdapServerConnection -HostName dirserver -Port 50000 -SslMode None -AuthenticationMethod Basic -Credential $DirectoryCredПримечание.
Рекомендуется создать новый объект подключения для каждого сервера LDAP, к которому требуется подключиться. AD FS может подключаться к нескольким репликационным серверам LDAP и автоматически выполнять отработку отказа в случае сбоя определенного сервера LDAP. В таком случае можно создать по одному AdfsLdapServerConnection для каждого из этих реплик серверов LDAP, а затем добавить массив объектов подключения с помощью параметра -LdapServerConnection командлета Add-AdfsLocalClaimsProviderTrust.
ПРИМЕЧАНИЕ. Попытка использовать Get-Credential и ввести имя пользователя и пароль для привязки к экземпляру LDAP может привести к сбою из-за требования пользовательского интерфейса к определенным входным форматам, например домен\имя_пользователя или user@domain.tld. Вместо этого вы можете использовать командлет ConvertTo-SecureString следующим образом (в приведённом ниже примере предполагается, что DN учетных данных, используемых для подключения к экземпляру LDAP, — это uid=admin,ou=system):
$ldapuser = ConvertTo-SecureString -string "uid=admin,ou=system" -asplaintext -force $DirectoryCred = Get-Credential -username $ldapuser -Message "Enter the credentials to bind to the LDAP instance:"Затем введите пароль для uid=admin и выполните остальные действия.
Затем можно выполнить необязательный шаг сопоставления атрибутов LDAP с существующими утверждениями AD FS с помощью командлета New-AdfsLdapAttributeToClaimMapping. В приведенном ниже примере вы сопоставляете атрибуты LDAP givenName, Surname и CommonName с утверждениями AD FS.
#Map given name claim $GivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" # Map surname claim $Surname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" # Map common name claim $CommonName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute cn -ClaimType "http://schemas.xmlsoap.org/claims/CommonName"Это сопоставление выполняется для того, чтобы сделать атрибуты из хранилища LDAP доступными в качестве утверждений в AD FS, чтобы создать правила условного управления доступом в AD FS. Она также позволяет AD FS работать с пользовательскими схемами в хранилищах LDAP, предоставляя простой способ сопоставления атрибутов LDAP с утверждениями.
Наконец, необходимо зарегистрировать хранилище LDAP в AD FS в качестве локального доверителя поставщика утверждений с помощью командлета Add-AdfsLocalClaimsProviderTrust.
Add-AdfsLocalClaimsProviderTrust -Name "Vendors" -Identifier "urn:vendors" -Type Ldap # Connection info -LdapServerConnection $vendorDirectory # How to locate user objects in directory -UserObjectClass inetOrgPerson -UserContainer "CN=VendorsContainer,CN=VendorsPartition" -LdapAuthenticationMethod Basic # Claims for authenticated users -AnchorClaimLdapAttribute mail -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($GivenName, $Surname, $CommonName) # General claims provider properties -AcceptanceTransformRules "c:[Type != ''] => issue(claim=c);" -Enabled $true # Optional - supply user name suffix if you want to use Ws-Trust -OrganizationalAccountSuffix "vendors.contoso.com"В приведенном выше примере вы создаете доверие локального поставщика утверждений с именем "Поставщики". Вы указываете сведения о подключении для AD FS, чтобы подключиться к каталогу LDAP, который представляет доверие локального поставщика утверждений, назначая параметру
-LdapServerConnectionзначение$vendorDirectory. Обратите внимание, что на шаге 1 вы назначили$vendorDirectoryстроку подключения, которая будет использоваться при подключении к конкретному каталогу LDAP. Наконец, вы указываете, что$GivenName,$Surnameи$CommonNameатрибуты LDAP (которые сопоставлены с утверждениями AD FS), используются для управления условным доступом, включая политики многофакторной проверки подлинности и правила авторизации выдачи, а также для выдачи с помощью утверждений в маркерах безопасности, выданных AD FS. Чтобы использовать активные протоколы, такие как Ws-Trust с AD FS, необходимо указать параметр OrganizationalAccountSuffix, который позволяет AD FS разграничивать между отношениями доверия локальных поставщиков утверждений при обслуживании активного запроса авторизации.