Laboratório Técnico: Configure identity-based access for Azure Files
Questões
Questão 1 — Múltipla Escolha
Uma equipe de administradores precisa habilitar autenticação baseada em identidade para um compartilhamento SMB no Azure Files. O ambiente possui controladores de domínio on-premises sincronizados com o Microsoft Entra ID via Microsoft Entra Connect, e os clientes acessam os arquivos a partir de máquinas ingressadas no domínio AD DS local.
Qual fonte de identidade deve ser configurada no storage account para que as permissões de nível de compartilhamento e de nível de arquivo funcionem corretamente nesse cenário?
A) Microsoft Entra Kerberos, pois é a única opção que valida tokens emitidos pelo Entra ID para clientes híbridos
B) AD DS on-premises, pois os clientes estão ingressados no domínio local e a autenticação Kerberos será emitida pelos DCs locais
C) Microsoft Entra Domain Services, pois oferece integração automática com a sincronização do Entra Connect
D) Nenhuma configuração adicional é necessária, pois o Entra Connect já propaga as identidades para o storage account automaticamente
Questão 2 — Cenário Técnico
Um administrador configurou autenticação AD DS on-premises para um compartilhamento Azure Files e atribuiu a função Storage File Data SMB Share Contributor a um grupo de usuários no nível do compartilhamento. Após a configuração, os usuários conseguem listar arquivos, mas não conseguem criar nem modificar arquivos existentes.
Permissão de nível de compartilhamento: Storage File Data SMB Share Contributor
Permissão de nível de diretório/arquivo (NTFS): Not configured (herdando padrão)
Qual é a causa mais provável do comportamento descrito?
A) A função Storage File Data SMB Share Contributor não cobre operações de escrita; a correta seria Storage File Data SMB Share Elevated Contributor
B) As permissões NTFS no nível de diretório/arquivo estão bloqueando escrita, pois o Azure Files aplica ambas as camadas e a permissão mais restritiva prevalece
C) A autenticação AD DS não suporta operações de escrita em compartilhamentos SMB; isso exige Microsoft Entra Kerberos
D) O storage account precisa ter o hierarchical namespace habilitado para que permissões de escrita funcionem via identidade
Questão 3 — Verdadeiro ou Falso
Ao configurar o Microsoft Entra Kerberos para acesso ao Azure Files, máquinas ingressadas exclusivamente no domínio AD DS on-premises (sem ingresso híbrido ou Entra ID join) conseguem autenticar-se utilizando esse método sem nenhuma configuração adicional no cliente.
Questão 4 — Cenário Técnico
Um administrador precisa que usuários externos (convidados B2B) acessem um compartilhamento Azure Files via SMB utilizando suas identidades corporativas já presentes no Microsoft Entra ID. O ambiente não possui AD DS on-premises.
Após habilitar Microsoft Entra Kerberos no storage account e atribuir a função Storage File Data SMB Share Reader aos convidados, os usuários relatam que não conseguem montar o compartilhamento.
Qual etapa foi omitida?
A) Os convidados precisam ser convertidos em membros nativos do tenant antes de acessar compartilhamentos SMB
B) É necessário habilitar o hierarchical namespace para que o Microsoft Entra Kerberos funcione com identidades externas
C) O acesso SMB com Microsoft Entra Kerberos requer que os clientes estejam ingressados no Entra ID ou sejam híbridos; convidados B2B não são suportados nesse fluxo
D) A função correta para convidados B2B é Storage File Data SMB Share Elevated Contributor; a função Reader não permite montagem
Questão 5 — Múltipla Escolha
Considerando as três fontes de identidade suportadas pelo Azure Files para autenticação SMB (AD DS on-premises, Microsoft Entra Domain Services e Microsoft Entra Kerberos), qual afirmação descreve corretamente uma diferença de comportamento entre elas?
A) Apenas o Microsoft Entra Domain Services exige que o storage account esteja na mesma região virtual que a rede gerenciada do serviço
B) O Microsoft Entra Kerberos emite tickets Kerberos diretamente pelo Entra ID, enquanto AD DS on-premises e Microsoft Entra Domain Services dependem de controladores de domínio para emissão dos tickets
C) O AD DS on-premises suporta montagem de compartilhamentos NFS, enquanto as demais opções suportam apenas SMB
D) O Microsoft Entra Domain Services não suporta permissões NTFS em nível de arquivo; apenas permissões de nível de compartilhamento via RBAC são aplicáveis
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Quando os clientes estão ingressados no AD DS on-premises e o ambiente usa o Microsoft Entra Connect apenas para sincronização, a emissão dos tickets Kerberos ocorre pelos controladores de domínio locais. O storage account deve ser configurado com a fonte AD DS on-premises, o que exige o registro da conta de armazenamento como objeto de computador ou conta de serviço no Active Directory local.
O principal erro das alternativas incorretas está em confundir sincronização de identidades (Entra Connect) com autenticação Kerberos: o Entra Connect não delega autenticação ao Entra ID automaticamente. O Microsoft Entra Kerberos é adequado para clientes com ingresso híbrido ou Entra ID join, não para clientes exclusivamente on-premises.
Gabarito — Questão 2
Resposta: B
O Azure Files aplica duas camadas independentes de controle de acesso: permissões de nível de compartilhamento via RBAC e permissões NTFS no nível de diretório e arquivo. Quando as permissões NTFS não são configuradas explicitamente, o comportamento padrão pode restringir escrita dependendo de como o compartilhamento foi criado. A permissão mais restritiva entre as duas camadas sempre prevalece.
A alternativa A é um distrator plausível, mas incorreta: a função Storage File Data SMB Share Contributor inclui leitura e escrita. A alternativa C é falsa; AD DS on-premises suporta escrita normalmente. A alternativa D confunde Azure Files com Azure Data Lake Storage Gen2, onde o namespace hierárquico é relevante para controle de acesso.
Gabarito — Questão 3
Resposta: Falso
O Microsoft Entra Kerberos exige que o dispositivo cliente esteja ingressado no Entra ID (Entra ID join) ou em ingresso híbrido (Hybrid Entra ID join). Máquinas ingressadas exclusivamente no AD DS on-premises não conseguem obter tokens do Entra ID para iniciar o fluxo de autenticação Kerberos via Entra, pois esse mecanismo depende da capacidade do cliente de se autenticar diretamente no Entra ID. Para esses clientes, a fonte correta é o AD DS on-premises.
Gabarito — Questão 4
Resposta: C
O Microsoft Entra Kerberos suporta usuários membros do tenant (incluindo cenários com ingresso híbrido), mas não suporta identidades de convidados B2B para montagem SMB. Esse é um limite explícito do método de autenticação: o fluxo de obtenção do ticket Kerberos via Entra ID não está disponível para identidades guest.
A alternativa A é incorreta porque a conversão de convidados em membros não é uma operação padrão do Azure Files. A alternativa B confunde Azure Files com Azure Data Lake Storage Gen2. A alternativa D é incorreta porque o problema não é de função RBAC insuficiente, mas de incompatibilidade fundamental entre o tipo de identidade e o método de autenticação.
Gabarito — Questão 5
Resposta: B
Esta é a diferença arquitetural central entre os três métodos. O Microsoft Entra Kerberos representa uma evolução em que o próprio Entra ID atua como Key Distribution Center (KDC), emitindo tickets Kerberos sem necessidade de controladores de domínio. Já o AD DS on-premises e o Microsoft Entra Domain Services dependem de DCs (locais ou gerenciados, respectivamente) para emissão dos tickets.
A alternativa A é parcialmente verdadeira quanto à rede, mas não descreve corretamente uma diferença de comportamento de autenticação. A alternativa C é falsa; o suporte a NFS no Azure Files é independente da fonte de identidade e não está vinculado ao AD DS. A alternativa D é falsa; o Microsoft Entra Domain Services suporta permissões NTFS normalmente, operando de forma equivalente ao AD DS on-premises nesse aspecto.