Configurar o AD FS para autenticar usuários armazenados em diretórios LDAP no Windows Server 2016 ou posterior
O tópico a seguir descreve a configuração necessária para permitir que a infraestrutura do AD FS autentique usuários que tenham as identidades armazenadas em diretórios compatíveis com LDAP (protocolo LDAP) v3.
Em muitas organizações, as soluções de gerenciamento de identidade consistem em uma combinação de Active Directory, AD LDS ou diretórios LDAP de terceiros. Com a adição do suporte de AD FS para autenticação de usuários armazenados em diretórios compatíveis com LDAP v3, você poderá se beneficiar de todo o conjunto de recursos do AD FS de nível empresarial, independentemente do local em que as identidades de usuário estão armazenadas. O AD FS dá suporte a todos os diretórios compatíveis com LDAP v3.
Observação
Alguns dos recursos do AD FS incluem SSO (logon único), autenticação de dispositivo, políticas de acesso condicional flexíveis, suporte para trabalhar de qualquer lugar por meio da integração com o Proxy de aplicativo Web e a federação perfeita com o Microsoft Entra, permitirá que você e seus usuários utilizem a nuvem, incluindo o Office 365 e outros aplicativos de SaaS. Para obter mais informações, consulte Visão geral dos Serviços de Federação do Active Directory (AD FS).
Para que o AD FS autentique usuários de um diretório LDAP, será necessário conectar esse diretório LDAP ao farm do AD FS criando um objeto de confiança do provedor de declarações local. Um objeto de confiança do provedor de declarações local é um objeto de confiança que representa um diretório LDAP no farm do AD FS. Um objeto de confiança do provedor de declarações local consiste em uma variedade de identificadores, nomes e regras que identificam esse diretório LDAP para o serviço de federação local.
É possível dar suporte a vários diretórios LDAP, cada um com sua própria configuração, no mesmo farm do AD FS adicionando vários objetos de confiança do provedor de declarações locais. Além disso, florestas do AD DS que não são confiáveis pela floresta em que o AD FS reside também poderão ser modeladas como objetos de confiança do provedor de declarações local. É possível criar objetos de confiança do provedor de declarações local usando o Windows PowerShell.
Diretórios LDAP (objetos de confiança do provedor de declarações local) podem coexistir com diretórios AD (objetos de confiança do provedor de declarações) no mesmo servidor AD FS, no mesmo farm do AD FS, portanto, uma única instância do AD FS poderá autenticar e autorizar o acesso a usuários armazenados em diretórios AD e não AD.
Apenas a autenticação baseada em formulários tem suporte para autenticar usuários de diretórios LDAP. Não há suporte para autenticação integrada do Windows e baseada em certificado para autenticar usuários em diretórios LDAP.
Todos os protocolos de autorização passiva com suporte do AD FS, incluindo SAML, Web Services Federation e OAuth, também têm suporte para identidades armazenadas em diretórios LDAP.
O protocolo de autorização ativa WS-Trust também tem suporte para identidades armazenadas em diretórios LDAP.
Configurar AD FS para autenticar usuários armazenados em um diretório LDAP
Para configurar o farm do AD FS para autenticar usuários de um diretório LDAP, conclua as seguintes etapas:
Primeiro, configure uma conexão com o diretório LDAP usando o cmdlet New-AdfsLdapServerConnection:
$DirectoryCred = Get-Credential $vendorDirectory = New-AdfsLdapServerConnection -HostName dirserver -Port 50000 -SslMode None -AuthenticationMethod Basic -Credential $DirectoryCredObservação
É recomendável criar um novo objeto de conexão para cada servidor LDAP que você quer conectar. O AD FS poderá conectar vários servidores LDAP de réplica e fazer failover automaticamente se um servidor LDAP específico estiver inoperante. Nesse caso, você poderá criar um AdfsLdapServerConnection para cada um desses servidores LDAP de réplica e, em seguida, adicionar a matriz de objetos de conexão usando o parâmetro -LdapServerConnection do cmdlet Add-AdfsLocalClaimsProviderTrust.
OBSERVAÇÃO: tentar usar Get-Credential e digitar um DN e uma senha a serem usados para associar a uma instância LDAP poderá resultar em falha devido ao requisito de interface do usuário para formatos de entrada específicos, por exemplo, domínio\nome de usuário ou user@domain.tld. Em vez disso, você poderá usar o cmdlet ConvertTo-SecureString conforme a seguir (o exemplo abaixo assume uid=admin,ou=system como o DN das credenciais que serão usadas para associar à instância LDAP):
$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:"Em seguida, insira a senha para uid=admin e conclua o restante das etapas.
Em seguida, você poderá executar a etapa opcional de mapeamento de atributos LDAP para as declarações do AD FS existentes usando o cmdlet New-AdfsLdapAttributeToClaimMapping. No exemplo abaixo, você mapeia os atributos GivenName, Surname e CommonName do LDAP para as declarações do 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"Esse mapeamento é feito para disponibilizar os atributos do repositório LDAP como declarações no AD FS para criar as regras de controle de acesso condicional no AD FS. Isso também permite que o AD FS funcione com esquemas personalizados em repositórios LDAP, fornecendo uma maneira fácil para mapear atributos LDAP para declarações.
Por fim, será necessário registrar o repositório LDAP com AD FS como um provedor de declarações de confiança local usando o cmdlet 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"No exemplo acima, você está criando um truste de provedor de declarações local chamado "Fornecedores". Você está especificando informações de conexão para o AD FS se conectar ao diretório LDAP que esse objeto de confiança do provedor de declarações local representa atribuindo
$vendorDirectoryao parâmetro-LdapServerConnection. Observe que, na primeira etapa, você atribuiu$vendorDirectorya uma cadeia de conexão a ser usada ao conectar o diretório LDAP específico. Por fim, você está especificando que os atributos$GivenName,$Surnamee$CommonNamedo LDAP (que você mapeou para as declarações do AD FS) deverão ser utilizados para o controle de acesso condicional, incluindo as políticas de autenticação multifator e as regras de autorização de emissão, bem como para a emissão por meio de declarações em tokens de segurança emitidos pelo AD FS. Para utilizar protocolos ativos como Ws-Trust com o AD FS, será necessário especificar o parâmetro OrganizationalAccountSuffix, que habilitará o AD FS para remover a ambiguidade entre os objetos de confiança do provedor de declarações local ao atender uma solicitação de autorização ativa.