Integrar a identidade do AD FS ao seu datacenter do Azure Stack Hub
Você pode implantar o Azure Stack Hub usando a ID do Microsoft Entra ou os Serviços de Federação do Ative Directory (AD FS) como o provedor de identidade. A escolha deve ser feita antes de implantar o Azure Stack Hub. Em um cenário conectado, você pode escolher Microsoft Entra ID ou AD FS. Para um cenário desconectado, apenas o AD FS é suportado. Este artigo mostra como integrar o Azure Stack Hub AD FS ao seu AD FS de datacenter.
Importante
Não é possível alternar o provedor de identidade sem reimplantar toda a solução do Azure Stack Hub.
Serviços de Federação e Gráfico do Ative Directory
A implantação com o AD FS permite que identidades em uma floresta existente do Ative Directory sejam autenticadas com recursos no Azure Stack Hub. Essa floresta existente do Ative Directory requer uma implantação do AD FS para permitir a criação de uma relação de confiança de federação do AD FS.
A autenticação é uma parte da identidade. Para gerenciar o controle de acesso baseado em função (RBAC) no Azure Stack Hub, o componente Graph deve ser configurado. Quando o acesso a um recurso é delegado, o componente Gráfico procura a conta de usuário na floresta existente do Ative Directory usando o protocolo LDAP.
O AD FS existente é o STS (serviço de token de segurança) de conta que envia declarações para o AD FS do Stack Hub do Azure (o STS de recurso). No Azure Stack Hub, a automação cria a confiança do provedor de declarações com o ponto de extremidade de metadados para o AD FS existente.
No AD FS existente, uma relação de confiança de terceira parte confiável deve ser configurada. Esta etapa não é feita pela automação e deve ser configurada pelo operador. O ponto de extremidade VIP do Azure Stack Hub para AD FS pode ser criado usando o padrão https://adfs.<Region>.<ExternalFQDN>/
.
A configuração de confiança da terceira parte confiável também exige que você configure as regras de transformação de declaração fornecidas pela Microsoft.
Para a configuração do Graph, deve ser fornecida uma conta de serviço que tenha permissão de "leitura" no Ative Directory existente. Essa conta é necessária como entrada para a automação habilitar cenários RBAC.
Para a última etapa, um novo proprietário é configurado para a assinatura de provedor padrão. Essa conta tem acesso total a todos os recursos quando conectada ao portal do administrador do Azure Stack Hub.
Requisitos:
Componente | Necessidade |
---|---|
Gráfico | Microsoft Ative Directory 2012/2012 R2/2016 2019 |
AD FS | Windows Server 2012/2012 R2/2016 2019 |
Configurando a integração do Graph
O Graph suporta apenas a integração com uma única floresta do Ative Directory. Se existirem várias florestas, somente a floresta especificada na configuração será usada para buscar usuários e grupos.
As seguintes informações são necessárias como entradas para os parâmetros de automação:
Parâmetro | Parâmetro da planilha de implantação | Description | Exemplo |
---|---|---|---|
CustomADGlobalCatalog |
FQDN da Floresta do AD FS | FQDN da floresta de destino do Ative Directory com a qual você deseja se integrar | Contoso.com |
CustomADAdminCredentials |
Um usuário com LDAP permissão de Ler | Serviço gráfico |
Configurar sites do Ative Directory
Para implantações do Ative Directory com vários sites, configure o Site do Ative Directory mais próximo da sua implantação do Azure Stack Hub. A configuração evita que o serviço Azure Stack Hub Graph resolva consultas usando um Servidor de Catálogo Global de um site remoto.
Adicione a sub-rede de rede VIP pública do Azure Stack Hub ao Site do Ative Directory mais próximo do Azure Stack Hub. Por exemplo, digamos que seu Ative Directory tenha dois sites: Seattle e Redmond. Se o Azure Stack Hub for implantado no site de Seattle, você adicionará a sub-rede de rede VIP pública do Azure Stack Hub ao site do Ative Directory para Seattle.
Para obter mais informações sobre sites do Ative Directory, consulte Projetando a topologia de site.
Nota
Se o Ative Directory consistir em um único site, você poderá ignorar esta etapa. Se você tiver uma sub-rede catch-all configurada, valide se a sub-rede de rede VIP pública do Azure Stack Hub não faz parte dela.
Criar conta de usuário no Ative Directory existente (opcional)
Opcionalmente, você pode criar uma conta para o serviço Graph no Ative Directory existente. Siga este passo se ainda não tiver uma conta que pretenda utilizar.
No Ative Directory existente, crie a seguinte conta de usuário (recomendação):
- Nome de usuário: graphservice
- Senha: use uma senha forte e configure a senha para nunca expirar.
Não são necessárias permissões especiais ou associação.
Acionar a automação para configurar o gráfico
Para este procedimento, use um computador em sua rede de datacenter que possa se comunicar com o ponto de extremidade privilegiado no Azure Stack Hub.
Abra uma sessão elevada do Windows PowerShell (execute como administrador) e conecte-se ao endereço IP do ponto de extremidade privilegiado. Use as credenciais do CloudAdmin para autenticar.
$creds = Get-Credential $pep = New-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
Agora que você tem uma sessão com o ponto de extremidade privilegiado, execute o seguinte comando:
Execute o script abaixo para o Azure Stack Hub build 2008 e mais recente
$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}
Execute o script abaixo para a compilação do Azure Stack Hub anterior a 2008
Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -CustomADGlobalCatalog contoso.com}
Quando solicitado, especifique a credencial para a conta de usuário que você deseja usar para o serviço Graph (como graphservice). A entrada para o cmdlet Register-DirectoryService deve ser o nome da floresta/domínio raiz na floresta e não qualquer outro domínio na floresta.
Importante
Aguarde o pop-up de credenciais (Get-Credential não é suportado no ponto de extremidade privilegiado) e insira as credenciais da Conta de Serviço do Graph.
O cmdlet Register-DirectoryService tem parâmetros opcionais que você pode usar em determinados cenários em que a validação existente do Ative Directory falha. Quando esse cmdlet é executado, ele valida que o domínio fornecido é o domínio raiz, que um servidor de catálogo global pode ser acessado e que a conta fornecida recebe acesso de leitura.
Parâmetro Description SkipRootDomainValidation
Especifica que um domínio filho deve ser usado em vez do domínio raiz recomendado. ValidateParameters
Ignora todas as verificações de validação.
Protocolos e portas de gráficos
O serviço Graph no Azure Stack Hub usa os seguintes protocolos e portas para se comunicar com um GC (Servidor de Catálogo Global) gravável e um Centro de Distribuição de Chaves (KDC) que podem processar solicitações de logon na floresta de destino do Ative Directory.
O serviço de gráfico no Azure Stack Hub usa os seguintes protocolos e portas para se comunicar com o Ative Directory de destino:
Type | Porta | Protocolo |
---|---|---|
LDAP | 389 | TCP & UDP |
LDAP SSL | 636 | TCP |
LDAP GC | 3268 | TCP |
LDAP GC SSL | 3269 | TCP |
Configurando a integração do AD FS baixando metadados de federação
As seguintes informações são necessárias como entrada para os parâmetros de automação:
Parâmetro | Parâmetro da planilha de implantação | Description | Exemplo |
---|---|---|---|
CustomAdfsName | Nome do Provedor do AD FS | Nome do provedor de declarações. Aparece assim na página de destino do AD FS. |
Contoso |
CustomAD FSFederationMetadataEndpointUri |
URI de metadados do AD FS | Link de metadados de federação. | https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml |
AssinaturaCertificadoRevocationCheck | ND | Parâmetro opcional para ignorar a verificação de CRL. | Nenhuma |
Acionar a automação para configurar a confiança do provedor de declarações no Azure Stack Hub (baixando metadados de federação)
Para este procedimento, use um computador que possa se comunicar com o ponto de extremidade privilegiado no Azure Stack Hub. Espera-se que o certificado usado pela conta STS AD FS seja confiável pelo Azure Stack Hub.
Abra uma sessão elevada do Windows PowerShell e conecte-se ao ponto de extremidade privilegiado.
$creds = Get-Credential Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
Agora que você está conectado ao ponto de extremidade privilegiado, execute o seguinte comando usando os parâmetros apropriados para seu ambiente:
Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataEndpointUri "https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml"
Execute o seguinte comando para atualizar o proprietário da assinatura de provedor padrão usando os parâmetros apropriados para seu ambiente:
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
Configurando a integração do AD FS fornecendo arquivo de metadados de federação
A partir da versão 1807, use este método se uma das seguintes condições for verdadeira:
- A cadeia de certificados é diferente para o AD FS em comparação com todos os outros pontos de extremidade no Azure Stack Hub.
- Não há conectividade de rede com o servidor AD FS existente da instância do AD FS do Azure Stack Hub.
As seguintes informações são necessárias como entrada para os parâmetros de automação:
Parâmetro | Description | Exemplo |
---|---|---|
CustomAdfsName | Nome do provedor de declarações. Aparece assim na página de destino do AD FS. | Contoso |
CustomADFSFederationMetadataFileContent | Conteúdo dos metadados. | $using:federationMetadataFileContent |
Criar arquivo de metadados de federação
Para o procedimento a seguir, você deve usar um computador que tenha conectividade de rede com a implantação existente do AD FS, que se torna o STS da conta. Os certificados necessários também devem ser instalados.
Abra uma sessão elevada do Windows PowerShell e execute o seguinte comando usando os parâmetros apropriados para seu ambiente:
$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
Copie o arquivo de metadados para um computador que possa se comunicar com o ponto de extremidade privilegiado.
Acionar a automação para configurar a confiança do provedor de declarações no Azure Stack Hub (usando o arquivo de metadados de federação)
Para este procedimento, use um computador que possa se comunicar com o ponto de extremidade privilegiado no Azure Stack Hub e tenha acesso ao arquivo de metadados criado em uma etapa anterior.
Abra uma sessão elevada do Windows PowerShell e conecte-se ao ponto de extremidade privilegiado.
$federationMetadataFileContent = get-content c:\metadata.xml $creds=Get-Credential Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
Agora que você está conectado ao ponto de extremidade privilegiado, execute o seguinte comando usando os parâmetros apropriados para seu ambiente:
Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent
Execute o seguinte comando para atualizar o proprietário da assinatura do provedor padrão. Use os parâmetros apropriados para seu ambiente.
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
Nota
Ao girar o certificado no AD FS (STS de conta) existente, você deve configurar a integração do AD FS novamente. Você deve configurar a integração mesmo se o ponto de extremidade de metadados estiver acessível ou tiver sido configurado fornecendo o arquivo de metadados.
Configurar a terceira parte confiável na implantação existente do AD FS (STS da conta)
A Microsoft fornece um script que configura a confiança da terceira parte confiável, incluindo as regras de transformação de declaração. O uso do script é opcional, pois você pode executar os comandos manualmente.
Você pode baixar o script auxiliar das Ferramentas do Hub de Pilha do Azure no GitHub.
Se decidir executar manualmente os comandos, siga estes passos:
Copie o seguinte conteúdo para um arquivo de .txt (por exemplo, salvo como c:\ClaimIssuanceRules.txt) na instância do AD FS ou no membro do farm do datacenter:
@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);
Valide se a autenticação baseada em Windows Forms para extranet e intranet está habilitada. Você pode verificar se já está habilitado executando o seguinte cmdlet:
Get-AdfsAuthenticationProvider | where-object { $_.name -eq "FormsAuthentication" } | select Name, AllowedForPrimaryExtranet, AllowedForPrimaryIntranet
Nota
As cadeias de caracteres de agente do usuário com suporte da Autenticação Integrada do Windows (WIA) podem estar desatualizadas para sua implantação do AD FS e podem exigir uma atualização para oferecer suporte aos clientes mais recentes. Você pode ler mais sobre como atualizar as cadeias de caracteres do agente do usuário suportadas pelo WIA no artigo Configurando a autenticação baseada em formulários da intranet para dispositivos que não suportam WIA.
Para conhecer as etapas para habilitar a política de autenticação baseada em formulário, consulte Configurar políticas de autenticação.Para adicionar a confiança da terceira parte confiável, execute o seguinte comando do Windows PowerShell em sua instância do AD FS ou em um membro do farm. Certifique-se de atualizar o ponto de extremidade do AD FS e aponte para o arquivo criado na Etapa 1.
Importante
Para clientes que executam o Azure Stack Hub versões 2002 e posteriores, o TLS 1.2 é imposto no ponto de extremidade ADFS do Azure Stack Hub. Como tal, o TLS 1.2 também deve ser habilitado nos servidores ADFS do cliente. Caso contrário, o seguinte erro ocorrerá ao ser executado
Add-ADFSRelyingPartyTrust
no host/farm do ADFS de propriedade do cliente:Add-ADFSRelyingPartyTrust : The underlying connection was closed: An unexpected error occurred on a send.
Para o 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
Para AD FS 2012/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
Importante
Você deve usar o snap-in MMC do AD FS para configurar as Regras de Autorização de Emissão ao usar o AD FS do Windows Server 2012 ou 2012 R2.
Ao usar o Internet Explorer ou o navegador Microsoft Edge para acessar o Azure Stack Hub, você deve ignorar as associações de token. Caso contrário, as tentativas de início de sessão falharão. Na instância do AD FS ou em um membro do farm, execute o seguinte comando:
Nota
Esta etapa não é aplicável ao usar o AD FS do Windows Server 2012 ou 2012 R2. Nesse caso, é seguro pular esse comando e continuar com a integração.
Set-AdfsProperties -IgnoreTokenBinding $true
Criação do SPN
Há muitos cenários que exigem o uso de um SPN (nome da entidade de serviço) para autenticação. Seguem-se alguns exemplos:
- Uso da CLI do Azure com a implantação do AD FS do Azure Stack Hub.
- Pacote de Gerenciamento do System Center para Azure Stack Hub quando implantado com o AD FS.
- Provedores de recursos no Azure Stack Hub quando implantados com o AD FS.
- Várias aplicações.
- Necessita de um início de sessão não interativo.
Importante
O AD FS só suporta sessões de início de sessão interativas. Se você precisar de uma entrada não interativa para um cenário automatizado, deverá usar um SPN.
Para obter mais informações sobre como criar um SPN, consulte Criar entidade de serviço para AD FS.
Resolução de Problemas
Reversão de configuração
Se ocorrer um erro que deixe o ambiente em um estado em que você não pode mais autenticar, uma opção de reversão estará disponível.
Abra uma sessão elevada do Windows PowerShell e execute os seguintes comandos:
$creds = Get-Credential Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
Em seguida, execute o seguinte cmdlet:
Reset-DatacenterIntegrationConfiguration
Depois de executar a ação de reversão, todas as alterações de configuração são revertidas. Somente a autenticação com o usuário integrado do CloudAdmin é possível.
Importante
Você deve configurar o proprietário original da assinatura de provedor padrão.
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "azurestackadmin@[Internal Domain]"
Coletando logs adicionais
Se algum dos cmdlets falhar, você poderá coletar logs adicionais usando o Get-Azurestacklogs
cmdlet.
Abra uma sessão elevada do Windows PowerShell e execute os seguintes comandos:
$creds = Get-Credential Enter-pssession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
Em seguida, execute o seguinte cmdlet:
Get-AzureStackLog -OutputPath \\myworkstation\AzureStackLogs -FilterByRole ECE