Partilhar via


Configurar uma confiança na nuvem entre o AD DS local e a ID do Microsoft Entra para aceder aos Ficheiros do Azure

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

Nesses cenários, os clientes podem habilitar a autenticação Kerberos do Microsoft Entra para identidades de usuário híbridas e, em seguida, estabelecer uma confiança na nuvem entre o AD DS local e a ID do Microsoft Entra 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 sua conta de serviço no Microsoft Entra ID e Objeto de Domínio Confiável, e 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íbridas, que são identidades do AD DS local sincronizadas com a ID do Microsoft Entra usando a sincronização na nuvem do Microsoft Entra Connect ou do Microsoft Entra Connect. Atualmente, não há suporte para identidades somente na nuvem para Arquivos do Azure.

Aplica-se a

Tipo de partilhas de ficheiros SMB NFS
Partilhas de ficheiros Standard (GPv2), LRS/ZRS Yes No
Partilhas de ficheiros Standard (GPv2), GRS/GZRS Yes No
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS Yes No

Cenários

Seguem-se exemplos de cenários em que poderá querer configurar uma relação de confiança na nuvem:

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

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

  • Algumas ou todas as máquinas cliente não atendem aos requisitos do sistema operacional para autenticação do Microsoft Entra Kerberos.

Permissões

Para concluir as etapas descritas neste artigo, você precisará:

  • Um nome de usuário e senha de administrador do Ative Directory local
  • Nome de utilizador e palavra-passe 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 seguintes pré-requisitos são atendidos:

Pré-requisito Descrição
O cliente tem de ter o Windows 10, o Windows Server 2012 ou uma versão superior do Windows.
Os clientes devem ser associados ao Ative Directory (AD). O domínio tem de ter um nível funcional do Windows Server 2012 ou superior. Pode determinar se o cliente está associado ao AD ao executar o comando dsregcmd: dsregcmd.exe /status
Um locatário do Microsoft Entra. Um Locatário Microsoft Entra é um limite de segurança de identidade que está sob o controle do departamento de TI da sua organização. É uma instância do Microsoft Entra ID na qual residem informações sobre uma única organização.
Uma assinatura do Azure sob o 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.
A sincronização na nuvem do Microsoft Entra Connect ou do Microsoft Entra Connect deve estar instalada. Essas soluções são usadas em ambientes híbridos onde as identidades existem tanto no Microsoft Entra ID quanto no AD DS local.

Habilitar a autenticação Kerberos do Microsoft Entra

Se já tiver ativado a autenticação Kerberos do Microsoft Entra na sua conta de armazenamento, pode ignorar este passo e prosseguir para Criar e configurar o Objeto de Domínio Fidedigno Kerberos do Microsoft Entra.

Você pode habilitar a autenticação Kerberos do 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 do Microsoft Entra Kerberos usando o portal do Azure, siga estas etapas.

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

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

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

    Captura de ecrã do portal do Azure a mostrar definições de partilha de ficheiros para uma conta de armazenamento. As definições de configuração do Ative Directory são selecionadas.

  4. Em Microsoft Entra Kerberos, selecione Configurar.

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

    Captura de ecrã do portal do Azure a mostrar as definições de configuração do Ative Directory para uma conta de armazenamento. Microsoft Entra Kerberos está selecionado.

  6. Opcional: Se desejar configurar permissões de diretório e nível de arquivo por meio do Explorador de Arquivos do Windows, especifique o nome de domínio e o GUID do domínio para seu AD local. Você pode obter essas informações do administrador do domínio ou executando o seguinte cmdlet do PowerShell do Ative Directory a partir de um cliente local associado ao AD: Get-ADDomain. Seu nome de domínio deve ser listado na saída em DNSRoot e seu GUID de domínio deve ser listado em ObjectGUID. Se preferir configurar permissões de diretório e nível de arquivo usando icacls, ignore esta etapa. No entanto, se você quiser usar icacls, o cliente precisará de conectividade de rede desimpedida para o AD local.

  7. Selecione Guardar.

Aviso

Se você habilitou anteriormente a autenticação do Microsoft Entra Kerberos por meio de etapas manuais de visualização limitada 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 está definida para expirar a cada seis meses. Quando a senha expirar, os usuários não poderão obter tíquetes Kerberos para o compartilhamento de arquivos. Para atenuar isso, consulte "Erro - A senha da entidade de serviço expirou no ID do Microsoft Entra" em Possíveis erros ao habilitar a autenticação Kerberos do Microsoft Entra para usuários híbridos.

Depois de habilitar a autenticação do Microsoft Entra Kerberos, você precisará conceder explicitamente o consentimento de administrador para o novo aplicativo 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 na entidade de serviço além das documentadas aqui. Se o fizer, 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 menu de serviço, em Gerir, selecione Registos de aplicações.
  3. Selecione 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 de API.
  6. Selecione Conceder consentimento de 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. Selecione 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 do Microsoft Entra, também precisará adicionar o FQDN de link privado ao aplicativo Microsoft Entra da conta de armazenamento. Para obter instruções, consulte a entrada em nosso guia de solução de problemas.

Desativar a autenticação multifator na conta de armazenamento

O Microsoft Entra Kerberos não oferece suporte ao uso de MFA para acessar compartilhamentos de arquivos do Azure configurados com o Microsoft Entra Kerberos. Você deve excluir o aplicativo Microsoft Entra que representa sua conta de armazenamento de suas políticas de acesso condicional de 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 procurar o aplicativo de 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 políticas de MFA do aplicativo de conta de armazenamento, não poderá acessar o compartilhamento de arquivos. Tentar mapear o compartilhamento de arquivos usando net use resultará em uma mensagem de erro que diz "Erro de sistema 1327: restrições de conta estão impedindo este usuário de entrar. Por exemplo: senhas em branco não são permitidas, os tempos de entrada são limitados ou uma restrição de política foi imposta."

Para obter orientações sobre a desativação da AMF, consulte o seguinte:

Atribuir permissões ao nível da partilha

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

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 nível de arquivo

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

Para configurar permissões de diretório e nível de arquivo, siga as instruções em Configurar permissões de diretório e nível de arquivo sobre 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 PowerShell de Gerenciamento de Autenticação Híbrida do Azure AD. Este módulo permite que 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 na nuvem e local.

Configurar o objeto de domínio confiável

Você usará o módulo 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 com a ID do Microsoft Entra. 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á tiver feito isso para seu domínio, ignore esta seção e prossiga para Configurar os clientes para recuperar tíquetes Kerberos.

Instalar o módulo 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. Instale o módulo 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 de pacotes NuGet.
    • Registra o repositório PSGallery.
    • Instala o módulo PowerShellGet.
    • Instala o módulo 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 recursos avançados de gerenciamento do Microsoft Entra.
      • Para proteger contra conflitos de instalação desnecessários com o módulo Azure AD PowerShell, este comando inclui o sinalizador de -AllowClobber opção.
[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 executá-lo.

    • Defina o $domain parâmetro como seu nome de domínio do Ative Directory local.
    • Quando solicitado pelo Get-Credential, insira um nome de usuário e uma senha de administrador do Ative Directory local.
    • Defina o parâmetro como o nome de usuário de uma conta privilegiada de Administrador Global para acesso à $cloudUserName nuvem do Microsoft Entra.

    Nota

    Se desejar usar sua conta de login atual do Windows para seu acesso ao Ative Directory local, ignore a etapa em que as $domainCred credenciais são atribuídas ao parâmetro. Se você adotar essa abordagem, não inclua o -DomainCredential parâmetro nos comandos do PowerShell seguindo 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 as configurações de domínio Kerberos atuais.

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

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

    Se esta for a primeira vez que chamará qualquer comando do Microsoft Entra Kerberos, você será solicitado para o acesso à nuvem do Microsoft Entra.

    • Introduza a palavra-passe da sua conta de Administrador Global do Microsoft Entra.
    • Se a sua organização usa outros métodos de autenticação modernos, como a autenticação multifator Microsoft Entra ou o Smart Card, siga as instruções solicitadas para entrar.

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

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

    Se o seu domínio já oferecer suporte à autenticação FIDO, o cmdlet exibirá as informações da Get-AzureAdKerberosServer conta de serviço do Microsoft Entra, como na saída de exemplo a seguir. O CloudTrustDisplay campo 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 PowerShell para adicionar o Objeto de Domínio Confiável. Certifique-se de incluir -SetupCloudTrust o parâmetro. Se não houver uma conta de serviço do Microsoft Entra, esse comando criará uma nova conta de serviço do Microsoft Entra. Este comando só criará o objeto Domínio Confiável solicitado se houver uma conta de serviço do Microsoft Entra.

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

    Nota

    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 (parâmetro include -SetupCloudTrust ).
    2. Execute o mesmo comando no domínio filho sem o -SetupCloudTrust parâmetro.

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

    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
    

    Nota

    As nuvens soberanas do Azure exigem a configuração da TopLevelNames propriedade, que é definida por windows.net padrão. As implantações de nuvem soberana do Azure da Instância Gerenciada do SQL usam um nome de domínio de nível superior diferente, como usgovcloudapi.net para o Azure US Government. Defina seu Objeto de Domínio Confiável para esse nome de domínio de nível superior 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 Kerberos

Identifique sua ID de locatário do Microsoft Entra e use a Política de Grupo para configurar a(s) máquina(s) cliente(s) a partir da(s) qual(is) você deseja montar/usar compartilhamentos de Arquivos do Azure. Você deve fazer isso em cada cliente no qual os Arquivos do Azure serão usados.

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

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

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

    2. Selecione Ativado.

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

      Captura de ecrã da caixa de diálogo para ativar 'Especificar servidores proxy KDC para clientes Kerberos'. A caixa de diálogo 'Mostrar conteúdo' permite a entrada de um nome de valor e o valor relacionado.

    4. Defina as configurações dos servidores proxy KDC usando mapeamentos da seguinte maneira. Substitua sua ID de locatário do your_Azure_AD_tenant_id Microsoft Entra pelo espaço reservado. Observe o espaço a seguir https e antes do fechamento / no mapeamento de valores.

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

      Captura de ecrã da caixa de diálogo 'Definir definições do servidor proxy KDC'. Uma tabela permite a entrada de várias linhas. Cada linha consiste em um nome de 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

Você pode alternar periodicamente a Chave Kerberos para a conta de serviço 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 este tempo de distribuição de chaves, você pode girar a chave uma vez dentro de 24 horas. Se você precisar girar a chave novamente dentro de 24 horas por qualquer motivo, por exemplo, logo após a criação do Objeto de Domínio Confiável, você pode adicionar o -Force parâmetro:

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

Remover o objeto de domínio confiável

Você pode remover o Objeto de Domínio Confiável adicionado usando o seguinte comando:

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

Este comando removerá apenas o Objeto de Domínio Confiável. Se o seu domínio suportar a autenticação FIDO, pode remover o Objeto de Domínio Fidedigno enquanto mantém a conta de serviço Microsoft Entra necessária para o serviço de autenticação FIDO.

Remover todas as configurações do Kerberos

Você pode 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óximo passo