Compartilhar via

Configurar uma relação de confiança na nuvem entre o AD DS local e o Microsoft Entra ID para acessar Arquivos do Azure

  • Artigo

Muitas organizações desejam usar a autenticação baseada em identidade para compartilhamentos de arquivos SMB do Azure em ambientes que abrangem o AD DS local e o Microsoft Entra ID (anteriormente Azure Active Directory), mas não atendem aos pré-requisitos de domínio ou sistema operacional necessários.

Nesses cenários, os clientes podem habilitar a autenticação Kerberos do Microsoft Entra para identidades de usuário híbrido e, em seguida, estabelecer uma relação de confiança na nuvem entre o AD DS local e o Microsoft Entra ID para acessar compartilhamentos de arquivos SMB usando suas credenciais locais. Este artigo explica como funciona uma relação de confiança na nuvem e fornece instruções para configuração e validação. Ele também inclui etapas para girar uma chave Kerberos para a conta de serviço no Microsoft Entra ID e no Objeto de domínio confiável, além de etapas para remover um Objeto de domínio confiável e todas as configurações Kerberos, se desejado.

Este artigo se concentra na autenticação de identidades de usuário híbrido, que são identidades locais do AD DS sincronizadas com o Microsoft Entra ID usando o Microsoft Entra Connect ou a sincronização de nuvem do Microsoft Entra Connect. No momento não há suporte para as Identidades somente na nuvem no Arquivos do Azure.

Aplica-se a

Tipo de compartilhamento de arquivos SMB NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS Sim Não
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS Sim Não
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS Sim No

Cenários

Confira a seguir exemplos de cenários nos quais você pode desejar configurar uma relação de confiança na nuvem:

  • Você tem um AD DS local tradicional, mas não pode usar para autenticação porque não tem conectividade de rede irrestrita com os controladores de domínio.

  • Você começou a migrar para a nuvem, mas atualmente ainda tem aplicativos em execução no AD DS local tradicional.

  • Alguns ou todos os computadores cliente não atendem aos requisitos do sistema operacional para obter a autenticação Kerberos do Microsoft Entra.

Permissões

Para concluir as etapas descritas nesse artigo, será necessário:

  • Um nome de usuário e senha de administrador local do Active Directory
  • Nome de usuário e senha da conta de administrador global do Microsoft Entra

Pré-requisitos

Antes de implementar o fluxo de autenticação baseado em confiança de entrada, verifique se os pré-requisitos a seguir são atendidos:

Pré-requisito Descrição
O cliente deve executar o Windows 10, Windows Server 2012 ou uma versão superior do Windows.
Clientes devem ser ingressados no Active Directory (AD). O domínio deve ter um nível funcional de Windows Server 2012 ou superior. É possível determinar se o cliente está ingressado no AD executando o comando dsregcmd: dsregcmd.exe /status
Um locatário do Microsoft Entra. Um locatário do Microsoft Entra é um limite de segurança de identidade que é controlado pelo departamento de TI da sua organização. Essa é uma instância do Microsoft Entra ID na qual residem informações sobre uma única organização.
Uma Assinatura do Azure no mesmo locatário do Microsoft Entra que você planeja usar para autenticação.
Uma conta de armazenamento do Azure na assinatura do Azure. Uma conta de armazenamento do Azure é um recurso que atua como um contêiner para agrupar todos os serviços de dados do Armazenamento do Azure, incluindo arquivos.
O Microsoft Entra Connect ou a Sincronização na nuvem do Microsoft Entra Connect deve ser instalado. Essas soluções são usadas em ambientes híbridos nos quais existem identidades tanto no Microsoft Entra ID quanto no AD DS local.

Habilitar a autenticação Kerberos do Microsoft Entra

Se você já tiver habilitado a autenticação Kerberos do Microsoft Entra em sua conta de armazenamento, ignore esta etapa e continue para Criar e configurar o Objeto de domínio confiável Kerberos do Microsoft Entra.

Você pode habilitar a autenticação Kerberos para Microsoft Entra nos Arquivos do Azure para contas de usuário híbridas usando o portal do Azure, o PowerShell ou a CLI do Azure.

Para habilitar a autenticação Kerberos para Microsoft Entra usando o portal do Azure, siga estas etapas.

  1. Entre no portal do Azure e selecione a conta de armazenamento para a qual você deseja habilitar a autenticação Kerberos para Microsoft Entra.

  2. Em Armazenamento de dados, selecione Compartilhamentos de arquivos.

  3. Ao lado do Active Directory, selecione o status de configuração (por exemplo, Não configurado).

    Captura de tela do portal do Azure mostrando as configurações de compartilhamento de arquivos para uma conta de armazenamento. As definições de configuração do Active Directory estão selecionadas.

  4. Em Kerberos para Microsoft Entra, selecione Configurar.

  5. Marque a caixa de seleção Kerberos para Microsoft Entra.

    Captura de tela do portal do Azure mostrando as configurações do Active Directory para uma conta de armazenamento. O Kerberos do Microsoft Entra está selecionado.

  6. Opcional: se você quiser configurar permissões de diretório e de nível de arquivo por meio do Explorador de Arquivos do Windows, especifique o nome de domínio e o GUID de domínio para o AD local. Você pode obter essas informações com o administrador de domínio ou executando os seguintes cmdlets do PowerShell do Active Directory de um cliente ingressado no AD local: Get-ADDomain. O nome de domínio deve ser listado na saída em DNSRoot e o GUID do domínio deve ser listado em ObjectGUID. Se você preferir configurar permissões de diretório e de nível de arquivo usando icacls, ignore esta etapa. No entanto, se você quiser usar icacls, o cliente precisará de uma conectividade de rede sem impedimentos para o AD local.

  7. Selecione Salvar.

Aviso

Se você já habilitou a autenticação do Kerberos para Microsoft Entra por meio das etapas manuais limitadas anteriores para armazenar perfis FSLogix nos Arquivos do Azure para VMs ingressadas no Microsoft Entra, a senha da entidade de serviço da conta de armazenamento será definida para expirar a cada seis meses. Depois que a senha expirar, os usuários não poderão obter os tíquetes do Kerberos para o compartilhamento de arquivo. Para mitigar esse comportamento, confira "Erro – A senha da entidade de serviço expirou no Microsoft Entra ID" em Possíveis erros ao habilitar a autenticação Kerberos para Microsoft Entra para usuários híbridos.

Depois de habilitar a autenticação Kerberos para Microsoft Entra, você precisará dar o consentimento do administrador explicitamente ao novo aplicativo do Microsoft Entra registrado em seu locatário do Microsoft Entra. Essa entidade de serviço é gerada automaticamente e não é usada para autorização para o compartilhamento de arquivos, portanto, não faça nenhuma edição para a entidade de serviço diferente daquelas documentadas aqui. Se você fizer isso, poderá receber um erro.

Você pode configurar as permissões de API do portal do Azure seguindo estas etapas:

  1. Abra o Microsoft Entra ID.
  2. No o menu de serviço, em Gerenciar, selecione a opção Registros de aplicativo.
  3. Selecionar Todos os Aplicativos.
  4. Selecione o aplicativo com o nome correspondente a [conta de armazenamento] <your-storage-account-name>.file.core.windows.net.
  5. No menu de serviço, em Gerenciar, selecione Permissões da API.
  6. Selecione Conceder consentimento do administrador para [Nome do Diretório] para conceder consentimento para as três permissões de API solicitadas (openid, profile e User.Read) para todas as contas no diretório.
  7. Clique em Sim para confirmar.

Importante

Se você estiver se conectando a uma conta de armazenamento por meio de um ponto de extremidade privado/link privado usando a autenticação Kerberos para Microsoft Entra, também precisará adicionar o FQDN de link privado ao aplicativo do Microsoft Entra da conta de armazenamento. Para obter instruções, consulte a entrada em nosso guia de solução de problemas.

Desabilitar a autenticação multifator na conta de armazenamento

O Kerberos para Microsoft Entra não dá suporte ao uso de MFA para acessar compartilhamentos de arquivos do Azure configurados com Kerberos para Microsoft Entra. Você deve excluir o aplicativo do Microsoft Entra que representa sua conta de armazenamento de suas políticas de acesso condicional da MFA se elas se aplicarem a todos os aplicativos.

O aplicativo de conta de armazenamento deve ter o mesmo nome que a conta de armazenamento na lista de exclusão de acesso condicional. Ao pesquisar o aplicativo da conta de armazenamento na lista de exclusão de acesso condicional, pesquise: [conta de armazenamento] <your-storage-account-name>.file.core.windows.net

Lembre-se de substituir <your-storage-account-name> pelo valor adequado.

Importante

Se você não excluir as políticas de MFA do aplicativo de conta de armazenamento, não será possível acessar o compartilhamento de arquivo. Tentar mapear o compartilhamento de arquivos usando o net use resultará em uma mensagem de erro que diz "Erro do sistema 1327: as restrições de conta estão impedindo esse usuário de entrar. Por exemplo: senhas em branco não são permitidas, os horários de entrada são limitados ou uma restrição de política foi imposta."

Para obter diretrizes sobre como desabilitar a MFA, confira o seguinte:

Atribuir permissões de níveis de compartilhamento

Ao habilitar o acesso baseado em identidade, você pode definir para cada compartilhamento quais usuários e grupos têm acesso a esse compartilhamento específico. Depois que um usuário ou grupo é permitido em um compartilhamento, as ACLs do Windows (também chamadas de permissões NTFS) em arquivos e diretórios individuais assumem o controle. Isso permite o controle refinado sobre permissões, semelhante a um compartilhamento SMB em um Windows Server.

Para definir permissões de nível de compartilhamento, siga as instruções em Atribuir permissões de nível de compartilhamento a uma identidade.

Configurar permissões de diretório e de nível de arquivo

Depois que as permissões de nível de compartilhamento estiverem em vigor, atribua permissões de nível de diretório/arquivo ao usuário ou grupo. Isso requer o uso de um dispositivo com uma conectividade de rede sem impedimentos para um AD local.

Para configurar permissões de diretório e de nível de arquivo, siga as instruções em Configurar permissões de diretório e de nível de arquivo por SMB.

Criar e configurar o objeto de domínio confiável Kerberos do Microsoft Entra

Para criar e configurar o Objeto de domínio confiável Kerberos do Microsoft Entra, você usará o módulo do PowerShell de Gerenciamento de autenticação híbrida do Azure AD. Este módulo permite que as organizações de identidade híbrida usem credenciais modernas para seus aplicativos e permite que o Microsoft Entra ID se torne a fonte confiável para autenticação local e na nuvem.

Configurar o Objeto de Domínio Confiável

Você usará o módulo do PowerShell de Gerenciamento de autenticação híbrida do Azure AD para configurar um Objeto de domínio confiável no domínio do AD local e registrar informações de confiança no Microsoft Entra ID. Isso cria uma relação de confiança de entrada no AD local, que permite que o Microsoft Entra ID confie no AD local.

Você só precisa configurar o Objeto de domínio confiável uma vez por domínio. Se você já fez isso em seu domínio, ignore esta seção e continue para configurar os clientes para recuperar tíquetes Kerberos.

Instalar o módulo do PowerShell de Gerenciamento de Autenticação Híbrida do Azure AD

  1. Inicie uma sessão do Windows PowerShell com a opção Executar como administrador.

  2. Instalar o módulo do PowerShell de Gerenciamento de Autenticação Híbrida do Azure AD usando o script a seguir. O script:

    • Habilita o TLS 1.2 para comunicação.
    • Instala o provedor do pacote NuGet.
    • Registra o repositório PSGallery.
    • Instala o módulo PowerShellGet.
    • Instala o módulo do PowerShell de Gerenciamento de Autenticação Híbrida do Azure AD.
      • O PowerShell de Gerenciamento de autenticação híbrida do Azure AD usa o módulo AzureADPreview, que fornece o recursos avançados de gerenciamento do Microsoft Azure.
      • Para proteger contra conflitos de instalação desnecessários com o módulo do PowerShell do Azure AD, esse comando inclui o sinalizador de opção -AllowClobber.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-PackageProvider -Name NuGet -Force

if (@(Get-PSRepository | ? {$_.Name -eq "PSGallery"}).Count -eq 0){
    Register-PSRepository -DefaultSet-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}

Install-Module -Name PowerShellGet -Force

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Criar o Objeto de Domínio Confiável

  1. Inicie uma sessão do Windows PowerShell com a opção Executar como administrador.

  2. Defina os parâmetros comuns. Personalize o script abaixo antes de ser executado.

    • De definir o parâmetro $domain como seu Active Directory local de domínio.
    • Quando solicitado por Get-Credential, insira um nome de usuário e senha do administrador local do Active Directory.
    • Definir o parâmetro $cloudUserName como o nome de usuário de uma conta com privilégios de Administrador Global para acesso à nuvem do Microsoft Entra.

    Observação

    Se você quiser usar sua conta de Windows de logon atual para seu acesso Active Directory local, ignore a etapa em que as credenciais são atribuídas ao parâmetro $domainCred. Se você seguir essa abordagem, não inclua o parâmetro -DomainCredential nos comandos do PowerShell após esta etapa.

    $domain = "your on-premesis domain name, for example contoso.com"

$domainCred = Get-Credential

$cloudUserName = "Azure AD user principal name, for example admin@contoso.onmicrosoft.com"

  3. Verifique o domínio kerberos atual Configurações.

    Execute o seguinte comando para verificar as configurações atuais do Kerberos do seu domínio:

    Get-AzureAdKerberosServer -Domain $domain `
    -DomainCredential $domainCred `
    -UserPrincipalName $cloudUserName

    Se esta for a primeira vez que você chama um comando Kerberos no Microsoft Entra, você será solicitado a acessar o Microsoft Entra na nuvem.

    • Insira a senha da conta de administrador global do Microsoft Entra.
    • Se sua organização usar outros métodos de autenticação modernos, como a autenticação multifator do Microsoft Entra ou o Cartão Inteligente, siga as instruções conforme solicitado para entrar.

    Se esta for a primeira vez que você estiver definindo as configurações do Kerberos do Microsoft Entra, o cmdlet Get-AzureAdKerberosServer exibirá informações vazias, como na seguinte saída de exemplo:

    ID                  :
UserAccount         :
ComputerAccount     :
DisplayName         :
DomainDnsName       :
KeyVersion          :
KeyUpdatedOn        :
KeyUpdatedFrom      :
CloudDisplayName    :
CloudDomainDnsName  :
CloudId             :
CloudKeyVersion     :
CloudKeyUpdatedOn   :
CloudTrustDisplay   :

    Se o domínio já dá suporte à autenticação FIDO, o cmdlet Get-AzureAdKerberosServer exibirá informações da conta de Serviço do Azure AD, como na saída de exemplo a seguir. O campo CloudTrustDisplay retorna um valor vazio.

    ID                  : XXXXX
UserAccount         : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com
ComputerAccount     : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com
DisplayName         : XXXXXX_XXXXX
DomainDnsName       : contoso.com
KeyVersion          : 53325
KeyUpdatedOn        : 2/24/2024 9:03:15 AM
KeyUpdatedFrom      : ds-aad-auth-dem.contoso.com
CloudDisplayName    : XXXXXX_XXXXX
CloudDomainDnsName  : contoso.com
CloudId             : XXXXX
CloudKeyVersion     : 53325
CloudKeyUpdatedOn   : 2/24/2024 9:03:15 AM
CloudTrustDisplay   :

  4. Adicione o Objeto de Domínio Confiável.

    Execute o cmdlet Set-AzureAdKerberosServer do PowerShell para adicionar o Objeto de Domínio Confiável. Certifique-se de incluir o parâmetro -SetupCloudTrust. Esse comando criará uma nova conta de serviço do Microsoft Entra, caso não exista nenhuma. Este comando só criará o objeto de domínio confiável solicitado se existir uma conta de serviço do Microsoft Entra.

    Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -DomainCredential $domainCred -SetupCloudTrust

    Observação

    Em uma floresta de vários domínios, para evitar o erro LsaCreateTrustedDomainEx 0x549 ao executar o comando em um domínio filho:

    1. Execute o comando no domínio raiz (inclui o parâmetro -SetupCloudTrust).
    2. Execute o mesmo comando no domínio filho, sem o parâmetro -SetupCloudTrust.

    Depois de criar o Objeto de Domínio Confiável, você pode verificar o Configurações Kerberos Get-AzureAdKerberosServer atualizado usando o cmdlet do PowerShell, conforme mostrado na etapa anterior. Se o cmdlet Set-AzureAdKerberosServer tiver sido executado com êxito com o parâmetro -SetupCloudTrust, o campo CloudTrustDisplay agora deverá retornar Microsoft.AzureAD.Kdc.Service.TrustDisplay, como na seguinte saída de exemplo:

    ID                  : XXXXX
UserAccount         : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com
ComputerAccount     : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com
DisplayName         : XXXXXX_XXXXX
DomainDnsName       : contoso.com
KeyVersion          : 53325
KeyUpdatedOn        : 2/24/2024 9:03:15 AM
KeyUpdatedFrom      : ds-aad-auth-dem.contoso.com
CloudDisplayName    : XXXXXX_XXXXX
CloudDomainDnsName  : contoso.com
CloudId             : XXXXX
CloudKeyVersion     : 53325
CloudKeyUpdatedOn   : 2/24/2024 9:03:15 AM
CloudTrustDisplay   : Microsoft.AzureAD.Kdc.Service.TrustDisplay

    Observação

    As nuvens soberanas do Azure exigem a configuração da propriedade TopLevelNames, que é definida como windows.net por padrão. As implantações de nuvem soberana da Instância Gerenciada de SQL do Azure usam um nome de domínio primário, como usgovcloudapi.net para o Azure Governamental para os EUA. Defina o objeto de domínio confiável para esse nome de domínio primário usando o seguinte comando do PowerShell: Set-AzureADKerberosServer -Domain $domain -DomainCredential $domainCred -CloudCredential $cloudCred -SetupCloudTrust -TopLevelNames "usgovcloudapi.net,windows.net". Você pode verificar a configuração com o seguinte comando do PowerShell: Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName | Select-Object -ExpandProperty CloudTrustDisplay.

Configurar os clientes para recuperar tíquetes do Kerberos

Identifique sua ID de locatário do Microsoft Entra e use a Política de Grupo para configurar os computadores cliente dos quais você deseja montar/usar compartilhamentos de Arquivos do Azure. Faça isso em cada cliente em que os Arquivos do Azure serão usados.

Configure essa política de grupo no(s) cliente(s) como "Habilitada": Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

  1. Implante a seguinte configuração Política de Grupo em máquinas cliente usando o fluxo baseado em relação de confiança de entrada:

    1. Edite a configuração de política Modelos Administrativos\System\Kerberos\Especificar servidores proxy KDC para clientes Kerberos.

    2. Selecione Habilitado.

    3. Em Opções, selecione Mostrar.... Isso abre a caixa de diálogo Mostrar Conteúdo.

      Captura de tela da caixa de diálogo para habilitar 'Especificar servidores proxy KDC para clientes Kerberos'. O diálogo 'Mostrar conteúdo' permite inserir um nome do valor e o valor relacionado.

    4. Defina as configurações de servidores proxy KDC usando mapeamentos da seguinte forma. Substitua sua ID de locatário do Microsoft Entra pelo espaço reservadoyour_Azure_AD_tenant_id. Observe o espaço que segue https e o espaço antes do fechamento / no mapeamento de valor.

      Nome do valor Valor
      KERBEROS.MICROSOFTONLINE.COM <https login.microsoftonline.com:443:your_Azure_AD_tenant_id/kerberos />

      Captura de tela da caixa de diálogo 'Definir configurações do servidor proxy KDC'. Uma tabela permite inserir várias linhas. Cada linha consiste em um nome do valor e um valor.

    5. Selecione OK para fechar a caixa de diálogo ' Mostrar conteúdo '.

    6. Selecione Aplicar na caixa de diálogo ' Especificar servidores proxy KDC para clientes Kerberos '.

Girar a chave Kerberos

É possível girar periodicamente a chave Kerberos para a conta de serviço do Microsoft Entra criada e o objeto de domínio confiável para fins de gerenciamento.

Set-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName -SetupCloudTrust `
   -RotateServerKey

Depois que a chave é girada, leva várias horas para propagar a chave alterada entre os servidores KDC Kerberos. Devido a esse tempo de distribuição de chave, você pode girar a chave uma vez dentro de 24 horas. Se precisar girar a chave novamente dentro de 24 horas por algum motivo, por exemplo, logo após a criação do objeto de domínio confiável, poderá adicionar o parâmetro -Force:

Set-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName -SetupCloudTrust `
   -RotateServerKey -Force

Remova o Objeto de Domínio Confiável

E possível remover o Objeto de Domínio Confiável adicionado usando o seguinte comando:

Remove-AzureADKerberosServerTrustedDomainObject -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName

Esse comando removerá apenas o Objeto de Domínio Confiável. Se o domínio for compatível com a autenticação FIDO, você poderá remover o objeto de domínio confiável ao mesmo tempo em que mantém a conta de serviço do Microsoft Entra necessária para o serviço de autenticação FIDO.

Remover todos os Configurações Kerberos

É possível remover a conta de serviço do Microsoft Entra e o objeto de domínio confiável usando o seguinte comando:

Remove-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName

Próxima etapa