Fundamentação Teórica: Configure identity-based access for Azure Files

1. Intuição Inicial

Imagine que sua empresa tem um servidor de arquivos Windows tradicional: uma pasta compartilhada em rede onde cada funcionário acessa com seu login do Active Directory. O gerente vê tudo, o analista vê apenas a pasta do seu departamento, e o estagiário vê apenas os documentos públicos. Esse controle é feito por permissões NTFS vinculadas às identidades do AD.

O Azure Files é o equivalente dessa pasta compartilhada em rede, mas hospedada na nuvem como um serviço gerenciado. E o identity-based access (acesso baseado em identidade) é exatamente a capacidade de aplicar ao Azure Files o mesmo modelo de controle de acesso do Active Directory que você já conhece: autenticação com identidade, permissões por usuário e grupo, ACLs em nível de arquivo e diretório.

Sem acesso baseado em identidade, o Azure Files usa access keys (a chave física do cofre, como vimos no módulo anterior), onde qualquer um com a chave tem acesso total. Com acesso baseado em identidade, você preserva a granularidade e rastreabilidade do modelo Windows/Active Directory na nuvem.

2. Contexto

O Azure Files suporta o protocolo SMB (Server Message Block), o mesmo protocolo usado pelo Windows para compartilhamento de arquivos em rede. Isso significa que você pode montar um Azure File Share em um computador Windows como se fosse uma unidade de rede, usando a letra Z:\ por exemplo.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O acesso baseado em identidade ao Azure Files usa dois níveis de controle que trabalham em conjunto, exatamente como o modelo Windows:

Share-level permissions: o que o usuário pode fazer no file share como um todo (equivalente ao acesso de rede)
NTFS permissions (file-level): o que o usuário pode fazer em arquivos e diretórios específicos dentro do share (equivalente às permissões NTFS)

Ambos os níveis precisam permitir o acesso para que o usuário chegue ao arquivo. É uma lógica de AND: permissão no share E permissão no arquivo.

3. Construção dos Conceitos

3.1 Fontes de Identidade para Autenticação

O Azure Files suporta quatro fontes de identidade para autenticação baseada em identidade:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Fonte	Ambiente	Protocolo	Pré-requisito
AD DS on-premises	Híbrido	Kerberos	Domínio Windows local; storage account "ingressado" no domínio via script
Microsoft Entra Domain Services	Cloud-only	Kerberos	Entra ID DS provisionado; storage account habilitado para AADDS
Microsoft Entra ID (Kerberos)	Cloud / Híbrido	Kerberos	Dispositivos Entra joined ou Hybrid joined; funciona sem AD on-premises
Local AD DS (via Azure File Sync)	Híbrido com sync	Kerberos	Azure File Sync configurado; servidor on-premises como endpoint

Para o AZ-104, os dois cenários mais relevantes são o AD DS on-premises (cenário híbrido) e o Microsoft Entra ID Kerberos (cenário moderno para dispositivos Entra joined).

3.2 O Protocolo Kerberos e Por Que Importa

O Kerberos é o protocolo de autenticação usado tanto pelo AD tradicional quanto pelo Azure Files com identity-based access. Quando um cliente Windows acessa um Azure File Share com identidade, o processo é:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O KDC (Key Distribution Center) é a autoridade que emite os tickets. No AD DS on-premises, é o controlador de domínio. No Entra ID Kerberos, é o próprio Entra ID agindo como KDC.

As permissões no nível do share são controladas pelo Azure RBAC, usando papéis específicos para Azure Files:

Papel RBAC	O que permite	Equivalente Windows
Storage File Data SMB Share Reader	Leitura de arquivos e atributos	Read & Execute
Storage File Data SMB Share Contributor	Leitura, escrita e exclusão de arquivos	Modify
Storage File Data SMB Share Elevated Contributor	Leitura, escrita, exclusão E modificação de ACLs	Full Control
Storage File Data Privileged Reader	Leitura incluindo permissões (para backup/restore)	Backup Operator
Storage File Data Privileged Contributor	Acesso completo incluindo permissões para backup	Backup Operator com escrita

Esses papéis são atribuídos no escopo do storage account (não no file share individual, pois a granularidade de RBAC não vai até o share diretamente no modelo atual).

Importante: os papéis Storage File Data SMB Share * são DataActions, não Actions. Eles controlam o acesso aos dados via SMB, não o gerenciamento do storage account.

3.4 NTFS Permissions: Controle Granular por Arquivo e Diretório

As NTFS ACLs (Access Control Lists) são permissões definidas diretamente nos arquivos e diretórios dentro do file share. Elas funcionam exatamente como as permissões NTFS no Windows:

Permissão NTFS	O que permite
Full Control	Tudo, incluindo modificar permissões
Modify	Ler, escrever, executar, excluir
Read & Execute	Ler e executar arquivos
Read	Apenas leitura
Write	Criar e modificar arquivos
List Folder Contents	Ver conteúdo de diretórios

As ACLs NTFS são definidas de dentro do Windows (via Explorer, icacls, PowerShell) depois que o share está montado. Elas são armazenadas nos metadados dos arquivos no Azure Files e persistem.

3.5 A Lógica dos Dois Níveis

A combinação dos dois níveis funciona assim:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O share-level é o portão de entrada: sem ele, o share não monta. O NTFS é o controle interno: mesmo com o share montado, o acesso a arquivos específicos pode ser negado.

Caso especial: ao habilitar identity-based access pela primeira vez, o Azure atribui automaticamente Full Control a todos os usuários autenticados nas ACLs NTFS da raiz do share. Isso significa que, para restrições granulares, você precisa configurar as ACLs NTFS explicitamente depois de montar o share.

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Configuração para AD DS On-Premises (Cenário Híbrido)

Este é o caminho mais usado em empresas que já têm AD Windows local:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Passo 2 em detalhes: o módulo AzFilesHybrid é um módulo PowerShell disponível no GitHub da Microsoft que executa o processo de "domain join" do storage account. O que isso significa tecnicamente: ele cria um objeto de conta de computador (ou conta de serviço) no AD local representando o storage account, e registra a relação no Azure. Depois disso, o storage account aceita tickets Kerberos emitidos pelo seu AD.

# Instalar o módulo AzFilesHybrid
Install-Module -Name AzFilesHybrid

# Conectar ao Azure
Connect-AzAccount

# Executar o join do storage account ao domínio
Join-AzStorageAccountForAuth `
  -ResourceGroupName "rg-producao" `
  -StorageAccountName "minhaconta" `
  -DomainAccountType "ComputerAccount" `
  -OrganizationalUnitDistinguishedName "OU=AzureFileStorage,DC=contoso,DC=com"

Configuração para Microsoft Entra ID Kerberos (Cenário Moderno)

Para dispositivos Entra joined ou Hybrid joined sem necessidade de AD on-premises:

# Habilitar Entra ID Kerberos no storage account via CLI
az storage account update \
  --name minhaconta \
  --resource-group rg-producao \
  --enable-files-aadkerb true

Após habilitar, os usuários com dispositivos Entra joined podem acessar o share usando suas credenciais do Entra ID, sem precisar de um AD on-premises.

Requisito adicional: o cliente Windows precisa ter a extensão de Kerberos do Entra ID instalada. Em Windows 11 e Windows 10 21H2+, isso já está disponível. Em versões mais antigas, requer atualização.

Comportamentos Importantes e Não Óbvios

ACLs NTFS vs. Share-level: qual prevalece? A permissão mais restritiva de cada nível se aplica. Se o share-level diz "Contributor" (ler e escrever) mas a ACL NTFS no arquivo diz "Read only", o usuário só pode ler. Se o share-level diz "Reader" mas a ACL NTFS diz "Full Control", o usuário ainda só pode ler (o share-level é o limitante superior).

O storage account precisa ser "domain joined" para aceitar Kerberos: diferente do Blob Storage, onde qualquer storage account aceita autenticação Entra ID via RBAC, o Azure Files requer uma etapa explícita de configuração (domain join ou habilitar Entra Kerberos) para aceitar autenticação de identidade. Um storage account não configurado só aceita access keys.

ACLs são preservadas no Azure Files: as ACLs NTFS configuradas em arquivos e diretórios são armazenadas como metadados no Azure Files e persistem. Se você desmonta o share, reconfigura as permissões e monta novamente, as ACLs NTFS ainda estão lá.

Sincronização de senhas do AD: para o cenário com AD DS on-premises, as senhas dos usuários AD não são sincronizadas para o Azure. A autenticação Kerberos funciona porque o AD local emite tickets que o Azure Files valida, sem nunca ver a senha do usuário.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: verificar o estado da configuração, atribuir share-level permissions (RBAC), configurar qual fonte de identidade está habilitada.

Caminho para habilitar identity-based access: Storage Account > File shares > Active Directory

Nessa tela você vê o status de cada opção:

Windows Server Active Directory (AD DS on-premises): Configured / Not configured
Microsoft Entra Domain Services: Enabled / Disabled
Microsoft Entra Kerberos: Enabled / Disabled

Caminho para share-level permissions: Storage Account > Access control (IAM) > Add role assignment

Selecionar um dos papéis Storage File Data SMB Share * e atribuir ao usuário ou grupo.

Limitação: o domain join para AD DS on-premises não pode ser feito pelo portal. Requer o módulo PowerShell AzFilesHybrid.

6.2 PowerShell

Verificar o status da configuração de identity-based access:

Get-AzStorageAccount `
  -ResourceGroupName "rg-producao" `
  -Name "minhaconta" |
  Select-Object -ExpandProperty AzureFilesIdentityBasedAuth

Habilitar Microsoft Entra Domain Services:

Set-AzStorageAccount `
  -ResourceGroupName "rg-producao" `
  -Name "minhaconta" `
  -EnableAzureActiveDirectoryDomainServicesForFile $true

Configurar NTFS ACLs via icacls (executado de dentro do share montado):

# Montar o share com access key para configurar ACLs iniciais
$connectTestResult = Test-NetConnection -ComputerName "minhaconta.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    $password = ConvertTo-SecureString -String "<access-key>" -AsPlainText -Force
    $credential = New-Object System.Management.Automation.PSCredential("Azure\minhaconta", $password)
    New-PSDrive -Name Z -PSProvider FileSystem `
      -Root "\\minhaconta.file.core.windows.net\meu-share" `
      -Credential $credential
}

# Configurar ACL NTFS para um grupo AD
icacls Z:\ /grant "CONTOSO\Grupo-Financeiro:(OI)(CI)(M)"

# Configurar ACL NTFS para pasta específica
icacls "Z:\Projetos\Confidencial" /grant "CONTOSO\Gerentes:(OI)(CI)(F)"
icacls "Z:\Projetos\Confidencial" /deny "CONTOSO\Estagiarios:(OI)(CI)(R)"

As flags do icacls significam:

(OI): Object Inherit - aplica a arquivos dentro do diretório
(CI): Container Inherit - aplica a subdiretórios
(M): Modify
(F): Full Control
(R): Read

6.3 Azure CLI

Verificar configuração de identity-based access:

az storage account show \
  --name minhaconta \
  --resource-group rg-producao \
  --query "azureFilesIdentityBasedAuth" \
  --output json

Habilitar Microsoft Entra Kerberos:

az storage account update \
  --name minhaconta \
  --resource-group rg-producao \
  --enable-files-aadkerb true

Habilitar Microsoft Entra Domain Services:

az storage account update \
  --name minhaconta \
  --resource-group rg-producao \
  --enable-files-aadds true

Atribuir papel share-level via CLI:

az role assignment create \
  --assignee "grupo-financeiro@contoso.com" \
  --role "Storage File Data SMB Share Contributor" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Storage/storageAccounts/minhaconta"

7. Controle e Segurança

A Separação Entre Montagem e Acesso a Dados

Um comportamento crítico para o diagnóstico: o share-level permission controla se o share pode ser montado, mas não é verificado a cada operação de arquivo. A ACL NTFS é verificada a cada acesso a arquivo ou diretório.

Isso significa:

Usuário sem share-level permission: não consegue montar o share (erro na conexão SMB)
Usuário com share-level permission mas sem NTFS permission: monta o share, mas recebe "Acesso negado" ao tentar abrir arquivos específicos

Permissão de "Superusuário" para Configuração Inicial

Existe um papel especial para administradores que precisam configurar ACLs NTFS sem restrições: Storage File Data Privileged Contributor. Ele concede acesso privilegiado que ignora as ACLs NTFS existentes, permitindo que o administrador configure as permissões iniciais mesmo em um share onde as ACLs bloqueiam o acesso.

Na prática, o fluxo recomendado para configuração inicial é:

Montar o share usando a access key (que sempre tem acesso total)
Configurar as ACLs NTFS corretas
Após configuração, aplicar o share-level RBAC para os usuários finais
Futuramente, administradores usam o papel Privileged Contributor quando precisam ajustar ACLs

Compatibilidade de Protocolos

Protocolo	Suporta identity-based auth?	Notas
SMB 3.0+	Sim	Principal protocolo, com criptografia
SMB 2.1	Sim	Sem criptografia in-transit
NFS 4.1	Não	Azure Files NFS usa controle de acesso baseado em rede (VNet), não identidade
REST API	Não (via Entra RBAC DataActions)	Não é SMB; usa modelo diferente de autenticação

O acesso via NFS 4.1 ao Azure Files (disponível apenas em shares Premium) usa um modelo completamente diferente: o controle de acesso é baseado em rede (restrição por IP/VNet) e em UID/GID Linux, não em AD ou Entra ID. Esse protocolo é para cargas de trabalho Linux e HPC, não para o cenário Windows descrito neste módulo.

8. Tomada de Decisão

Qual fonte de identidade escolher?

Situação	Fonte recomendada	Motivo
Empresa com AD on-premises e VMs domain-joined na Azure	AD DS on-premises	Reutiliza identidades existentes, sem infraestrutura adicional
Empresa cloud-only sem AD, usuários em VMs Azure	Microsoft Entra Domain Services	AD como serviço gerenciado, sem servidores para manter
Dispositivos modernos (Windows 10/11 Entra joined) sem VMs	Microsoft Entra ID Kerberos	Mais simples, sem Entra DS, mais moderno
Filial sem AD local que precisa acessar shares	Microsoft Entra ID Kerberos	Não requer AD local na filial
Workloads Linux que precisam de acesso compartilhado	NFS 4.1 com restrição de rede	Identity-based auth não se aplica ao NFS

Situação	Papel	Motivo
Usuários regulares que leem e editam arquivos	Storage File Data SMB Share Contributor	Permite ler, escrever e excluir
Usuários que só consultam arquivos	Storage File Data SMB Share Reader	Menor privilégio
Admin que precisa configurar ACLs NTFS	Storage File Data SMB Share Elevated Contributor	Pode modificar permissões
Sistema de backup que precisa acessar tudo	Storage File Data Privileged Reader / Contributor	Ignora ACLs para backup completo

9. Boas Práticas

Configure share-level permissions com grupos, não usuários individuais: exatamente como no RBAC geral do Azure, atribuir papéis a grupos facilita a gestão. Um novo funcionário no departamento financeiro entra para o grupo "Grupo-Financeiro" e automaticamente herda as permissões SMB Share do grupo.

Configure ACLs NTFS espelhando a estrutura de pastas do negócio: a hierarquia de permissões NTFS deve refletir a estrutura organizacional. Crie grupos AD para cada nível de acesso necessário ("Leitores-Projetos", "Editores-Projetos-Alpha", etc.) e configure as ACLs NTFS usando esses grupos.

Use herança de ACLs NTFS: ao configurar ACLs com flags (OI)(CI), as permissões se propagam automaticamente para novos arquivos e subdiretórios criados dentro da pasta. Isso elimina a necessidade de reconfigurar permissões manualmente para cada novo arquivo.

Mantenha o objeto de computador do AD sincronizado: no cenário com AD DS on-premises, o storage account é representado como um objeto de computador no AD com uma senha que expira periodicamente. O módulo AzFilesHybrid tem um cmdlet para atualizar essa credencial; configure uma rotação automatizada para evitar que o Kerberos pare de funcionar quando a senha expirar.

# Atualizar a credencial do storage account no AD
Update-AzStorageAccountADObjectPassword `
  -ResourceGroupName "rg-producao" `
  -StorageAccountName "minhaconta" `
  -RotateToKerbKey kerb1

10. Erros Comuns

Atribuir share-level permission mas esquecer de configurar as ACLs NTFS

O usuário recebe o papel RBAC de Contributor, monta o share sem problemas, mas ao tentar criar ou modificar arquivos recebe "Acesso negado". O motivo: ao habilitar identity-based access, o Azure configura as ACLs NTFS da raiz do share com permissões padrão que podem não incluir o usuário. O share monta (share-level OK) mas o acesso a arquivos falha (NTFS ACL não configurada). A solução é configurar explicitamente as ACLs NTFS após habilitar identity-based access.

Tentar habilitar AD DS on-premises pelo portal ou CLI sem o módulo AzFilesHybrid

O portal e a CLI permitem "habilitar" o AD DS on-premises, mas sem executar o domain join via AzFilesHybrid, a configuração está incompleta. O storage account precisa do objeto de computador criado no AD local para emitir tickets Kerberos válidos. Sem isso, a autenticação falha mesmo com o checkbox marcado no portal.

Esquecer de renovar a senha do objeto de computador no AD

No cenário AD DS on-premises, o storage account tem um objeto de computador no AD com uma senha. Essa senha expira seguindo a política de senha do domínio (geralmente 90 dias). Quando expira, o Kerberos para de funcionar: os usuários recebem erros de autenticação ao tentar montar o share. Configure uma tarefa agendada ou pipeline para renovar essa credencial periodicamente.

Tentar acessar Azure Files com identity-based auth de um cliente não ingressado no domínio

Se o dispositivo do usuário não está no domínio AD (nem Entra joined para o caso do Entra Kerberos), o cliente não tem como obter um ticket Kerberos para o storage account. O acesso via identity-based auth requer que o cliente esteja em um dos modelos de identidade suportados. Um notebook pessoal sem configuração de domínio não consegue usar autenticação de identidade; precisaria usar a access key diretamente.

Confundir NFS 4.1 com SMB para identity-based access

Um administrador configura identity-based access no storage account e espera que VMs Linux que acessam via NFS 4.1 também se beneficiem da autenticação por identidade. O NFS 4.1 no Azure Files não usa AD nem Entra ID; o controle de acesso é via restrição de rede (VNet/subnet). São dois protocolos com modelos de segurança completamente diferentes no Azure Files.

11. Operação e Manutenção

Verificar o Status da Configuração

# Status completo da configuração identity-based
$account = Get-AzStorageAccount `
  -ResourceGroupName "rg-producao" `
  -Name "minhaconta"

$account.AzureFilesIdentityBasedAuth | ConvertTo-Json -Depth 5

O resultado mostra qual método está ativo, as configurações do AD e o status do objeto de computador.

Diagnóstico de Problemas de Autenticação

O Azure Files registra erros de autenticação no Storage Account via Storage Analytics Logging ou Azure Monitor. Para diagnóstico via PowerShell:

# Verificar se o storage account está corretamente domain-joined
Debug-AzStorageAccountAuth `
  -StorageAccountName "minhaconta" `
  -ResourceGroupName "rg-producao" `
  -Verbose

O cmdlet Debug-AzStorageAccountAuth (parte do módulo AzFilesHybrid) executa uma série de verificações automatizadas e reporta problemas específicos de configuração.

Limites Importantes

Item	Detalhe
Protocolos suportados para identity auth	SMB 2.1 e 3.0/3.1
Versões Windows suportadas para Entra Kerberos	Windows 10 21H2+, Windows 11, Windows Server 2022+
Tamanho máximo de ACL NTFS	Sem limite documentado específico
Renovação de senha do objeto AD	Seguindo política do domínio (geralmente 90 dias)
Compartilhamentos Premium vs. Standard	Identity-based auth funciona em ambos

12. Integração e Automação

Azure File Sync com Identity-Based Access

O Azure File Sync sincroniza um servidor de arquivos Windows on-premises com um Azure File Share. Nesse cenário, o servidor on-premises é o endpoint principal onde os usuários acessam os arquivos. As ACLs NTFS configuradas no servidor on-premises são sincronizadas para o Azure Files e preservadas.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Nesse modelo, o AD on-premises é a fonte de identidade tanto para os usuários locais quanto para os que acessam diretamente o Azure Files.

Automação do Domain Join via Pipeline CI/CD

Para provisionamento automatizado de storage accounts com identity-based access já configurado:

# Pipeline de criação de storage account com domain join automático
param(
    [string]$resourceGroup,
    [string]$storageAccountName,
    [string]$ouDN
)

# 1. Criar o storage account
New-AzStorageAccount `
  -ResourceGroupName $resourceGroup `
  -Name $storageAccountName `
  -SkuName Standard_LRS `
  -Kind StorageV2 `
  -Location "brazilsouth"

# 2. Fazer domain join via AzFilesHybrid
Join-AzStorageAccountForAuth `
  -ResourceGroupName $resourceGroup `
  -StorageAccountName $storageAccountName `
  -DomainAccountType "ComputerAccount" `
  -OrganizationalUnitDistinguishedName $ouDN

# 3. Atribuir papel padrão ao grupo de usuários
$scope = "/subscriptions/$((Get-AzContext).Subscription.Id)/resourceGroups/$resourceGroup/providers/Microsoft.Storage/storageAccounts/$storageAccountName"

New-AzRoleAssignment `
  -ObjectId (Get-AzADGroup -DisplayName "SMB-FileShare-Users").Id `
  -RoleDefinitionName "Storage File Data SMB Share Contributor" `
  -Scope $scope

13. Resumo Final

Pontos essenciais:

O Azure Files suporta acesso baseado em identidade via AD DS on-premises, Microsoft Entra Domain Services e Microsoft Entra ID Kerberos. O protocolo usado é o Kerberos, o mesmo do AD Windows tradicional.
O controle de acesso tem dois níveis independentes: share-level permissions (Azure RBAC) e file-level permissions (ACLs NTFS). Ambos precisam permitir o acesso para que o usuário chegue ao arquivo.
Os papéis RBAC específicos para Azure Files são DataActions na família Storage File Data SMB Share *, não confundir com papéis genéricos como Contributor.
O domain join do storage account ao AD on-premises requer o módulo PowerShell AzFilesHybrid e não pode ser feito pelo portal.

Diferenças críticas:

Share-level (RBAC) vs. File-level (NTFS ACL): share-level controla o acesso ao share como um todo (montagem); NTFS ACL controla o acesso a arquivos e diretórios específicos. Os dois se combinam com lógica de AND.
AD DS on-premises vs. Entra ID Kerberos: o AD DS on-premises requer domain join via script e objeto de computador no AD; o Entra ID Kerberos só precisa de um az storage account update e dispositivos Entra joined.
SMB com identity auth vs. NFS 4.1: SMB suporta identity-based access; NFS 4.1 usa controle de acesso baseado em rede, sem AD ou Entra ID.
Storage File Data SMB Share Contributor vs. Storage File Data SMB Share Elevated Contributor: Contributor permite ler e escrever arquivos; Elevated Contributor adicionalmente pode modificar as ACLs NTFS.

O que precisa ser lembrado:

Ao habilitar identity-based access, o Azure atribui Full Control a todos os usuários autenticados nas ACLs NTFS da raiz por padrão. Configure as ACLs explicitamente para restrições granulares.
No cenário AD DS on-premises, o objeto de computador no AD tem uma senha que expira. Configure renovação automática para evitar interrupções na autenticação Kerberos.
Share-level permissions são atribuídas no escopo do storage account, não do file share individual.
Para configuração inicial de ACLs NTFS em um share novo, o caminho mais prático é montar com a access key (acesso total), configurar as ACLs, e depois usar somente autenticação baseada em identidade.
O papel Storage File Data Privileged Contributor ignora ACLs NTFS e é destinado a operações de backup e administração, não para usuários regulares.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 Fontes de Identidade para Autenticação​

3.2 O Protocolo Kerberos e Por Que Importa​

3.3 Share-Level Permissions: Azure RBAC​

3.4 NTFS Permissions: Controle Granular por Arquivo e Diretório​

3.5 A Lógica dos Dois Níveis​

4. Visão Estrutural​

5. Funcionamento na Prática​

Configuração para AD DS On-Premises (Cenário Híbrido)​

Configuração para Microsoft Entra ID Kerberos (Cenário Moderno)​

Comportamentos Importantes e Não Óbvios​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 PowerShell​

6.3 Azure CLI​

7. Controle e Segurança​

A Separação Entre Montagem e Acesso a Dados​

Permissão de "Superusuário" para Configuração Inicial​

Compatibilidade de Protocolos​

8. Tomada de Decisão​

Qual fonte de identidade escolher?​

Qual papel RBAC de share-level atribuir?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Verificar o Status da Configuração​

Diagnóstico de Problemas de Autenticação​

Limites Importantes​

12. Integração e Automação​

Azure File Sync com Identity-Based Access​

Automação do Domain Join via Pipeline CI/CD​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 Fontes de Identidade para Autenticação

3.2 O Protocolo Kerberos e Por Que Importa

3.3 Share-Level Permissions: Azure RBAC

3.4 NTFS Permissions: Controle Granular por Arquivo e Diretório

3.5 A Lógica dos Dois Níveis

4. Visão Estrutural

5. Funcionamento na Prática

Configuração para AD DS On-Premises (Cenário Híbrido)

Configuração para Microsoft Entra ID Kerberos (Cenário Moderno)

Comportamentos Importantes e Não Óbvios

6. Formas de Implementação

6.1 Portal do Azure

6.2 PowerShell

6.3 Azure CLI

7. Controle e Segurança

A Separação Entre Montagem e Acesso a Dados

Permissão de "Superusuário" para Configuração Inicial

Compatibilidade de Protocolos

8. Tomada de Decisão

Qual fonte de identidade escolher?

Qual papel RBAC de share-level atribuir?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Verificar o Status da Configuração

Diagnóstico de Problemas de Autenticação

Limites Importantes

12. Integração e Automação

Azure File Sync com Identity-Based Access

Automação do Domain Join via Pipeline CI/CD

13. Resumo Final