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

  • Artigo

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

Aplicável a

Tipo de compartilhamento de arquivo SMB NFS
Compartilhamentos de arquivo padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivo padrão (GPv2), GRS/GZRS
Compartilhamentos de arquivo Premium (FileStorage), LRS/ZRS

Erro ao executar o módulo AzFilesHybrid

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

Um privilégio necessário não é mantido pelo cliente.

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 seu administrador do AD para fornecer os privilégios necessários.

Erro 5 ao montar um compartilhamento de arquivos do Azure

Ao tentar montar um compartilhamento de arquivos, você poderá receber o seguinte erro:

O erro do sistema 5 ocorreu. 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 Active Directory Domain Services (AD DS) ou Microsoft Entra Domain Services autenticação, o acesso ao compartilhamento de arquivos falhará com o erro "O acesso é negado" se as permissões no nível do compartilhamento estiverem incorretas.

Observação

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

Solução

Valide se as permissões estão configuradas corretamente:

  • Active Directory Domain Services (AD DS) consulte Atribuir permissões de nível de compartilhamento.

    Há suporte para atribuições de permissão no nível de compartilhamento para grupos e usuários que foram sincronizados do AD DS para Microsoft Entra ID usando Microsoft Entra Connect Sync ou Microsoft Entra Sincronização de nuvem connect. Confirme se grupos e usuários que recebem permissões de nível de compartilhamento não são grupos "somente nuvem" sem suporte.

  • Microsoft Entra Domain Services veja Atribuir permissões de nível de compartilhamento.

Erro AadDsTenantNotFound ao habilitar Microsoft Entra Domain Services autenticação para Arquivos do Azure "Não é possível localizar locatários ativos com ID do locatário Microsoft Entra id de locatário"

Motivo

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

Solução

Habilite Microsoft Entra Domain Services no locatário Microsoft Entra da assinatura à 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 Microsoft Entra, entre em contato com o administrador e siga as diretrizes passo a passo para criar e configurar um domínio gerenciado Microsoft Entra Domain Services.

Não é possível montar compartilhamentos de arquivos do Azure com credenciais do AD

Etapas de auto-diagnóstico

Primeiro, verifique se você seguiu as etapas para habilitar Arquivos do Azure Autenticação do 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 ajudar você a validar o ambiente de execução do cliente. O AzFileDiagnostics pode detectar configurações incompatíveis do cliente que podem causar falha de acesso para Arquivos do Azure, fornecer diretrizes prescritivas sobre auto-correção e coletar os rastreamentos 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 na versão AzFilesHybrid v0.1.2+. Você precisa executar esse cmdlet com um usuário do AD que tenha permissão de proprietário na conta de armazenamento de destino.

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

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

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

  1. CheckADObjectPasswordIsCorrect: verifique se a senha configurada na identidade do AD que representa a conta de armazenamento está correspondendo à 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 Set-AD cmdlet retornado no cmdlet de depuração para configurar o SPN.
  3. CheckDomainJoined: valide se o computador cliente é ingressado no domínio do AD. Se o computador não for ingressado no domínio do AD, consulte Ingressar em um computador em um domínio para obter instruções de junção de 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 para 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 para 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 esse marcar, você deve fornecer o -ObjectId parâmetro, 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 do tíquete.
  8. CheckStorageAccountDomainJoined: verifique se a autenticação do AD foi habilitada e as propriedades do AD da conta estão preenchidas. Caso contrário, habilite a autenticação do 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 de nível de compartilhamento para acessar Arquivos do Azure. Caso contrário, configure a permissão de nível de compartilhamento. (Com suporte na versão 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 Arquivos do Azure. Caso contrário, configure a permissão de diretório/nível de arquivo. Para executar esse marcar, você deve fornecer o -FilePath parâmetro, juntamente com o caminho do arquivo montado ao qual deseja depurar o acesso. (Com suporte na versão AzFilesHybrid v0.2.3+ )
  11. CheckAadKerberosRegistryKeyIsOff: verifique se a chave do registro kerberos Microsoft Entra está desativada. Se a chave 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 na versão AzFilesHybrid v0.2.9+ )

Se você quiser apenas executar uma subseção das verificações anteriores, poderá usar o -Filter parâmetro, juntamente com uma lista separada por vírgula de verificações a serem executadas. Por exemplo, para executar todas as verificações relacionadas a 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 você quiser apenas executar o marcar relacionado a ACLs (permissões no nível do arquivo), 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 configurar permissões de diretório/nível de arquivo (ACLs do Windows) com o Windows Explorador de Arquivos

Sintoma

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

  • Depois de clicar em Editar permissão na guia Segurança, o assistente de permissão não será carregado.
  • Quando você tenta selecionar um novo usuário ou grupo, o local de domínio não exibe o domínio AD DS certo.
  • 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 seguintes domínios 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 configurar permissões de diretório/nível de arquivo usando icacls em vez de usar o Windows Explorador de Arquivos.

Erros ao executar Join-AzStorageAccountForAuth cmdlet

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 RID Master FSMO não estiver disponível ou for removido do domínio e restaurado do backup. Confirme se 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 dado"

Esse erro provavelmente é disparado por um erro de sintaxe no Join-AzStorageAccountforAuth comando. Verifique o comando para erros ortográficos ou de sintaxe e verifique se a versão mais recente do módulo AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases) está instalada.

Arquivos do Azure suporte à Autenticação do AD DS local para criptografia Kerberos do AES-256

Arquivos do Azure dá suporte à criptografia Kerberos AES-256 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, precisará baixar o módulo AzFilesHybrid mais recente e executar o PowerShell abaixo. Se você ainda não tiver habilitado a autenticação do AD DS em sua conta de armazenamento, siga estas diretrizes.

Importante

Se você estivesse usando a criptografia RC4 anteriormente e atualizasse a conta de armazenamento para usar o AES-256, você deverá executar klist purge no cliente e, em seguida, remontar o compartilhamento de arquivos para obter novos tíquetes Kerberos com o AES-256.

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

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

A identidade do usuário anteriormente tendo 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, contêineres de blobs, tabelas e filas e 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 as 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 manter o acesso à conta de armazenamento por meio de chaves salvas da conta de armazenamento.

Solução 1

Você pode corrigir esse problema facilmente girando as chaves da conta de armazenamento. Recomendamos girar as chaves uma de cada vez, alternando o acesso de uma para 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 super-administrador 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 girar as chaves Kerberos de uma conta de armazenamento, consulte Atualizar a senha da identidade da sua conta de armazenamento no AD DS.

Navegue até a conta de armazenamento desejada no portal do Azure. Na tabela de conteúdo da conta de armazenamento desejada, selecione Chaves de acesso no título Segurança + rede . No painel Chave de acesso , selecione Girar chave acima da chave desejada.

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

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

Depois de habilitar Microsoft Entra autenticação Kerberos, você precisará conceder explicitamente o consentimento do administrador ao novo aplicativo Microsoft Entra registrado em seu locatário Microsoft Entra para concluir sua configuração. Você pode configurar as permissões de API do portal do Azure 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 de administrador para "DirectoryName".

Erros potenciais ao habilitar Microsoft Entra autenticação Kerberos para usuários híbridos

Você pode encontrar os seguintes erros ao habilitar Microsoft Entra autenticação Kerberos para contas de usuário híbridas.

Erro – Conceder consentimento do administrador desabilitado

Em alguns casos, Microsoft Entra administrador pode desabilitar a capacidade de conceder o consentimento do administrador para Microsoft Entra aplicativos. Abaixo está a captura de tela de como isso pode ser no portal do Azure.

Captura de tela que mostra a folha

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

Erro - "A solicitação para 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 Microsoft Entra autenticação Kerberos, 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 em todo o locatário que:
    • Não tem data de início ou tem uma data de início antes de 1º de janeiro de 2019.
    • Define uma restrição em senhas de entidade de serviço, que não permite senhas personalizadas ou define um tempo de vida máximo de senha de menos de 365,5 dias.

No momento, não há solução alternativa para esse erro.

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

Você também pode encontrar esse erro se tiver habilitado anteriormente Microsoft Entra autenticação Kerberos por meio de etapas de visualização limitada manual. Para excluir o aplicativo existente, o cliente ou seu administrador de TI podem executar o script a seguir. Executar esse script removerá o aplicativo criado manualmente antigo 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 em Microsoft Entra ID

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

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

Certifique-se de salvar 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 nível de arquivo usando o 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 solução alternativa.

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

Depois de reconfigurar Microsoft Entra Kerberos, a nova experiência criará automaticamente e gerenciará 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 Microsoft Entra autenticação Kerberos, ao tentar montar um compartilhamento de arquivos por meio net use ou outro método, o cliente será solicitado a obter credenciais. O usuário provavelmente digitará suas credenciais, mas as credenciais são rejeitadas.

Motivo

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 tíquete Kerberos para a conta de armazenamento porque o link privado FQDN não está registrado em nenhum aplicativo de 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 o identifierUris necessário ao objeto de aplicativo usando o portal do Azure 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, 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 o novo identifierUris.

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

  10. Tente novamente montar o compartilhamento.

Erro AADSTS50105

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

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

Motivo

Se você configurar "atribuição necessária" para o aplicativo empresarial correspondente, não poderá obter um tíquete Kerberos e Microsoft Entra logs de entrada 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 Microsoft Entra aplicativo para a conta de armazenamento porque não preenchemos direitos no tíquete Kerberos que é retornado de volta 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

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.