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

  • Artigo

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

Observação

Esse erro poderá 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, confira Solução de problemas de conectividade e acesso dos Arquivos do Azure.

Solução

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

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

    As atribuições de permissão em nível de compartilhamento têm suporte para grupos e usuários que foram sincronizados do AD DS para a ID do Microsoft Entra usando o Microsoft Entra Connect Sync ou o Microsoft Entra Connect Cloud Sync. Confirme se os grupos e usuários que recebem permissões em nível de compartilhamento não são grupos "somente nuvem" sem suporte.

  • Microsoft Entra Domain Services 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

O erro AadDsTenantNotFound ocorre 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.

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 necessárias para habilitar a autenticação do AD DS dos Arquivos do Azure.

Depois, 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 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 é compatível com a 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 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 ingressado no domínio do AD, consulte Ingressar um computador em um domínio para obter instruções de ingresso no 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 foi ativada 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 no nível do compartilhamento. (Compatível com a 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 os Arquivos do Azure. Caso contrário, configure a permissão de nível de diretório/arquivo. 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. (Compatível com a versão AzFilesHybrid v0.2.3+)
  11. 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 na versão 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 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, na versão AzFilesHybrid v0.3.0+.

$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 algum mapeamento de realm que uniria a conta a outro realm Kerberos que não KERBEROS.MICROSOFTONLINE.COM.
  6. CheckAdminConsent: verifique se a entidade de serviço do Entra recebeu consentimento de 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: verifica o serviço Auxiliar de IP (iphlpsvc) necessário para a autenticação Kerberos do Microsoft Entra. Seu estado deve ser definido como Running.

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.

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 ter um dos sintomas descritos abaixo ao tentar configurar ACLs do Windows com o Explorador de Arquivos em um compartilhamento de arquivos montado:

  • Após você clicar em Editar permissão na guia Segurança, o assistente de Permissão não será 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 as permissões de diretório/nível de arquivo usando o icacls em vez de usar o Explorador de Arquivos do Windows.

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 é acionado 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 (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 do módulo anterior à v0.2.2, será necessário baixar o módulo AzFilesHybrid mais recente e executar o PowerShell abaixo. Se você ainda não habilitou a autenticação do AD DS na sua conta de armazenamento, siga estas diretrizes.

Importante

Se você estava usando a criptografia RC4 anteriormente e atualiza a conta de armazenamento para usar o AES-256, deverá executar klist purge no cliente e, em seguida, remontar o compartilhamento de arquivos para obter novos tíquetes do 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 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 completo aos dados da conta de armazenamento, incluindo compartilhamentos de arquivos, contêineres de blob, tabelas e filas, e acesso limitado às operações de gerenciamento dos 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 mantendo o acesso à conta de armazenamento por meio das chaves da 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 girar as chaves Kerberos de uma conta de armazenamento, confira Atualizar a senha da identidade da sua 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 chave acima da chave desejada.

Captura de tela que mostra o painel 'Tecla 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ê precisará 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 do portal do Azure seguindo estas etapas.

  1. Abra o Microsoft Entra ID.
  2. Selecione Registros de aplicativo no painel de navegação esquerdo.
  3. Selecione Todos os Aplicativos no painel de navegação 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 de navegação esquerdo.
  6. Selecione Adicionar permissões na parte inferior da página.
  7. Selecione Fornecer o consentimento do administrador para "DirectoryName".

Possíveis erros ao habilitar a autenticação Kerberos para Microsoft Entra para usuários híbridos

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

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. Abaixo está a captura de tela de como isso é apresentado no portal do Azure.

Captura de tela que mostra a folha 'Permissões configuradas' exibindo um aviso de que algumas ações podem ser desabilitadas devido às suas permissões.

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 os 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 a versão beta/versão prévia do recurso das políticas de gerenciamento de aplicativos.
  2. Você (ou seu administrador) definiu uma política para todo o locatário 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 nível de diretório/arquivo usando icacls como 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 de navegação esquerdo.

  3. Selecionar 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 de aplicativo com o novo IdentifierUris.

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

  10. Tente montar novamente o compartilhamento.

Erro AADSTS50105

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 preenchemos os direitos 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

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.