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

Este artigo lista os problemas comuns ao usar compartilhamentos de arquivos SMB do Azure com a autenticação baseada em identidade. Também fornece as possíveis causas e resoluções para esses problemas. Atualmente, não há suporte para a autenticação baseada em identidade nos compartilhamentos de arquivos NFS do Azure.

Aplica-se a

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

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 necessárias do Active Directory (AD) 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.

Erros 5 ao montar um compartilhamento de arquivo do 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 estiverem acessando 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.

Solução

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

Erro AadDsTenantNotFound na habilitação da autenticação do Microsoft Entra Domain Services para Arquivos do Azure, "Não é possível localizar locatários Microsoft Entra com o locatário ID tenant-id"

Causa

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

Solução

Habilite os Microsoft Entra Domain Services no locatário do Microsoft Entra da assinatura na qual sua conta de armazenamento está implantada. Você precisa de privilégios de administrador do locatário do 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 ao adicionar um URI de redirecionamento ou um URI de identificador que não atenda aos requisitos de segurança do aplicativo Microsoft Entra ID.

O Microsoft Entra ID impõe restrições às URIs do identificador de aplicativo e URIs de redirecionamento. Os URIs recém-adicionados devem fazer referência a um dos seguintes:

• Um domínio personalizado verificado pelo locatário
• A ID do locatário do 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 solicitação será bloqueada pela política de locatário padrão.

Esse comportamento é imposto pelo Microsoft Entra ID e não é específico para o serviço Azure Files.

Para obter mais informações, consulte: Restrições às URIs de identificador de aplicativos do Microsoft EntraEsboço e restrições de URI de redirecionamento (URL de resposta)Gerenciando nomes de domínio personalizados em sua ID do Microsoft Entra

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 o ID do inquilino do 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 eles serão rejeitados pela política de locatário do Microsoft Entra ID. 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 os compartilhamentos de arquivos do Azure com as credenciais do AD

Etapas de autodiagnóstico

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

Em segundo lugar, experimente montar o compartilhamento de arquivo do Azure usando a chave da conta de armazenamento. Se o compartilhamento não for montado, baixe o 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 no acesso para s Arquivos do Azure, fornecer diretrizes prescritivas sobre a correção automática 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 tem 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 (nome da entidade de serviço) correto. 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 os Arquivos do Azure.
5. CheckSidHasAadUser: Verifique se o usuário conectado do AD está sincronizado com o ID do Microsoft Entra. Se você quiser verificar se um usuário específico do AD está sincronizado com a ID do Microsoft Entra, poderá especificar o -UserName e -Domain nos parâmetros de entrada. Para um determinado SID, ele verifica se há um usuário do Microsoft Entra associado.
6. CheckAadUserHasSid: Verifique se o usuário conectado do AD está sincronizado com o ID do Microsoft Entra. Se você quiser verificar se um usuário específico do AD está sincronizado com a ID do Microsoft Entra, poderá especificar o -UserName e -Domain nos parâmetros de entrada. Para um determinado usuário do Microsoft Entra, ele verifica seu SID. Para executar essa verificação, você deve fornecer o -ObjectId parâmetro, juntamente com a ID do objeto do usuário do 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, habilite a autenticação do AD DS nos 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 do compartilhamento para acessar os 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 (ACLs do Windows) adequada para acessar os 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 de registro Kerberos do 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 no X:e quiser executar apenas a verificação relacionada às permissões no nível do arquivo (ACLs do Windows), 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 o Microsoft Entra Kerberos

Etapas de autodiagnóstico

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

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 do Microsoft Entra Kerberos, no AzFilesHybrid v0.3.0+.

1. Entre no Azure PowerShell interativamente como um usuário do AD que tem 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 os Arquivos do Azure.
2. CheckAADConnectivity: Verifique a conectividade do Entra. As montagens SMB com autenticação Kerberos podem falhar se o cliente não puder entrar em contato com 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 do 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 a entidade de serviço Entra recebeu consentimento do administrador para as permissões do Microsoft Graph necessárias para obter um tíquete Kerberos.
7. CheckWinHttpAutoProxySvc: verifica o Serviço de Descoberta Automática de Proxy Web WinHTTP (WinHttpAutoProxySvc) necessário para a autenticação Kerberos do Microsoft Entra. Seu estado deve ser definido como Running.
8. CheckIpHlpScv: verifique o serviço auxiliar de IP (iphlpsvc) necessário para a autenticação Kerberos do Microsoft Entra. 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 Entra híbrido Ingressado. É 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 dos Arquivos do Azure falha ao usar o Entra Kerberos devido a tipos de criptografia Kerberos não suportados

Ao montar um compartilhamento de arquivos do 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 SupportedEncryptionTypes Registro estiver configurada com um valor que não inclua a AES, o 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.

Solução

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

Use uma das seguintes opções:

Opção 1: remover a chave do Registro (recomendada se não estiver configurada intencionalmente)

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

1. Exclua 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.

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.

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

Sintoma

Você pode experimentar um dos sintomas descritos abaixo ao tentar configurar 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ê tentar selecionar um novo usuário ou grupo, o local do domínio não exibirá o domínio AD DS correto.
• Você está usando várias florestas do AD e recebe a seguinte mensagem de erro: "Os controladores de domínio do 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 do Active Directory estão disponíveis e tente selecionar os objetos novamente."

Solução

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

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 em um UPN. Os Arquivos do Azure não dão 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 de ortografia ou sintaxe no comando e verifique se a versão mais recente do módulo AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases) está instalada.

Suporte de autenticação local do AD DS nos Arquivos do Azure para criptografia Kerberos AES 256

Os Arquivos do Azure dão suporte à criptografia AES-256 Kerberos para autenticação do AD DS começando com o módulo AzFilesHybrid v0.2.2. O AES-256 é o método de criptografia recomendado e é o método de criptografia padrão que começa no módulo AzFilesHybrid v0.2.5. Se você habilitou a autenticação do AD DS com uma versão de módulo inferior à v0.2.2, será necessário baixar o módulo AzFilesHybrid mais recente e executar o script do PowerShell a seguir. Se você ainda não habilitou a autenticação do AD DS em sua conta de armazenamento, siga estas diretrizes.

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Como parte da atualização, o cmdlet gira as chaves Kerberos, o que é necessário para alternar para AES-256. Não há necessidade de voltar atrás, a menos que você queira regenerar ambas as senhas.

A identidade de usuário que anteriormente tinha a atribuição de função Proprietário ou Colaborador ainda tem 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 do Windows Server Active Directory para os cenários do Windows Server Active Directory.

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

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key1"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key2"

RESOURCE_GROUP_NAME="<resource-group>"
STORAGE_ACCOUNT_NAME="<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "primary"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "secondary"

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 do Microsoft Entra registrado em seu locatário do Microsoft Entra para concluir sua configuração. Você pode configurar as permissões de API no portal do Azure seguindo estas etapas.

1. Abra o 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 do Microsoft Entra Kerberos

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

Erro – Concessão de consentimento do administrador desabilitada

Em alguns casos, o administrador do Microsoft Entra pode desabilitar a capacidade de conceder consentimento de administrador aos aplicativos do Microsoft Entra. Aqui está uma captura de tela de como isso se parece no portal do Azure.

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

Erro – "A solicitação para o Azure AD Graph falhou 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 as seguintes condições forem atendidas:

1. Você está usando o recurso beta/versão prévia das políticas de gerenciamento de aplicativos.
2. Você (ou seu administrador) definiu uma política do inquilino que:
   • Não tem data de início ou tem uma data de início anterior a 1º de janeiro de 2019.
   • Define uma restrição nas senhas da entidade de serviço, que não permite senhas personalizadas ou define um tempo de vida máximo da senha inferior a 365,5 dias.

Atualmente, não há nenhuma solução alternativa para esse erro.

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 por meio de etapas de visualização manual 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 o Microsoft Graph, entre no aplicativo Ferramentas de Linha de Comando do Microsoft Graph 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 na ID do Microsoft Entra

Se você já habilitou a autenticação Kerberos do Microsoft Entra por meio de etapas de visualização manual limitada, 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 atenuar isso, você tem duas opções: girar a senha da entidade de serviço no 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.

Certifique-se de salvar as propriedades de domínio (domainName e domainGUID) antes de desabilitar o Microsoft Entra Kerberos, pois você precisará delas durante a reconfiguração se quiser configurar permissões de diretório e nível de arquivo usando o Explorador de Arquivos do Windows. 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 o Microsoft Entra Kerberos
2. Excluir o aplicativo existente
3. Reconfigurar o Microsoft Entra Kerberos por meio do portal do Azure

Depois de reconfigurar o 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 ponto de extremidade privado/link privado usando a autenticação Kerberos do Microsoft Entra, ao tentar montar um compartilhamento de arquivos por meio net use de ou outro método, o cliente será solicitado a fornecer 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 o Arquivos do Azure não é compatível com a autenticação NTLM para credenciais de domínio. O cliente não pode obter um tíquete 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 portal do Azure seguindo estas etapas.

1. Abra o 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, você deve editar 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 montar novamente o compartilhamento.

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

Sintoma

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

Causa

Esse problema é causado por um comportamento conhecido do Windows 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 é capaz de 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 de cliente do Windows e não é causada pelos Arquivos do Azure ou pela configuração da ID do Microsoft Entra.

Solução

Opção um: sair e entrar novamente no Windows restaura o acesso buscando um novo PRT, que inclui uma configuração atualizada de TGT (TGT) e proxy 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. Definir 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 mapeamento a seguir, substituindo your_Azure_AD_tenant_id pela ID do locatário do Microsoft Entra

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

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

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

Sintoma

Os clientes do Windows que usam a autenticação Do Microsoft Entra Kerberos para acessar os 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 do Microsoft Entra Kerberos. Atualmente, o Microsoft Entra ID não dá suporte à renovação de Tickets de Concessão de Tickets (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 obtendo um novo PRT, que inclui um novo TGT. Essa é uma limitação conhecida do Microsoft Entra Kerberos e não é causada pela configuração dos Arquivos do Azure.

Solução

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

Com a confiança na nuvem configurada, os clientes do Windows obtêm seu TGT dos Serviços de Domínio do Active Directory (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 visto com o Microsoft Entra Kerberos. O TGT emitido pelo AD DS é então trocado por um TGT de referência do Entra, que é usado para obter tíquetes de serviço para o Azure Files.

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

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

Para aplicar essa mitigação, configure uma confiança na nuvem entre o AD DS local e a ID do Microsoft Entra para acessar arquivos do Azure. Para obter diretrizes passo a passo, consulte: Configurar uma confiança na nuvem para autenticação de 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 "atribuição necessária" para o aplicativo empresarial correspondente, não poderá obter um tíquete Kerberos e os logs de entrada do Microsoft Entra mostrarão um erro, mesmo que 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 incluímos as permissões no tíquete Kerberos que é retornado 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

• Solucionar problemas de arquivos do Azure
• Solucionar problemas de desempenho dos Arquivos do Azure
• Solucionar problemas de conectividade do Azure Files (SMB)
• Solucionar problemas gerais de SMB dos Arquivos do Azure no Linux
• Solucionar problemas gerais de NFS do Azure Files no Linux
• Solucionar problemas de Sincronização de Arquivos do Azure

Entre em contato conosco para obter ajuda

Se você tiver dúvidas, poderá perguntar ao suporte da comunidade do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.