Solucionar problemas de autenticação e autorização baseados em identidade do Arquivos do Azure (SMB)

Aplica-se a: ✔️ compartilhamentos de arquivos SMB Azure

Resumo

Este artigo lista problemas comuns ao usar a autenticação baseada em identidade com compartilhamentos de arquivos SMB do Azure e fornece possíveis causas e resoluções. Use este guia para diagnosticar e corrigir erros de autenticação, problemas de permissão e problemas de configuração kerberos.

Erro ao executar o módulo AzFilesHybrid

Ao tentar executar o módulo AzFilesHybrid, você pode receber o seguinte erro:

O cliente não tem um privilégio obrigatório.

Causa: as permissões do AD são insuficientes

Esse problema ocorre porque você não tem as permissões de Active Directory (AD) necessárias para executar o módulo.

Solução

Consulte os privilégios do AD ou entre em contato com o administrador do AD para fornecer os privilégios necessários.

Erro 5 ao montar um compartilhamento de arquivos Azure

Quando você tenta montar um compartilhamento de arquivos, pode receber o erro a seguir:

Ocorreu um erro de sistema 5. Acesso negado.

Causa: as permissões de nível de compartilhamento estão incorretas

Se os usuários finais acessarem o compartilhamento de arquivos do Azure usando a autenticação baseada em identidade, o acesso ao compartilhamento de arquivos falhará com o erro "O acesso é negado" se as permissões de nível de compartilhamento estiverem incorretas.

Observação

Esse erro pode ser causado por problemas que não sejam permissões de nível de compartilhamento incorretas. Para obter informações sobre outras possíveis causas e soluções, consulte Troubleshoot Arquivos do Azure problemas de conectividade e acesso.

Solução

Valide se as permissões estão configuradas corretamente. Consulte Atribuir permissões de nível de compartilhamento.

Erro AadDsTenantNotFound ao habilitar a autenticação do Microsoft Entra Domain Services para Arquivos do Azure "Incapaz de localizar inquilinos ativos com ID de inquilino do Microsoft Entra tenant-id"

Causa

Erro AadDsTenantNotFound ocorre quando você tenta habilitar a autenticação do Microsoft Entra Domain Services para o Arquivos do Azure em uma conta de armazenamento em que o Microsoft Entra Domain Services não foi criado no locatário Microsoft Entra da assinatura associada.

Solução

Habilite Microsoft Entra Domain Services no locatário Microsoft Entra da assinatura na qual sua conta de armazenamento está implantada. Você precisa de privilégios de administrador do locatário Microsoft Entra para criar um domínio gerenciado. Se você não for o administrador do locatário do Microsoft Entra, entre em contato com o administrador e siga as diretrizes passo a passo para criar e configurar um domínio gerenciado do Microsoft Entra Domain Services.

Erro: todas as URIs recém-adicionadas devem conter um domínio verificado pelo locatário, ID do locatário ou ID do aplicativo

Causa

Esse erro ocorre durante a configuração da autenticação baseada em identidade para arquivos do Azure quando você adiciona um URI de redirecionamento ou um URI do identificador que não atende aos requisitos de segurança do aplicativo Microsoft Entra ID.

Microsoft Entra ID impõe restrições aos URIs do identificador de aplicativo e URIs de redirecionamento. Os URIs recém-adicionados devem referenciar um dos seguintes valores:

  • Um domínio personalizado verificado pelo locatário
  • O ID do tenant Microsoft Entra
  • A ID do aplicativo (cliente)

Se um URI usar um domínio não verificado, um .local nome de host ou uma URL arbitrária que não esteja associada ao locatário, a política de locatário padrão bloqueará a solicitação.

O Microsoft Entra ID impõe esse comportamento e não é específico para o serviço Arquivos do Azure.

Para obter mais informações, consulte:

Solução

Ao configurar o registro de aplicativo ou a autenticação baseada em identidade para arquivos do Azure, verifique se qualquer URI de redirecionamento ou URI do identificador usa um dos formatos com suporte:

  • Usar um domínio personalizado verificado pelo locatário
  • Usar a ID do locatário Microsoft Entra
  • Utilize o ID do aplicativo (cliente)

Não use domínios não verificados, .local nomes de host ou URLs arbitrárias, pois a política de locatário do Microsoft Entra ID rejeita esses valores. Se você não tiver certeza de quais domínios são verificados em seu locatário, examine a seção Nomes de domínio personalizados no centro de administração do Microsoft Entra ou entre em contato com o administrador do locatário.

Não é possível montar compartilhamentos de arquivos do Azure com credenciais do Active Directory.

Etapas de autodiagnóstico

Primeiro, verifique se você seguiu as etapas para habilitar a Autenticação do Arquivos do Azure com AD DS.

Em segundo lugar, tente montar o compartilhamento de arquivos do Azure com a chave da conta de armazenamento. Se o compartilhamento não for montado, baixe AzFileDiagnostics para ajudá-lo a validar o ambiente de execução do cliente. O AzFileDiagnostics pode detectar configurações de cliente incompatíveis que podem causar falha de acesso para Arquivos do Azure, fornecer diretrizes prescritivas sobre auto-correção e coletar os rastreamentos de diagnóstico.

Em terceiro lugar, você pode executar o Debug-AzStorageAccountAuth cmdlet para realizar um conjunto de verificações básicas na configuração do AD com o usuário do AD conectado. Esse cmdlet tem suporte no AzFilesHybrid v0.1.2+.

  1. Entre no Azure PowerShell interativamente como um usuário do AD que tenha permissão de proprietário na conta de armazenamento de destino:

    Connect-AzAccount

  2. Execute o Debug-AzStorageAccountAuth cmdlet:

    $ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

O cmdlet executa estas verificações em sequência e fornece diretrizes para falhas:

  1. CheckADObjectPasswordIsCorrect: verifique se a senha configurada na identidade do AD que representa a conta de armazenamento corresponde à da chave kerb1 ou kerb2 da conta de armazenamento. Se a senha estiver incorreta, você poderá executar Update-AzStorageAccountADObjectPassword para redefinir a senha.
  2. CheckADObject: confirme se há um objeto no Active Directory que representa a conta de armazenamento e tem o SPN correto (nome da entidade de serviço). Se o SPN não estiver configurado corretamente, execute o cmdlet Set-AD retornado no cmdlet de depuração para configurar o SPN.
  3. CheckDomainJoined: Valide se o computador cliente está ingressado no domínio do AD. Se o computador não estiver unido ao domínio no Active Directory, consulte Ingressar um computador em um domínio para obter instruções de como unir-se a um domínio.
  4. CheckPort445Connectivity: Verifique se a porta 445 está aberta para conexão SMB. Se a porta 445 não estiver aberta, consulte a ferramenta de solução de problemas AzFileDiagnostics para problemas de conectividade com Arquivos do Azure.
  5. CheckSidHasAadUser: verifique se o usuário conectado ao AD está sincronizado com Microsoft Entra ID. Se você quiser pesquisar se um usuário específico do AD está sincronizado com Microsoft Entra ID, você pode especificar o -UserName e -Domain nos parâmetros de entrada. Para um determinado SID, ele verifica se há um usuário Microsoft Entra associado.
  6. CheckAadUserHasSid: verifique se o usuário conectado ao AD está sincronizado com Microsoft Entra ID. Se você quiser pesquisar se um usuário específico do AD está sincronizado com Microsoft Entra ID, você pode especificar o -UserName e -Domain nos parâmetros de entrada. Para um determinado usuário Microsoft Entra, ele verifica seu SID. Para executar essa verificação, você deve fornecer o parâmetro -ObjectId, juntamente com a ID do objeto do usuário Microsoft Entra.
  7. CheckGetKerberosTicket: tente obter um tíquete Kerberos para se conectar à conta de armazenamento. Se não houver um token Kerberos válido, execute o klist get cifs/storage-account-name.file.core.windows.net cmdlet e examine o código de erro para determinar a causa da falha de recuperação de tíquete.
  8. CheckStorageAccountDomainJoined: Verifique se a autenticação do AD está habilitada e se as propriedades do AD da conta estão preenchidas. Caso contrário, ative a autenticação AD DS no Arquivos do Azure.
  9. CheckUserRbacAssignment: Verifique se a identidade do AD tem a atribuição de função RBAC adequada para fornecer permissões no nível de compartilhamento para acessar o Arquivos do Azure. Caso contrário, configure a permissão de nível de compartilhamento. (Com suporte no AzFilesHybrid v0.2.3+)
  10. CheckUserFileAccess: verifique se a identidade do AD tem a permissão de diretório/arquivo (Windows ACLs) adequada para acessar Arquivos do Azure. Caso contrário, configure a permissão de nível de arquivo/diretório. Para executar essa verificação, você deve fornecer o -FilePath parâmetro, juntamente com o caminho do arquivo montado ao qual deseja depurar o acesso. (Com suporte no AzFilesHybrid v0.2.3+)
  11. CheckKerberosTicketEncryption: verifique se a conta de armazenamento está configurada para aceitar o tipo de criptografia usado pelo tíquete Kerberos. (Com suporte no AzFilesHybrid v0.2.5+)
  12. CheckChannelEncryption: verifique se a conta de armazenamento está configurada para aceitar o tipo de criptografia de canal SMB usado pelo cliente. (Com suporte no AzFilesHybrid v0.2.5+)
  13. CheckDomainLineOfSight: verifique se o cliente tem conectividade de rede desimpedida com o controlador de domínio. (Com suporte no AzFilesHybrid v0.2.5+)
  14. CheckDefaultSharePermission: verifique se a permissão de nível de compartilhamento padrão está configurada. (Com suporte no AzFilesHybrid v0.2.5+)
  15. CheckAadKerberosRegistryKeyIsOff: verifique se a chave do Registro Kerberos Microsoft Entra está desativada. Se a tecla estiver ativada, execute reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 a partir de um prompt de comando elevado para desativá-la e reinicie o computador. (Com suporte no AzFilesHybrid v0.2.9+)

Se você quiser apenas executar uma subseleção das verificações anteriores, poderá usar o parâmetro, juntamente com uma lista separada por vírgulas -Filter de verificações a serem executadas. Por exemplo, para executar todas as verificações relacionadas às RBAC (permissões de nível de compartilhamento), use os seguintes cmdlets do PowerShell:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Se você tiver o compartilhamento de arquivos montado em X: e se quiser executar apenas a verificação relacionada a permissões no nível do arquivo (Windows ACLs), poderá executar os seguintes cmdlets do PowerShell:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Não é possível montar compartilhamentos de arquivos do Azure com Microsoft Entra Kerberos

Etapas de autodiagnóstico

Primeiro, verifique se você seguiu as etapas para habilitar a autenticação Kerberos do Microsoft Entra.

Em segundo lugar, você pode executar o Debug-AzStorageAccountAuth cmdlet para executar um conjunto de verificações básicas. Esse cmdlet tem suporte para contas de armazenamento, configuradas para autenticação Kerberos do Microsoft Entra, em AzFilesHybrid v0.3.0+.

  1. Entre no Azure PowerShell interativamente como um usuário do AD que tenha permissão de proprietário na conta de armazenamento de destino:

    Connect-AzAccount

  2. Execute o Debug-AzStorageAccountAuth cmdlet:

    $ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

O cmdlet executa estas verificações em sequência e fornece diretrizes para falhas:

  1. CheckPort445Connectivity: Verifique se a porta 445 está aberta para conexão SMB. Se a porta 445 não estiver aberta, use a ferramenta de solução de problemas AzFileDiagnostics para problemas de conectividade com Arquivos do Azure.
  2. CheckAADConnectivity: Verifique a conectividade do Entra. As montagens SMB com autenticação Kerberos podem falhar se o cliente não conseguir acessar o Entra. Se essa verificação falhar, isso indica que há um erro de rede (talvez um problema de firewall ou VPN).
  3. CheckEntraObject: Confirme se há um objeto no Entra que representa a conta de armazenamento e tem o SPN (nome da entidade de serviço) correto. Se o SPN não estiver configurado corretamente, desabilite e habilite novamente a autenticação Kerberos do Entra na conta de armazenamento.
  4. CheckRegKey: Verifique se a CloudKerberosTicketRetrieval chave do Registro está habilitada. Essa chave do Registro é necessária para a autenticação Kerberos da Entra.
  5. CheckRealmMap: verifique se o usuário configurou mapeamentos de domínios que ingressariam a conta em um reino Kerberos diferente de KERBEROS.MICROSOFTONLINE.COM.
  6. CheckAdminConsent: Verifique se o principal de serviço Entra recebeu o consentimento do administrador para as permissões do Microsoft Graph necessárias para obter um tíquete Kerberos.
  7. CheckWinHttpAutoProxySvc: Verifica se o serviço WinHTTP Web Proxy Auto-Discovery (WinHttpAutoProxySvc), necessário para a autenticação Kerberos do Microsoft Entra, está presente. Seu estado deve ser definido como Running. Por motivos de segurança, opcionalmente, você pode desabilitar a Descoberta Automática de Proxy Web (WPAD) por meio de chaves do Registro. No entanto, você não deve desabilitar o serviço WinHttpAutoProxySvc, pois ele é responsável por uma gama de outras funcionalidades, incluindo solicitações de Proxy do Centro de Distribuição de Chaves Kerberos (Proxy KDC).
  8. CheckIpHlpScv: Verifique se o serviço Auxiliar de IP (iphlpsvc), necessário para a autenticação Kerberos do Microsoft Entra, está ativado. Seu estado deve ser definido como Running.
  9. CheckFiddlerProxy: verifique se existe um proxy Fiddler que impede a autenticação Kerberos do Microsoft Entra.
  10. CheckEntraJoinType: Verifique se a máquina está ingressada no domínio Entra ou no domínio híbrido Entra. É um pré-requisito para a autenticação Kerberos do Microsoft Entra.

Se você quiser apenas executar uma subseleção das verificações anteriores, poderá usar o parâmetro, juntamente com uma lista separada por vírgulas -Filter de verificações a serem executadas.

A montagem do Arquivos do Azure falha usando o Entra Kerberos devido a tipos de criptografia do Kerberos que não são suportados

Ao montar um compartilhamento de arquivos Azure usando a autenticação Entra Kerberos, a operação de montagem falha. A coleta de logs pode mostrar que o ticket de serviço Kerberos não pode ser descriptografado. Você também pode descobrir que a seguinte chave do Registro está configurada: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes

Causa

Se a chave do Registro SupportedEncryptionTypes for configurada com um valor que não inclui AES, Windows permitirá apenas os tipos de criptografia especificados na máscara de bits. Por exemplo, o valor 0x7 indica que o cliente dá suporte apenas aos seguintes tipos de criptografia Kerberos:

  • DES_CBC_CRC
  • DES_CBC_MD5
  • RC4_HMAC

Como o Entra Kerberos sempre criptografa os tíquetes de serviço com o AES-256 (AES256-CTS-HMAC-SHA1-96), as montagens falharão se o AES não estiver incluído nos tipos de criptografia com suporte para a conta ou o computador.

Observação

A criptografia AES é habilitada por padrão em sistemas operacionais Windows modernos. Se a chave do Registro SupportedEncryptionTypes não estiver configurada, Windows negociará automaticamente o AES quando disponível.

Solução

Para montar compartilhamentos de arquivos do Azure com êxito usando o Entra Kerberos, o AES-256 precisa estar incluído nos tipos de criptografia com suporte.

Use uma das seguintes opções:

Se os tipos de criptografia não foram deliberadamente restritos:

  1. Excluir a chave do Registro: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes
  2. Reinicialize o computador.

Após a reinicialização, tente montar novamente o compartilhamento de arquivos.

Dica

Remover a chave restaura o comportamento padrão do Windows, permitindo que o Active Directory negocie automaticamente o AES para tíquetes Kerberos.

Opção 2: habilitar explicitamente o AES-256 usando a Política de Grupo

Se sua organização exigir tipos de criptografia Kerberos configurados explicitamente:

  1. Pressione Win + R, digite gpedit.msce selecione Enter.
  2. Navegue até: Política de Computador Local > Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança
  3. Segurança de Rede Aberta: configurar tipos de criptografia permitidos para Kerberos.
  4. Habilite os seguintes tipos de criptografia:
    • AES256_HMAC_SHA1
    • AES128_HMAC_SHA1 (opcional)
  5. Aplique a alteração e reinicialize o computador.

Após a reinicialização, tente montar novamente o compartilhamento de arquivos.

Importante

Entra Kerberos requer AES256_HMAC_SHA1 para montar com sucesso compartilhamentos de arquivos do Azure. As configurações somente RC4 ou DES falharão. Para entender mais sobre chaves do Registro, consulte Decifrando a Seleção de Tipos de Criptografia Kerberos com Suporte.

Não é possível configurar permissões de nível de arquivo/diretório (ACLs Windows) com Windows Explorador de Arquivos

Sintoma

Você pode experimentar um dos sintomas descritos abaixo ao tentar configurar as ACLs do Windows com o Explorador de Arquivos do Windows em um compartilhamento de arquivos montado:

  • Depois de clicar em Editar permissão na guia Segurança, o assistente de permissão não é carregado.
  • Quando você tenta selecionar um novo usuário ou grupo, o local de domínio não exibe o domínio do AD DS (Active Directory Domain Services) correto.
  • Você está usando várias florestas do AD e recebe a seguinte mensagem de erro: "Os controladores de domínio Active Directory necessários para localizar os objetos selecionados nos domínios a seguir não estão disponíveis. Verifique se os controladores de domínio Active Directory estão disponíveis e tente selecionar os objetos novamente."

Solução

Recomendamos que você configurar permissões de nível de arquivo/diretório usando icacls em vez de usar Windows Explorador de Arquivos.

Não é possível exibir UserPrincipalName (UPN) de um proprietário de arquivo/diretório no Explorador de Arquivos

Sintoma

O Explorador de Arquivos exibe o SID (identificador de segurança) de um proprietário de arquivo/diretório, mas não o UPN.

Causa

O Explorador de Arquivos chama uma API RPC diretamente para o servidor (Arquivos do Azure) para traduzir o SID para um UPN. Arquivos do Azure não dá suporte a essa API, portanto, o UPN não é exibido.

Solução

Em um cliente ingressado no domínio, use o seguinte comando do PowerShell para exibir todos os itens em um diretório e seu proprietário, incluindo UPN:

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Erros ao executar o cmdlet Join-AzStorageAccountForAuth

Erro: "O serviço de diretório não pôde alocar um identificador relativo"

Esse erro poderá ocorrer se um controlador de domínio que contém a função FSMO do Mestre de RID estiver indisponível ou tiver sido removido do domínio e restaurado do backup. Confirme que todos os Controladores de Domínio estão em execução e disponíveis.

Erro: "Não é possível associar parâmetros posicionais porque nenhum nome foi fornecido"

Esse erro provavelmente é disparado por um erro de sintaxe no Join-AzStorageAccountforAuth comando. Verifique se há erros ortográficos ou de sintaxe no comando e verifique se a versão mais recente do módulo AzFilesHybrid está instalada.

A identidade do usuário que anteriormente tinha a função de Proprietário ou Colaborador ainda possui acesso à chave da conta de armazenamento.

As funções Proprietário e Colaborador da conta de armazenamento concedem a capacidade de listar as chaves da conta de armazenamento. A chave da conta de armazenamento permite acesso total aos dados da conta de armazenamento, incluindo compartilhamentos de arquivos, blobs, tabelas e filas. Ele também fornece acesso limitado às operações de gerenciamento de Arquivos do Azure por meio das APIs de gerenciamento herdadas expostas por meio da API FileREST. Se você estiver alterando atribuições de função, considere que os usuários que estão sendo removidos das funções Proprietário ou Colaborador podem continuar a ter acesso à conta de armazenamento por meio de chaves de conta de armazenamento salvas.

Solução 1

Você pode corrigir esse problema com facilidade girando as chaves da conta de armazenamento. Recomendamos girar as teclas uma de cada vez, alternando o acesso de uma para a outra à medida que elas são giradas. Há dois tipos de chaves compartilhadas que a conta de armazenamento fornece: as chaves da conta de armazenamento, que fornecem acesso de superadministrador aos dados da conta de armazenamento, e as chaves Kerberos, que funcionam como um segredo compartilhado entre a conta de armazenamento e o controlador de domínio Windows Server Active Directory para Windows Server Active Directory cenários.

Para alternar as chaves Kerberos de uma conta de armazenamento, consulte Alterar a senha da identidade da conta de armazenamento no AD DS.

Navegue até a conta de armazenamento desejada no portal do Azure. No sumário da conta de armazenamento desejada, selecione chaves de acesso no título Segurança + rede . No painel Chave de acesso, selecione Girar a chave acima da chave desejada.

Captura de tela que mostra o painel 'Chave de acesso'.

Definir as permissões de API em um aplicativo recém-criado

Depois de habilitar a autenticação Kerberos do Microsoft Entra, você deve conceder explicitamente o consentimento do administrador ao novo aplicativo Microsoft Entra registrado em seu inquilino Microsoft Entra para concluir sua configuração. Você pode configurar as permissões de API do Azure portal seguindo estas etapas.

  1. Abra Microsoft Entra ID.
  2. Selecione Registros de aplicativo no painel esquerdo.
  3. Selecione Todos os Aplicativos no painel direito.
  4. Selecione o aplicativo com o nome correspondente [Conta de Armazenamento] $storageAccountName.file.core.windows.net.
  5. Selecione permissões de API no painel esquerdo.
  6. Selecione Adicionar permissões na parte inferior da página.
  7. Selecione Conceder consentimento do administrador para "DirectoryName".

Possíveis erros ao habilitar a autenticação Kerberos do Microsoft Entra

Você pode encontrar os seguintes erros ao ativar a autenticação Kerberos do Microsoft Entra.

Erro – Concessão de consentimento do administrador desabilitada

Em alguns casos, o administrador do Microsoft Entra pode desabilitar a capacidade de conceder consentimento do administrador a aplicativos do Microsoft Entra. Aqui está uma captura de tela da aparência disso no portal do Azure.

Captura de tela que mostra o painel

Se esse for o caso, peça ao administrador do Microsoft Entra que conceda consentimento do administrador ao novo aplicativo Microsoft Entra. Para localizar e exibir seus administradores, selecione funções e administradores e, em seguida, selecione Administrador de aplicativos de nuvem.

Erro – "Falha na solicitação para Microsoft Graph com o código BadRequest"

Causa 1: uma política de gerenciamento de aplicativos está impedindo que as credenciais sejam criadas

Ao habilitar a autenticação Kerberos do Microsoft Entra, você poderá encontrar esse erro se você (ou seu administrador) tiver definido uma política de locatário ou uma política de gerenciamento de aplicativo que:

  • Aplica-se ao aplicativo empresarial "Provedor de Recursos de Armazenamento" (ID a6aa9161-5291-40bb-8c5c-923b567bee3bdo aplicativo).
  • Define uma restrição para senhas do principal de serviço, que bloqueia a adição de senhas ou restringe o tempo máximo de vida das senhas para menos de 365,5 dias.

Para resolver esse erro, você deve configurar a política ofensiva para conceder uma exceção ao Aplicativo Empresarial "Provedor de Recursos de Armazenamento" (ID a6aa9161-5291-40bb-8c5c-923b567bee3bdo aplicativo).

Causa 2: já existe um aplicativo para a conta de armazenamento

Você também poderá encontrar esse erro se tiver habilitado anteriormente a autenticação Kerberos do Microsoft Entra através de etapas manuais em uma visualização limitada. Para excluir o aplicativo existente, o cliente ou o respectivo administrador de TI pode executar o script a seguir. A execução desse script removerá o aplicativo antigo criado manualmente e permitirá que a nova experiência crie e gerencie automaticamente o aplicativo recém-criado. Depois de iniciar a conexão com Microsoft Graph, entre no aplicativo Microsoft Graph Ferramentas de Linha de Comando em seu dispositivo e conceda permissões ao aplicativo.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

Erro – A senha da entidade de serviço expirou no Microsoft Entra ID

Se você tiver habilitado anteriormente a autenticação Kerberos do Microsoft Entra por meio de etapas manuais de visualização limitada, a senha da entidade de serviço da conta de armazenamento está definida para expirar a cada seis meses. Depois que a senha expirar, os usuários não poderão obter tíquetes Kerberos para acessar o compartilhamento de arquivos.

Para atenuar isso, você tem duas opções: trocar a senha do principal de serviço do Microsoft Entra a cada seis meses ou seguir estas etapas para desabilitar o Kerberos do Microsoft Entra, excluir o aplicativo existente e reconfigurar o Kerberos do Microsoft Entra.

Salve as propriedades de domínio (domainName e domainGUID) antes de desabilitar Microsoft Entra Kerberos, pois você precisará delas durante a reconfiguração se quiser configurar permissões de diretório e de nível de arquivo usando Windows Explorador de Arquivos. Se você não salvou propriedades de domínio, ainda poderá configurar permissões de diretório/nível de arquivo usando icacls como uma solução alternativa.

  1. Desabilitar Microsoft Entra Kerberos
  2. Excluir o aplicativo existente
  3. Reconfigure Microsoft Entra Kerberos por meio do portal Azure

Depois de reconfigurar Microsoft Entra Kerberos, a nova experiência criará e gerenciará automaticamente o aplicativo recém-criado.

Erro 1326 - O nome de usuário ou senha está incorreto ao usar o link privado

Se você estiver se conectando a uma conta de armazenamento por meio de um link privado/ponto de extremidade privado usando autenticação Kerberos do Microsoft Entra, ao tentar montar um compartilhamento de arquivos por meio de net use ou outro método, o cliente será solicitado a inserir as credenciais. O usuário provavelmente digitará suas credenciais, mas elas serão rejeitadas.

Causa

Isso ocorre porque o cliente SMB tentou usar Kerberos, mas falhou, portanto, ele volta a usar a autenticação NTLM e Arquivos do Azure não dá suporte ao uso da autenticação NTLM para credenciais de domínio. O cliente não pode obter um ticket Kerberos para a conta de armazenamento porque o FQDN do link privado não está registrado em nenhum aplicativo Microsoft Entra existente.

Solução

A solução é adicionar o FQDN privateLink ao aplicativo Microsoft Entra da conta de armazenamento antes de montar o compartilhamento de arquivos. Você pode adicionar os identifierUris necessários ao objeto de aplicativo usando o Azure portal seguindo estas etapas.

  1. Abra Microsoft Entra ID.

  2. Selecione Registros de aplicativo no painel esquerdo.

  3. Selecione Todos os Aplicativos.

  4. Selecione o aplicativo com o nome correspondente [Conta de Armazenamento] $storageAccountName.file.core.windows.net.

  5. Selecione Manifesto no painel esquerdo.

  6. Copie e cole o conteúdo existente para que você tenha uma cópia duplicada.

  7. Edite o manifesto JSON. Para cada <storageAccount>.file.core.windows.net entrada, adicione uma entrada correspondente <storageAccount>.privatelink.file.core.windows.net . Por exemplo, se o manifesto tiver o seguinte valor para identifierUris:

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net"
],

    Em seguida, edite o identifierUris campo para o seguinte:

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net",

    "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
    "HOST/<storageaccount>.privatelink.file.core.windows.net",
    "CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "HTTP/<storageaccount>.privatelink.file.core.windows.net"
],

  8. Examine o conteúdo e selecione Salvar para atualizar o objeto do aplicativo com os novos identifierUris.

  9. Atualize todas as referências de DNS internas para apontar para o link privado.

  10. Tente novamente montar o compartilhamento.

Falhas de autenticação intermitentes após alterações de rede ao usar Microsoft Entra Kerberos

Sintoma

Os clientes do Windows que usam a autenticação Kerberos do Microsoft Entra para acessar o Arquivos do Azure perdem o acesso intermitentemente após uma alteração de rede (por exemplo, reconexão de VPN, mudança de Wi-Fi, suspensão ou retomada). O Access pode falhar até que o usuário saia e entre novamente no Windows.

Causa

Esse problema é causado por um comportamento de Windows conhecido em que determinadas alterações de rede limpam a configuração de proxy KDC armazenada em cache no cliente. Quando a configuração de proxy KDC é removida, o cliente não consegue atualizar os tíquetes de serviço Kerberos do Microsoft Entra ID.

Embora o PRT (Token de Atualização Primária) do usuário permaneça válido, a configuração de proxy KDC ausente impede o cliente de adquirir um novo tíquete de serviço, resultando em falhas de autenticação.

Essa é uma limitação do cliente Windows e não é causada por Arquivos do Azure ou configuração de Microsoft Entra ID.

Solução

Opção um: Sair do sistema e entrar novamente no Windows restaura o acesso ao buscar um novo PRT, que inclui um TGT atualizado (Ticket Granting Ticket) e a configuração de proxy do KDC. No entanto, isso resulta em uma experiência ruim do usuário.

Opção dois: definir uma configuração de Política de Grupo para persistir a configuração de proxy KDC no cliente, reduzindo as interrupções de autenticação causadas por alterações de rede.

  1. Defina as configurações de proxy KDC usando a Política de Grupo.

  2. Abra o Gerenciamento de Política de Grupo e edite a política aplicável.

  3. Navegue até:Modelos Administrativos>Sistema>Kerberos>Especificar servidores proxy KDC para clientes Kerberos

  4. Selecione Habilitado.

  5. Em Opções, selecione Mostrar para abrir a caixa de diálogo Mostrar Conteúdo.

  6. Adicione o seguinte mapeamento, substituindo Microsoft_Entra_tenant_id pela ID do locatário Microsoft Entra. Inclua o espaço após https e antes do fechamento /.

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

  7. Selecione OK e, em seguida, selecione Aplicar.

Depois que essa política é aplicada, os clientes Windows retêm a configuração de proxy KDC durante as alterações de rede, reduzindo as interrupções de autenticação.

A autenticação é interrompida após aproximadamente 10 horas ao usar Microsoft Entra Kerberos

Sintoma

Clientes do Windows que usam autenticação Kerberos do Microsoft Entra para acessar Arquivos do Azure perdem o acesso após aproximadamente 10 horas de uso contínuo. O acesso é restaurado somente depois que o usuário sai e entra novamente no Windows.

Causa

Esse problema é causado por uma limitação conhecida na autenticação Kerberos Microsoft Entra. Microsoft Entra ID, no momento, não oferece suporte à renovação de Tickets de Concessão de Tíquetes (TGTs).

Nos cenários do Microsoft Entra Kerberos, o TGT é obtido como parte do PRT (Token de Atualização Primária) do usuário. Como não há suporte para a renovação do TGT, o cliente não pode atualizar o TGT depois de expirar. Quando o TGT expira, o cliente não consegue adquirir novos tíquetes de serviço, resultando em falhas de autenticação.

Sair e entrar novamente no Windows resolve o problema ao obter um novo PRT, que inclui um novo TGT. Essa é uma limitação conhecida de Microsoft Entra Kerberos e não é causada por Arquivos do Azure configuração.

Solução

Como mitigação, os clientes podem usar a confiança de nuvem entre o AD DS (Active Directory Domain Services local) e o Microsoft Entra ID ao acessarem o Arquivos do Azure.

Com a confiança na nuvem configurada, os clientes Windows obtêm seu TGT do AD DS em vez do Microsoft Entra ID. Os TGTs emitidos pelo AD DS dão suporte à renovação, evitando o comportamento de expiração observado com o Microsoft Entra Kerberos. O TGT emitido pelo AD DS é então trocado por uma TGT de referência da Entra, que é usada para obter tíquetes de serviço para Arquivos do Azure.

Essa mitigação se aplica somente aos clientes que são:

  • Domínio do AD DS ingressado ou
  • Ingressado ao Microsoft Entra híbrido
  • Clientes nativos de nuvem (somente Microsoft Entra) não podem usar essa solução alternativa.

Para aplicar essa mitigação, configure uma relação de confiança na nuvem entre o AD DS local e o Microsoft Entra ID para acessar Arquivos do Azure. Para obter diretrizes passo a passo, consulte Configure uma confiança na nuvem para autenticação Arquivos do Azure.

Erro AADSTS50105

Sintoma

A solicitação foi interrompida pelo seguinte erro AADSTS50105:

Seu administrador configurou o aplicativo "Nome do aplicativo corporativo" para bloquear usuários, a menos que eles recebam especificamente acesso (atribuído) ao aplicativo. O usuário conectado '{EmailHidden}' está bloqueado porque não é um membro direto de um grupo com acesso, nem teve acesso atribuído diretamente por um administrador. Entre em contato com o administrador para atribuir acesso a este aplicativo.

Causa

Se você configurar a "atribuição necessária" para o aplicativo empresarial correspondente, não será possível obter um ticket Kerberos, e os registros de entrada do Microsoft Entra mostrarão um erro, mesmo que os usuários ou grupos sejam atribuídos ao aplicativo.

Solução

Não selecione Atribuição necessária para o aplicativo Microsoft Entra para a conta de armazenamento porque não preenchemos os privilégios no tíquete Kerberos que é devolvido ao solicitante. Para obter mais informações, consulte Erro AADSTS50105 - O usuário conectado não está atribuído a uma função para o aplicativo.

Confira também

  • Last updated on