Laboratório de Troubleshooting: Configure identity-based access for Azure Files
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento relatou que, após a migração de um servidor de arquivos on-premises para o Azure Files, os usuários conseguem montar o compartilhamento SMB e listar os diretórios raiz, mas recebem o erro "Access is denied" ao tentar abrir qualquer subdiretório ou arquivo.
O administrador verificou o seguinte antes de abrir o chamado:
- A autenticação AD DS on-premises está habilitada no storage account há duas semanas
- O grupo de segurança FS-Usuarios-Leitura possui a função Storage File Data SMB Share Reader atribuída no nível do compartilhamento
- O Microsoft Entra Connect está sincronizando normalmente, com o último ciclo concluído há 18 minutos
- O storage account tem o firewall configurado para permitir a rede da filial
A equipe informa ainda que o administrador anterior migrou os dados usando robocopy com a flag /copyall a partir de um servidor Windows Server 2019.
Evento observado no cliente ao acessar subdiretório:
Status: 0xC0000022 - STATUS_ACCESS_DENIED
SMB dialect: SMB 3.0
Authentication: Kerberos
Qual é a causa raiz do problema observado?
A) O firewall do storage account está bloqueando o tráfego SMB dos clientes da filial
B) A função Storage File Data SMB Share Reader não cobre acesso a subdiretórios; é necessária a função Storage File Data SMB Share Contributor
C) As permissões NTFS copiadas pelo robocopy /copyall não incluem o grupo do Entra ID/AD DS correto, bloqueando o acesso nos subdiretórios mesmo com o RBAC correto
D) O Microsoft Entra Connect não sincronizou os grupos a tempo e o Azure Files ainda não reconhece a associação do usuário ao grupo FS-Usuarios-Leitura
Cenário 2 — Decisão de Ação
A causa do problema já foi identificada: o storage account de produção está configurado com Microsoft Entra Kerberos como fonte de identidade, mas os clientes que precisam acessar o compartilhamento são máquinas ingressadas exclusivamente no AD DS on-premises, sem ingresso híbrido no Entra ID. Os usuários estão recebendo erros de autenticação ao tentar montar o compartilhamento.
O ambiente possui as seguintes restrições:
- O compartilhamento está em produção ativa com aproximadamente 200 usuários conectados via outros clientes compatíveis (máquinas híbridas)
- Alterar a fonte de identidade do storage account exige desabilitar a configuração atual e reabilitar com a nova fonte, o que força a remontagem de todos os clientes conectados
- A janela de manutenção programada é em 6 dias
- O time de suporte possui permissão de Contributor no storage account, mas não possui permissão para modificar atribuições de função RBAC no compartilhamento
Qual é a ação correta a tomar neste momento?
A) Alterar imediatamente a fonte de identidade para AD DS on-premises, pois a interrupção será breve e os 200 usuários reconectarão automaticamente
B) Ingressar as máquinas problemáticas no Entra ID de forma híbrida agora, resolvendo a incompatibilidade sem alterar o storage account
C) Documentar o problema, comunicar os stakeholders e executar a alteração da fonte de identidade durante a janela de manutenção em 6 dias
D) Criar um segundo storage account com AD DS on-premises configurado e migrar os dados antes da janela de manutenção
Cenário 3 — Causa Raiz
Um administrador recém-contratado configurou o Azure Files com autenticação AD DS on-premises seguindo a documentação oficial. O processo de registro do storage account no AD DS foi executado com o script AzFilesHybrid e concluiu sem erros. A função Storage File Data SMB Share Contributor foi atribuída ao grupo correto.
Ao tentar montar o compartilhamento a partir de uma máquina do domínio, o usuário recebe:
net use Z: \\storageaccount.file.core.windows.net\compartilhamento /persistent:yes
System error 5 has occurred.
Access is denied.
O administrador coletou as seguintes informações adicionais:
- O cmdlet
Get-AzStorageAccountADObjectretorna o objeto corretamente no AD DS - O tenant possui licenças Microsoft Entra ID P2 ativas para todos os usuários
- A conta de armazenamento foi criada há 3 dias na região Brazil South
- O comando
klistno cliente mostra que o ticket Kerberos foi emitido para o storage account com sucesso - O storage account não possui restrições de rede configuradas
klist output (resumido):
Client: usuario@contoso.com
Server: cifs/storageaccount.file.core.windows.net@CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags: forwardable, renewable, pre-authent
Qual é a causa raiz do problema observado?
A) O script AzFilesHybrid registrou o objeto corretamente, mas a sincronização com o Microsoft Entra Connect ainda não propagou a identidade para o Entra ID
B) As licenças Microsoft Entra ID P2 estão gerando conflito com o fluxo de autenticação AD DS, pois ativam políticas de acesso condicional por padrão
C) O ticket Kerberos foi emitido com sucesso, indicando que a autenticação passou; o bloqueio está na camada de autorização RBAC, que ainda não foi propagada para o storage account
D) O objeto registrado no AD DS perdeu a sincronização de senha com o storage account após a criação; é necessário executar Update-AzStorageAccountADObjectPassword
Cenário 4 — Sequência de Diagnóstico
Um usuário relata que não consegue acessar um compartilhamento Azure Files configurado com autenticação Microsoft Entra Kerberos. O sintoma reportado é erro de acesso negado ao tentar montar o compartilhamento via SMB a partir de uma máquina com ingresso híbrido.
Os passos abaixo representam ações de diagnóstico válidas, mas estão fora de ordem:
- Verificar se a função RBAC correta está atribuída ao usuário ou grupo no nível do compartilhamento
- Confirmar que o Microsoft Entra Kerberos está habilitado como fonte de identidade no storage account
- Executar
klistno cliente para verificar se o ticket Kerberos foi emitido para o storage account - Verificar as permissões NTFS no nível do diretório e arquivo dentro do compartilhamento
- Confirmar que o dispositivo do usuário está ingressado de forma híbrida no Entra ID
Qual é a sequência correta de diagnóstico para esse sintoma?
A) 2 -> 5 -> 1 -> 3 -> 4
B) 5 -> 2 -> 3 -> 1 -> 4
C) 1 -> 2 -> 5 -> 4 -> 3
D) 3 -> 5 -> 2 -> 1 -> 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está na combinação de dois fatos: o robocopy /copyall preserva todas as permissões NTFS do servidor de origem, e os usuários conseguem listar o diretório raiz mas não acessar subdiretórios. Isso indica que a camada RBAC está funcionando (a listagem do raiz é possível), mas as permissões NTFS herdadas do servidor antigo não incluem os grupos ou usuários do domínio na forma como o Azure Files os reconhece. O Azure Files aplica as duas camadas e a mais restritiva prevalece.
A informação sobre o firewall da filial é irrelevante para o diagnóstico: se o firewall estivesse bloqueando, o usuário não conseguiria nem montar o compartilhamento nem listar o raiz. A alternativa D é um distrator baseado no tempo de sincronização do Entra Connect, que também é irrelevante porque a autenticação Kerberos do cenário é emitida pelo AD DS local, não pelo Entra ID. A alternativa B representa um equívoco clássico de confundir as camadas: a função Reader cobre leitura em qualquer profundidade do compartilhamento; o bloqueio não é de RBAC.
O distrator mais perigoso é o D. Agir sobre ele levaria o administrador a aguardar uma nova sincronização do Entra Connect sem resolver o problema real, atrasando o diagnóstico correto.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é que há 200 usuários ativos conectados ao compartilhamento. Alterar a fonte de identidade força a remontagem de todos os clientes, causando interrupção imediata em produção. A janela de manutenção existe exatamente para absorver esse tipo de impacto.
A alternativa A ignora a restrição de impacto em produção. A alternativa B é tecnicamente válida como solução de longo prazo, mas ingressar 200 máquinas no Entra ID de forma híbrida é uma operação complexa que não pode ser executada sem planejamento, especialmente fora de uma janela de manutenção. A alternativa D introduz complexidade desnecessária (migração de dados, novo storage account) quando a solução correta é mais simples e já possui uma janela planejada.
O distrator mais perigoso é o A, pois apresenta a interrupção como algo trivial. Em produção, forçar a remontagem de 200 clientes sem aviso prévio pode causar perda de trabalho em andamento e violação de SLA.
Gabarito — Cenário 3
Resposta: D
A pista mais importante é o resultado do klist: o ticket Kerberos foi emitido com sucesso para o storage account. Isso elimina qualquer problema de autenticação e aponta para a camada de autorização ou de credencial do objeto AD. O objeto registrado no AD DS autentica-se no Azure Files usando uma senha que deve estar sincronizada entre o AD e o storage account. Essa senha tem validade e pode estar desatualizada ou nunca ter sido sincronizada corretamente após o registro.
A alternativa C parece lógica porque ticket Kerberos emitido sugere autenticação bem-sucedida, mas o erro ocorre antes da verificação RBAC: o mapeamento de identidade entre o objeto AD e o storage account falha quando a senha está fora de sincronia. A alternativa A é irrelevante para esse cenário porque o AD DS on-premises não depende do Entra Connect para emissão de tickets Kerberos locais. A alternativa B é um distrator que explora o dado irrelevante inserido propositalmente (licenças P2); licenças não interferem no fluxo de autenticação AD DS para Azure Files.
O distrator mais perigoso é o C. Agir sobre ele levaria o administrador a investigar e recriar atribuições RBAC que já estão corretas, sem jamais resolver o problema real.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 2 -> 5 -> 1 -> 3 -> 4
O raciocínio diagnóstico correto segue do geral para o específico, do nível de configuração para o nível de sessão:
- Passo 2 primeiro: confirmar que o Microsoft Entra Kerberos está habilitado é o pré-requisito de tudo. Se não estiver habilitado, nenhum outro passo é necessário.
- Passo 5 em seguida: verificar se o dispositivo tem ingresso híbrido válida se o cliente é elegível para esse método de autenticação.
- Passo 1 depois: com a configuração e o cliente validados, verificar o RBAC no compartilhamento.
- Passo 3 após: executar
klistconfirma se o ticket Kerberos foi de fato emitido, validando a camada de autenticação na sessão atual. - Passo 4 por último: permissões NTFS são a camada mais granular e devem ser investigadas apenas quando todas as camadas anteriores estiverem corretas.
A alternativa D começa pelo klist, que é um diagnóstico de sessão; executá-lo antes de validar a configuração do storage account e a elegibilidade do cliente gera informação sem contexto e pode levar a conclusões erradas.
Árvore de Troubleshooting: Configure identity-based access for Azure Files
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de um problema real, inicie pelo nó raiz que descreve o sintoma observado e responda cada pergunta de diagnóstico com base no que você pode verificar diretamente no ambiente: o portal do Azure, o resultado de comandos como klist e Get-AzStorageAccountADObject, e o estado das atribuições RBAC. Cada ramificação elimina uma hipótese e conduz ao nó de causa ou ação correspondente, evitando ações corretivas aplicadas antes do diagnóstico estar completo.