Compartilhar via

Resolver problemas de autenticação e autorização (SMB) baseados na identidade dos Ficheiros do Azure

  • Artigo

Este artigo lista problemas comuns ao utilizar partilhas de ficheiros do Azure SMB com autenticação baseada em identidade. Também fornece possíveis causas e resoluções para estes problemas. A autenticação baseada em identidade não é atualmente suportada para partilhas de ficheiros do Azure NFS.

Aplicável a

Tipo de partilha de ficheiros SMB NFS
Partilhas de ficheiros standard (GPv2), LRS/ZRS
Partilhas de ficheiros standard (GPv2), GRS/GZRS
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS

Erro ao executar o módulo AzFilesHybrid

Quando tenta executar o módulo AzFilesHybrid, poderá receber o seguinte erro:

O cliente não detém um privilégio necessário.

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

Este problema ocorre porque 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 contacte o administrador do AD para fornecer os privilégios necessários.

Erro 5 ao montar uma partilha de ficheiros do Azure

Quando tenta montar uma partilha de ficheiros, poderá receber o seguinte erro:

Ocorreu o erro de sistema 5. Acesso negado.

Causa: As permissões ao nível da partilha estão incorretas

Se os utilizadores finais estiverem a aceder à partilha de ficheiros do Azure com os Serviços de Domínio do Active Directory (AD DS) ou a autenticação do Microsoft Entra Domain Services, o acesso à partilha de ficheiros falhará com o erro "Acesso negado" se as permissões ao nível da partilha estiverem incorretas.

Observação

Este erro pode ser causado por problemas que não sejam permissões incorretas ao nível da partilha. Para obter informações sobre outras causas e soluções possíveis, veja Resolver problemas de conectividade e acesso dos Ficheiros do Azure.

Solução

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

  • Serviços de Domínio do Active Directory (AD DS) veja Atribuir permissões ao nível da partilha.

    As atribuições de permissões ao nível da partilha são suportadas para grupos e utilizadores que foram sincronizados do AD DS com o Microsoft Entra ID através do Microsoft Entra Connect Sync ou da sincronização da cloud do Microsoft Entra Connect. Confirme que os grupos e utilizadores a quem são atribuídas permissões ao nível da partilha não são grupos "apenas na cloud" não suportados.

  • Microsoft Entra Domain Services consulte Atribuir permissões ao nível da partilha.

Erro AadDsTenantNotFound ao ativar a autenticação do Microsoft Entra Domain Services para os Ficheiros do Azure "Não é possível localizar inquilinos ativos com o ID de inquilino do Microsoft Entra tenant-id"

Motivo

Erro AadDsTenantNotFound ocorre quando tenta ativar a autenticação do Microsoft Entra Domain Services para os Ficheiros do Azure numa conta de armazenamento onde o Microsoft Entra Domain Services não é criado no inquilino do Microsoft Entra da subscrição associada.

Solução

Ative o Microsoft Entra Domain Services no inquilino do Microsoft Entra da subscrição na qual a sua conta de armazenamento está implementada. Precisa de privilégios de administrador do inquilino do Microsoft Entra para criar um domínio gerido. Se não for o administrador do inquilino do Microsoft Entra, contacte o administrador e siga a documentação de orientação passo a passo para criar e configurar um domínio gerido do Microsoft Entra Domain Services.

Não é possível montar partilhas de ficheiros do Azure com credenciais do AD

Passos de autodiagnósdia

Primeiro, certifique-se de que seguiu os passos para ativar a Autenticação do Azure Files AD DS.

Em segundo lugar, experimente montar a partilha de ficheiros do Azure com a chave da conta de armazenamento. Se a partilha não conseguir montar, transfira AzFileDiagnostics para o ajudar a validar o ambiente de execução do cliente. O AzFileDiagnostics consegue detetar configurações de cliente incompatíveis que podem causar falhas de acesso nos Ficheiros do Azure, fornecer orientações prescritivas sobre a correção automática e recolher os rastreios de diagnóstico.

Em terceiro lugar, pode executar o Debug-AzStorageAccountAuth cmdlet para realizar um conjunto de verificações básicas na configuração do AD com o utilizador do AD com sessão iniciada. Este cmdlet é suportado na versão AzFilesHybrid v0.1.2+. Tem de executar este cmdlet com um utilizador 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 efetua estas verificações em sequência e fornece orientações para falhas:

  1. CheckADObjectPasswordIsCorrect: certifique-se de que a palavra-passe configurada na identidade do AD que representa a conta de armazenamento corresponde à da conta de armazenamento kerb1 ou kerb2. Se a palavra-passe estiver incorreta, pode executar Update-AzStorageAccountADObjectPassword para repor a palavra-passe.
  2. CheckADObject: confirme que existe um objeto no Active Directory que representa a conta de armazenamento e que tem o SPN correto (nome do principal de serviço). Se o SPN não estiver configurado corretamente, execute o Set-AD cmdlet devolvido no cmdlet de depuração para configurar o SPN.
  3. CheckDomainJoined: valide se o computador cliente está associado ao domínio ao AD. Se o seu computador não estiver associado a um domínio ao AD, consulte Associar um Computador a um Domínio para obter instruções de associação a um domínio.
  4. CheckPort445Connectivity: verifique se a porta 445 está aberta para a ligação SMB. Se a porta 445 não estiver aberta, veja a ferramenta de resolução de problemas AzFileDiagnostics para problemas de conectividade com os Ficheiros do Azure.
  5. CheckSidHasAadUser: verifique se o utilizador com sessão iniciada no AD está sincronizado com o ID do Microsoft Entra. Se quiser saber se um utilizador específico do AD está sincronizado com o Microsoft Entra ID, pode especificar o -UserName e -Domain nos parâmetros de entrada. Para um determinado SID, verifica se existe um utilizador do Microsoft Entra associado.
  6. CheckAadUserHasSid: verifique se o utilizador com sessão iniciada no AD está sincronizado com o ID do Microsoft Entra. Se quiser saber se um utilizador específico do AD está sincronizado com o Microsoft Entra ID, pode especificar o -UserName e -Domain nos parâmetros de entrada. Para um determinado utilizador do Microsoft Entra, verifica o respetivo SID. Para executar esta verificação, tem de fornecer o -ObjectId parâmetro, juntamente com o ID de objeto do utilizador do Microsoft Entra.
  7. CheckGetKerberosTicket: tente obter uma permissão Kerberos para ligar à conta de armazenamento. Se não existir 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 obtenção de pedidos.
  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, ative a autenticação do AD DS nos Ficheiros do Azure.
  9. CheckUserRbacAssignment: verifique se a identidade do AD tem a atribuição de função RBAC adequada para fornecer permissões ao nível da partilha para aceder aos Ficheiros do Azure. Caso contrário, configure a permissão ao nível da partilha. (Suportado na versão AzFilesHybrid v0.2.3+
  10. CheckUserFileAccess: verifique se a identidade do AD tem a permissão de diretório/ficheiro (ACLs do Windows) adequada para aceder aos Ficheiros do Azure. Caso contrário, configure a permissão ao nível do diretório/ficheiro. Para executar esta verificação, tem de indicar o -FilePath parâmetro, juntamente com o caminho do ficheiro montado ao qual pretende depurar o acesso. (Suportado na versão AzFilesHybrid v0.2.3+
  11. CheckAadKerberosRegistryKeyIsOff: verifique se a chave de registo do Microsoft Entra Kerberos 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 uma linha de comandos elevada para a desativar e, em seguida, reinicie o computador. (Suportado na versão AzFilesHybrid v0.2.9+

Se apenas quiser executar uma subeleção das verificações anteriores, pode utilizar o -Filter parâmetro, juntamente com uma lista separada por vírgulas de verificações a executar. Por exemplo, para executar todas as verificações relacionadas com permissões ao nível da partilha (RBAC), utilize 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 tiver a partilha de ficheiros montada no X:e se apenas quiser executar a verificação relacionada com permissões ao nível do ficheiro (ACLs do Windows), pode 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 partilhas de ficheiros do Azure com o Microsoft Entra Kerberos

Passos de autodiagnósdia

Primeiro, certifique-se de que seguiu os passos para ativar a autenticação Microsoft Entra Kerberos.

Em segundo lugar, pode executar o Debug-AzStorageAccountAuth cmdlet para executar um conjunto de verificações básicas. Este cmdlet é suportado para contas de armazenamento configuradas para autenticação Microsoft Entra Kerberos, na versão AzFilesHybrid v0.3.0 ou superior.

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

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

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

  1. CheckPort445Connectivity: verifique se a porta 445 está aberta para a ligação SMB. Se a porta 445 não estiver aberta, utilize a ferramenta de resolução de problemas AzFileDiagnostics para problemas de conectividade com os Ficheiros do Azure.
  2. CheckAADConnectivity: verifique a conectividade do Entra. As montagens SMB com autenticação Kerberos podem falhar se o cliente não conseguir contactar o Entra. Se esta verificação falhar, indica que existe um erro de rede (talvez um problema de firewall ou VPN).
  3. CheckEntraObject: confirme que existe um objeto no Entra que representa a conta de armazenamento e tem o nome do principal de serviço (SPN) correto. Se o SPN não estiver configurado corretamente, desative e reative a autenticação Entra Kerberos na conta de armazenamento.
  4. CheckRegKey: verifique se a chave do CloudKerberosTicketRetrieval registo está ativada. Esta chave de registo é necessária para a autenticação Entra Kerberos.
  5. CheckRealmMap: verifique se o utilizador configurou mapeamentos de domínios que associariam a conta a outro domínio Kerberos do que 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 uma permissão Kerberos.

Se apenas quiser executar uma subeleção das verificações anteriores, pode utilizar o -Filter parâmetro, juntamente com uma lista separada por vírgulas de verificações a executar.

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

Sintoma

Poderá deparar-se com um dos sintomas descritos abaixo ao tentar configurar ACLs do Windows com o Explorador de Ficheiros numa partilha de ficheiros montada:

  • Depois de clicar em Editar permissão no separador Segurança, o Assistente de permissões não carrega.
  • Quando tenta selecionar um novo utilizador ou grupo, a localização do domínio não apresenta o domínio do AD DS correto.
  • Está a utilizar 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. Certifique-se de que os controladores de domínio do Active Directory estão disponíveis e tente selecionar os objetos novamente."

Solução

Recomendamos que configure as permissões ao nível do diretório/ficheiro com icacls em vez de utilizar o Explorador de Ficheiros do Windows.

Erros ao executar Join-AzStorageAccountForAuth cmdlet

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

Este erro pode ocorrer se um controlador de domínio que contém a função FSMO mestre de RID estiver indisponível ou tiver sido removido do domínio e restaurado a partir da cópia de segurança. Confirme que todos os Controladores de Domínio estão em execução e disponíveis.

Erro: "Não é possível vincular parâmetros posicionais porque não foram atribuídos nomes"

Este erro é provavelmente acionado por um erro de sintaxe no Join-AzStorageAccountforAuth comando. Verifique se existem 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 do AD DS no local dos Ficheiros do Azure para encriptação Kerberos AES-256

Os Ficheiros do Azure suportam a encriptação Kerberos AES-256 para autenticação do AD DS, começando com o módulo AzFilesHybrid v0.2.2. AES-256 é o método de encriptação recomendado e é o método de encriptação predefinido que começa no módulo AzFilesHybrid v0.2.5. Se tiver ativado a autenticação do AD DS com uma versão de módulo inferior à v0.2.2, terá de transferir o módulo AzFilesHybrid mais recente e executar o PowerShell abaixo. Se ainda não ativou a autenticação do AD DS na sua conta de armazenamento, siga esta documentação de orientação.

Importante

Se estava a utilizar anteriormente a encriptação RC4 e atualizou a conta de armazenamento para utilizar a AES-256, deve executar klist purge no cliente e, em seguida, montar novamente a partilha de ficheiros para obter novas permissões Kerberos com a 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 irá rodar as chaves Kerberos, que é necessário para mudar para AES-256. Não é necessário voltar a rodar, a menos que pretenda regenerar ambas as palavras-passe.

Anteriormente, a identidade de utilizador com a atribuição da função Proprietário ou Contribuidor ainda tem acesso à chave da conta de armazenamento

As funções Proprietário e Contribuidor da conta de armazenamento concedem a capacidade de listar as chaves da conta de armazenamento. A chave da conta de armazenamento permite o acesso total aos dados da conta de armazenamento, incluindo partilhas de ficheiros, contentores de blobs, tabelas e filas, e acesso limitado às operações de gestão dos Ficheiros do Azure através das APIs de gestão legadas expostas através da API FileREST. Se estiver a alterar as atribuições de funções, deve considerar que os utilizadores que estão a ser removidos das funções Proprietário ou Contribuidor podem continuar a manter o acesso à conta de armazenamento através de chaves de conta de armazenamento guardadas.

Solução 1

Pode resolver este problema facilmente ao rodar as chaves da conta de armazenamento. Recomendamos que rode as teclas uma de cada vez, ao mudar o acesso de uma para a outra à medida que são rodadas. Existem dois tipos de chaves partilhadas 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 partilhado entre a conta de armazenamento e o controlador de domínio do Windows Server Active Directory para cenários do Windows Server Active Directory.

Para rodar as chaves Kerberos de uma conta de armazenamento, veja Atualizar a palavra-passe da identidade da conta de armazenamento no AD DS.

Navegue para a conta de armazenamento pretendida no portal do Azure. No índice da conta de armazenamento pretendida, selecione Chaves de acesso no cabeçalho Segurança + rede . No painel Tecla de acesso , selecione Rodar chave acima da chave pretendida.

Captura de ecrã a mostrar o painel

Definir as permissões da API numa aplicação recentemente criada

Depois de ativar a autenticação Microsoft Entra Kerberos, terá de conceder explicitamente o consentimento do administrador à nova aplicação Microsoft Entra registada no seu inquilino do Microsoft Entra para concluir a configuração. Pode configurar as permissões da API a partir do portal do Azure ao seguir estes passos.

  1. Abra o Microsoft Entra ID.
  2. Selecione Registos de aplicações no painel esquerdo.
  3. Selecione Todas as Aplicações no painel direito.
  4. Selecione a aplicação com o nome correspondente a [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".

Potenciais erros ao ativar a autenticação Microsoft Entra Kerberos para utilizadores híbridos

Poderá encontrar os seguintes erros ao ativar a autenticação Microsoft Entra Kerberos para contas de utilizador híbridas.

Erro – Conceder consentimento do administrador desativado

Em alguns casos, o administrador do Microsoft Entra pode desativar a capacidade de conceder consentimento do administrador às aplicações do Microsoft Entra. Abaixo encontra-se a captura de ecrã do aspeto que isto poderá ter no portal do Azure.

Captura de ecrã que mostra o painel

Se for este o caso, peça ao seu administrador do Microsoft Entra para conceder o consentimento do administrador à nova aplicação Microsoft Entra. Para localizar e ver os administradores, selecione funções e administradores e, em seguida, selecione Administrador de aplicações na cloud.

Erro – "O pedido ao Azure AD Graph falhou com o código BadRequest"

Causa 1: uma política de gestão de aplicações está a impedir a criação de credenciais

Ao ativar a autenticação Microsoft Entra Kerberos, poderá deparar-se com este erro se forem cumpridas as seguintes condições:

  1. Está a utilizar a funcionalidade beta/pré-visualização das políticas de gestão de aplicações.
  2. O utilizador (ou o administrador) definiu uma política ao nível do inquilino que:
    • Não tem data de início nem data de início antes de 1 de janeiro de 2019.
    • Define uma restrição às palavras-passe do principal de serviço, que não permitem palavras-passe personalizadas ou definem uma duração máxima de palavra-passe inferior a 365,5 dias.

Atualmente, não existe nenhuma solução para este erro.

Causa 2: já existe uma aplicação para a conta de armazenamento

Também poderá deparar-se com este erro se tiver ativado anteriormente a autenticação Microsoft Entra Kerberos através de passos de pré-visualização limitados manuais. Para eliminar a aplicação existente, o cliente ou o respetivo administrador de TI pode executar o seguinte script. A execução deste script removerá a aplicação antiga criada manualmente e permitirá que a nova experiência crie e faça a gestão automática da aplicação criada recentemente. Depois de iniciar a ligação ao Microsoft Graph, inicie sessão na aplicação Ferramentas de Linha de Comandos do Microsoft Graph no seu dispositivo e conceda permissões à aplicação.

$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 palavra-passe do principal de serviço expirou no ID do Microsoft Entra

Se tiver ativado anteriormente a autenticação Microsoft Entra Kerberos através de passos de pré-visualização manual limitados, a palavra-passe do principal de serviço da conta de armazenamento está definida para expirar a cada seis meses. Assim que a palavra-passe expirar, os utilizadores não conseguirão obter permissões Kerberos para a partilha de ficheiros.

Para mitigar esta situação, tem duas opções: rodar a palavra-passe do principal de serviço no Microsoft Entra a cada seis meses ou seguir estes passos para desativar o Microsoft Entra Kerberos, eliminar a aplicação existente e reconfigurar o Microsoft Entra Kerberos.

Certifique-se de que guarda as propriedades de domínio (domainName e domainGUID) antes de desativar o Microsoft Entra Kerberos, pois irá precisar das mesmas durante a reconfiguração se pretender configurar permissões ao nível do diretório e do ficheiro com o Explorador de Ficheiros do Windows. Se não guardou as propriedades de domínio, ainda pode configurar permissões ao nível do diretório/ficheiro com icacls como solução.

  1. Desativar o Microsoft Entra Kerberos
  2. Eliminar a aplicação existente
  3. Reconfigurar o Microsoft Entra Kerberos através do portal do Azure

Depois de reconfigurar o Microsoft Entra Kerberos, a nova experiência irá criar e gerir automaticamente a aplicação recém-criada.

Erro 1326 – O nome de utilizador ou palavra-passe está incorreto ao utilizar a ligação privada

Se estiver a ligar a uma conta de armazenamento através de um ponto final privado/ligação privada com a autenticação Microsoft Entra Kerberos, ao tentar montar uma partilha de ficheiros através net use ou de outro método, é pedida ao cliente as credenciais. É provável que o utilizador escreva as respetivas credenciais, mas as credenciais são rejeitadas.

Motivo

Isto acontece porque o cliente SMB tentou utilizar o Kerberos, mas falhou, pelo que volta a utilizar a autenticação NTLM e os Ficheiros do Azure não suportam a utilização da autenticação NTLM para credenciais de domínio. O cliente não consegue obter uma permissão Kerberos para a conta de armazenamento porque o FQDN de ligação privada não está registado em nenhuma aplicação Microsoft Entra existente.

Solução

A solução é adicionar o FQDN privateLink à aplicação Microsoft Entra da conta de armazenamento antes de montar a partilha de ficheiros. Pode adicionar os identifierUris necessários ao objeto de aplicação com o portal do Azure ao seguir estes passos.

  1. Abra o Microsoft Entra ID.

  2. Selecione Registos de aplicações no painel esquerdo.

  3. Selecione Todas as Aplicações.

  4. Selecione a aplicação com o nome correspondente a [Conta de Armazenamento] $storageAccountName.file.core.windows.net.

  5. Selecione Manifesto no painel esquerdo.

  6. Copie e cole o conteúdo existente para que 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 seu 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, 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. Reveja o conteúdo e selecione Guardar para atualizar o objeto da aplicação com os novos identifierUris.

  9. Atualize quaisquer referências DNS internas para apontar para a ligação privada.

  10. Repita a montagem da partilha.

Erro AADSTS50105

O pedido foi interrompido pelo seguinte erro AADSTS50105:

O administrador configurou a aplicação "Nome da aplicação empresarial" para bloquear os utilizadores, a menos que lhes seja concedido especificamente acesso (atribuído) à aplicação. O utilizador com sessão iniciada "{EmailHidden}" está bloqueado porque não é um membro direto de um grupo com acesso, nem teve acesso diretamente atribuído por um administrador. Contacte o administrador para atribuir acesso a esta aplicação.

Motivo

Se configurar a "atribuição necessária" para a aplicação empresarial correspondente, não poderá obter uma permissão Kerberos e os registos de início de sessão do Microsoft Entra mostrarão um erro, apesar de os utilizadores ou grupos estarem atribuídos à aplicação.

Solução

Não selecione Atribuição necessária para a aplicação Microsoft Entra para a conta de armazenamento porque não preenchamos as elegibilidades na permissão Kerberos que é devolvida ao requerente. Para obter mais informações, veja Erro AADSTS50105 – O utilizador com sessão iniciada não está atribuído a uma função para a aplicação.

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.