Como usar Namespaces do DFS-N com Arquivos do Azure

Aplica-se a: ✔️ compartilhamentos de arquivos SMB

Espaços de Nomes de Sistemas de Arquivos Distribuídos, comumente chamados de Namespaces DFS ou DFS-N, são uma função de servidor Windows Server que simplifica a implantação e manutenção de compartilhamentos de arquivos SMB em produção. Os espaços de nomes DFS fornecem virtualização do espaço de nomes de armazenamento, permitindo que você forneça uma camada de indireção entre o caminho UNC do seu compartilhamento de arquivos e o compartilhamento de arquivos real. Os Namespaces do DFS funcionam com compartilhamentos de arquivos do SMB, independentes de onde esses compartilhamentos de arquivos estão hospedados. Você pode usá-lo com compartilhamentos SMB hospedados em um Servidor de Arquivos do Windows local, com ou sem o Sincronização de Arquivos do Azure; diretamente com compartilhamentos de arquivos do Azure; com compartilhamentos SMB hospedados no Azure NetApp Files ou em outras soluções de terceiros; e até com compartilhamentos de arquivos hospedados em outras nuvens.

No seu núcleo, os Namespaces DFS fornecem um mapeamento entre um caminho UNC amigável, como \\contoso\shares\ProjectX, e o caminho UNC subjacente do compartilhamento SMB, como \\Server01-Prod\ProjectX ou \\storageaccount.file.core.windows.net\projectx. Quando o usuário final navega até seu compartilhamento de arquivos, ele digita o caminho UNC amigável, mas seu cliente SMB acessa o caminho SMB subjacente do mapeamento. Você também pode estender esse conceito para assumir um nome de servidor de arquivos existente, como \\MyServer\ProjectX. Você pode usar essa capacidade para ter os seguintes cenários:

• Forneça um nome de prova de migração para um conjunto lógico de dados. Por exemplo, você pode mapear \\contoso\shares\Engineering para \\OldServer\Engineering. Quando você concluir sua migração para o Arquivos do Azure, pode alterar o mapeamento para \\storageaccount.file.core.windows.net\engineering, de modo que, quando um usuário final acessar o caminho UNC amigável, ele seja redirecionado de forma fluida para o caminho de compartilhamento de arquivos do Azure.

• Estabeleça um nome comum para um conjunto lógico de dados distribuídos para múltiplos servidores em diferentes locais físicos, como via Sincronização de Arquivos do Azure. Neste exemplo, um nome como \\contoso\shares\FileSyncExample é mapeado para múltiplos caminhos UNC, como \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, e \\FileSyncServer3\ExampleShare. Quando o usuário acessa o UNC de fácil utilização, ele recebe uma lista de possíveis caminhos UNC e escolhe o caminho mais próximo com base nas definições de sites do Active Directory (AD) do Windows Server.

• Estenda um conjunto lógico de dados entre tamanho, E/S ou outros limites de escala. Essa extensão é útil para diretórios de usuários, onde cada usuário tem sua própria pasta em um compartilhamento, e para compartilhamentos de scratch, onde os usuários têm espaço arbitrário para dados temporários. Com os namespaces de DFS, você une várias pastas em um namespace coeso. Por exemplo, \\contoso\shares\UserShares\user1 mapeia para \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 mapeia para \\storageaccount.file.core.windows.net\user2 e assim por diante.

Você pode ver um exemplo de como usar namespaces de DFS com sua implantação de Arquivos do Azure no seguinte vídeo de visão geral.

Observação

Vá para o minuto 10:10 no vídeo para ver como configurar namespaces de DFS.

Se você já tem um namespace DFS instalado, não são necessários passos especiais para usá-lo com o Arquivos do Azure e o File Sync. Se você acessar seu compartilhamento de arquivos do Azure a partir do local, as considerações normais de rede se aplicam. Confira Considerações de rede dos Arquivos do Azure para mais informações.

Este artigo aborda as partes de uma implantação de Namespaces DFS que são específicas para Arquivos do Azure. Para os conceitos subjacentes do Windows Server e o conjunto completo de procedimentos de namespace, veja a visão geral dos Namespaces DFS e Deploying DFS Namespaces.

Pré-requisitos

Para usar espaços de nomes DFS com Arquivos do Azure e File Sync, você precisa dos seguintes recursos:

• Um domínio do Active Directory. Você pode hospedar esse domínio em qualquer lugar, como on-premises, em uma máquina virtual (VM) do Azure ou em outra nuvem.

• Um servidor membro do Windows Server conectado ao domínio com o papel de servidor DFS Namespaces instalado. Os namespaces de DFS estão disponíveis em todas as versões do Windows Server com suporte.

  Importante

  Não hospede um namespace consolidado root em um controlador de domínio do Active Directory. Assumir o nome de um servidor de arquivos existente requer um servidor membro dedicado ou um cluster de failover do Windows Server.

• Um compartilhamento de arquivos SMB hospedado em um ambiente unido ao domínio, como um compartilhamento de arquivos Azure em uma conta de armazenamento unido ao domínio, ou um compartilhamento de arquivos em um servidor de arquivos Windows conectado ao domínio com Sincronização de Arquivos do Azure. Para mais informações, veja Autenticação baseada em identidade.

• Conectividade de rede entre seus clientes e os compartilhamentos de arquivos SMB. Para obter mais informações, confira Considerações de rede para acesso direto.

• Direitos de Administrador de Domínio, ou acesso delegado de escrita ao servicePrincipalName atributo das contas de computador afetadas. O procedimento de tomada de nome modifica objetos do Active Directory e requer uma sessão elevada.

Instalar a função de servidor Namespaces do DFS

Se você já usa espaços de nomes DFS, pule essa etapa.

Gerenciador de Servidores

Abra o Gerenciador do Servidor e selecione Gerenciar>Adicionar Papéis e Recursos. Escolha instalação baseada em funções ou baseada em recursos. Na página Funções do Servidor, selecione Namespaces DFS em Serviços de Arquivo e Armazenamento>Serviços de Arquivo e iSCSI. O assistente adiciona todas as funções ou recursos necessários.

PowerShell

Em uma sessão do PowerShell com privilégios elevados, execute:

Install-WindowsFeature -Name "FS-DFS-Namespace", "RSAT-DFS-Mgmt-Con"

Para mais opções de instalação, veja Instalar Namespaces DFS.

Escolha um tipo de namespace

Os espaços de nomes DFS fornecem dois tipos de namespace: baseados em domínio e independentes. Para uma comparação completa, incluindo limites de escala, opções de disponibilidade e requisitos do Active Directory, veja Escolher um tipo de namespace.

Para o Arquivos do Azure, a escolha geralmente se resume a uma única pergunta:

• Se você precisar preservar um nome existente de servidor de arquivos local, como \\MyServer\share, escolha um espaço para nome autônomo e use a consolidação de raízes. Essa abordagem é recomendada quando você migra compartilhamentos de arquivos para o Arquivos do Azure, pois mantém atalhos de documentos, links incorporados e caminhos UNC codificados em funcionamento após a migração. O restante deste artigo foca nesse cenário.
• Para qualquer outro cenário, escolha um namespace baseado em domínio.

Namespaces independentes têm vantagens e desvantagens que devem ser consideradas no planejamento:

• Os metadados do namespace são armazenados no registro do servidor do namespace, não no Active Directory. Inclua a configuração do namespace na sua estratégia de backup de servidor.
• Você não pode adicionar múltiplos servidores de namespace a um namespace independente para redundância. Para alta disponibilidade, hospede o namespace em um cluster de failover do Windows Server.
• Namespaces independentes suportam alvos de escala menor do que namespaces baseados em domínio no modo Windows Server 2008.

O caminho que seus usuários montam depende do tipo de namespace:

Configuração de namespace	Caminho a usar
Espaço de nomes autônomo com consolidação da raiz	\\<old-server>\<share>
Namespace independente	\\<DFS-server>\<namespace>\<share>
Namespace baseado em domínio	\\<domain-name>\<namespace>\<share>

Se você escolheu um namespace baseado em domínio, pule as etapas de consolidação de raízes. O namespace e o procedimento de destino da pasta é o mesmo para ambos os tipos. Use Criar o namespace e adicionar os compartilhamentos de arquivos do Azure com DomainV2 como tipo de namespace.

Assumir nomes de servidor existentes com a consolidação raiz

Ao usar a consolidação de raízes, um único servidor do DFS Namespaces pode responder a vários nomes de servidor de arquivos e encaminhar solicitações para o compartilhamento apropriado. Essa funcionalidade é especialmente útil para adotar o Arquivos do Azure, porque:

• Compartilhamentos de arquivos do Azure não podem reutilizar nomes de servidores existentes no local.
• Você acessa os compartilhamentos de arquivos do Azure usando o nome de domínio totalmente qualificado (FQDN) da conta de armazenamento. Por exemplo, para acessar o compartilhamento share na conta de armazenamento storageaccount, use \\storageaccount.file.core.windows.net\share. Esse caminho pode ser confuso para usuários finais que esperam um nome curto, como \\MyServer\share. Arquivos do Azure suporta nomes de domínio personalizados quando o nome da conta de armazenamento é o prefixo do domínio, mas sem espaços de nomes DFS, você não pode usar um nome como \\MyServer.contoso.com\share.

Você pode usar a consolidação de raiz apenas com namespaces independentes. Se você já tem um namespace baseado em domínio para seus compartilhamentos de arquivos, não precisa de um namespace consolidado com root.

Para tornar um namespace consolidado de raiz altamente disponível, hospede-o em um cluster de failover. Para construir o cluster subjacente, veja Criar um cluster de failover. Se você adotar essa abordagem, registre o alias no objeto de nome do cluster (CNO), não em um nó individual.

O diagrama a seguir mostra uma implementação de consolidação raiz com alta disponibilidade. Um Azure Load Balancer fica à frente de um cluster de failover do Windows Server formado por servidores DFS Namespaces que hospedam os namespaces consolidados raiz, de modo que os clientes continuem acessando os nomes dos servidores de arquivos desativados após seus compartilhamentos serem movidos para o Arquivos do Azure.

Assumir um nome de servidor existente é uma transição, não uma alteração incremental. Complete as seguintes etapas em ordem:

1. Ative a consolidação de raízes no servidor DFS Namespaces.
2. Crie o namespace e adicione seus compartilhamentos de arquivos no Azure, usando um namespace chamado #<old-server-name>.
3. Transfira o nome do servidor e os nomes do principal do serviço do servidor de arquivos de origem.
4. Crie entradas DNS para nomes de servidores de arquivos existentes.
5. Verifique a apropriação de nome.

Importante

As fases 3 e 4 colocam o servidor de arquivos de origem fora do ar, portanto o intervalo entre desligá-lo e concluir a alteração de DNS representa um período de indisponibilidade para seus usuários. Programe um período de manutenção.

Antes de começar, faça um levantamento de tudo o mais que é resolvido para o nome do servidor de origem. Filas de impressão, membros de replicação DFS, aliases de banco de dados, tarefas agendadas, trabalhos de backup e scripts codificados que referenciam o nome antigo param de funcionar quando o nome é redirecionado para um servidor de espaços de nomes DFS, porque um servidor de espaço de nomes só retorna referências SMB. Migre ou descontinue essas dependências primeiro.

Permitir a consolidação das raízes

A partir de uma sessão PowerShell elevada no servidor namespace, defina os seguintes valores do registro e então reinicie o serviço DFS Namespace. O serviço lê esses valores apenas na inicialização; até reiniciar, você não pode criar um namespace cujo nome comece com #.

New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Type Registry `
    -ErrorAction SilentlyContinue
Set-ItemProperty `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Name "ServerConsolidationRetry" `
    -Type DWord `
    -Value 1

Restart-Service -Name "Dfs"

Em um cluster de failover, defina os valores do Registro em cada nó e, em seguida, execute o failover da função de namespace em cluster para que cada nó reinicie o serviço.

Crie o namespace e adicione seus compartilhamentos de arquivos do Azure

A unidade básica de gerenciamento para espaços de nomes DFS é o namespace, cuja raiz é o ponto de partida da árvore. Em \\contoso.com\Public\, a raiz do namespace é Public. Dentro de um namespace, pastas com alvos de pasta apontam para os compartilhamentos de arquivos SMB que armazenam seu conteúdo, e pastas sem alvos de pasta adicionam estrutura e hierarquia.

Para os procedimentos gerais do Windows Server, veja Criar um namespace DFS, Criar uma pasta em um namespace DFS e Adicionar alvos de pasta. Quando você direcionar compartilhamentos de arquivos no Azure, tenha em mente os seguintes pontos:

• Use a conta de armazenamento FQDN como destino da pasta. Aponte os destinos da pasta para \\<storage-account>.file.core.windows.net\<share>. O Arquivos do Azure também oferece suporte a nomes de domínio personalizados quando o nome da conta de armazenamento é o prefixo do domínio, mas usar um deles para um destino de pasta adiciona uma segunda dependência de DNS e de Kerberos por trás de cada referência. Use o FQDN, a menos que você já dependa de nomes de domínio personalizados.
• Espere um alerta de conectividade no DFS Management. Quando você adiciona um destino de pasta para um compartilhamento de arquivos do Azure, o console pode informar que storageaccount.file.core.windows.net não pode ser contatado. Esse aviso é esperado. Clique em Sim para continuar.
• Namespaces de consolidação de raízes precisam de um # prefixo. O nome do namespace deve corresponder ao servidor que você está substituindo, precedido por #. Para assumir um servidor chamado MyServer, crie um namespace chamado #MyServer. O exemplo do PowerShell adiciona o prefixo para você. O console de gerenciamento do DFS não faz isso, então digite manualmente.
• Os nomes das pastas devem corresponder aos nomes antigos dos compartilhamentos. Um cliente que abre \\MyServer\Finance é servido pela pasta Finance no #MyServer namespace, então os nomes das pastas devem corresponder exatamente aos nomes de compartilhamento do servidor de origem.

Gestão do DFS

No console Gerenciamento DFS, selecione Namespaces>Novo Namespace e siga o Assistente para Novo Namespace. Depois, selecione o novo namespace, selecione Nova Pasta, insira o nome de uma pasta e selecione Adicionar para fornecer o caminho UNC do seu compartilhamento de arquivos do Azure como destino de pasta.

PowerShell

Execute os seguintes comandos a partir de uma sessão PowerShell elevada no servidor DFS Namespace. Atualize as variáveis no primeiro bloco para o seu ambiente.

# Variables
$namespace = "MyServer"                   # Namespace root name. For root consolidation, use the
                                          # name of the file server you're replacing.
$type = "Standalone"                      # "Standalone" for a stand-alone namespace, or "DomainV2"
                                          # for a domain-based namespace (Windows Server 2008 mode).
$takeOverName = $true                     # Set to $false if you aren't using root consolidation.
$shareName = "Finance"                    # Folder name within the namespace. For root consolidation,
                                          # match the share name on the source file server exactly.
$targetUNC = "\\storageaccount.file.core.windows.net\finance"

# Root consolidation namespaces must be prefixed with "#".
if ($takeOverName -and $type -eq "Standalone" -and $namespace -notlike "#*") {
    $namespace = "#$namespace"
}

$dfsnServer = $env:ComputerName
$namespaceServer = if ($type -like "Domain*") {
    Get-CimInstance -ClassName "Win32_ComputerSystem" | `
        Select-Object -ExpandProperty Domain
} else { $dfsnServer }

# Create the SMB share that backs the namespace root. Read-only access matches the DFS Management
# default, because this share serves referrals rather than data.
$smbSharePath = "C:\DFSRoots\$namespace"
if (!(Test-Path -Path $smbSharePath)) {
    New-Item -Path $smbSharePath -ItemType Directory | Out-Null
}
New-SmbShare -Name $namespace -Path $smbSharePath -ReadAccess "Everyone"

# Create the namespace root.
Import-Module -Name DFSN
$namespacePath = "\\$namespaceServer\$namespace"
New-DfsnRoot -Path $namespacePath -TargetPath "\\$dfsnServer\$namespace" -Type $type

# Create the folder and point it at the Azure file share.
New-DfsnFolder -Path "$namespacePath\$shareName" -TargetPath $targetUNC

# Verify the namespace root and folder target.
Get-DfsnRoot -Path $namespacePath
Get-DfsnFolderTarget -Path "$namespacePath\$shareName"

Confirme que o namespace seja resolvido por meio do próprio nome do servidor de namespace antes de continuar. O nome antigo do servidor ainda não funciona; começa a funcionar depois das próximas duas etapas.

Test-Path -Path "\\CloudDFSN\#MyServer\Finance"

Se o caminho não se resolver, verifique se o cliente pode acessar o compartilhamento de arquivos do Azure diretamente em \\<storage-account>.file.core.windows.net\<share>. O DFS Namespaces retorna apenas um encaminhamento, portanto qualquer problema de rede ou autenticação com o compartilhamento subjacente se manifesta aqui. Para obter mais informações, confira Considerações de rede para acesso direto.

Transferir o nome do servidor e os nomes principais de serviço

A consolidação de raízes permite que o servidor DFS Namespaces responda ao nome do servidor de arquivos antigo, mas duas outras coisas precisam ser verdadeiras antes que um cliente possa autenticar com esse nome:

• O servidor SMB no servidor de namespace deve aceitar uma conexão estabelecida usando um nome diferente do seu próprio nome de computador.
• O Kerberos deve resolver cifs/MyServer para a conta que atende a solicitação. Se esse nome principal de serviço (SPN) ainda estiver registrado na conta do computador do servidor de arquivos desativado, os clientes recebem um chamado pela conta errada. A conexão então falha com "O nome da conta alvo está incorreto" ou cai silenciosamente de volta para NTLM.

O netdom computername comando atende a ambos os requisitos. Ele registra o nome antigo como um nome alternativo do computador no servidor de namespace, o que adiciona o nome ao atributo msDS-AdditionalDnsHostName do servidor e registra os SPNs HOST/<alias> correspondentes. Um HOST SPN abrange implicitamente um conjunto de classes de serviço que inclui cifs, portanto uma solicitação de cliente para cifs/MyServer é resolvida para a conta do servidor de namespace. Para a lista completa de classes de serviço, veja setspn.

Não substitua um cadastro criado manualmente setspn por netdom. Registrar cifs/MyServer na conta do servidor de namespace configura o Kerberos, mas não o servidor SMB, e o serviço de diretório rejeita SPNs que não sejam derivados dos nomes da conta alvo. Para mais informações, consulte O acesso ao compartilhamento de servidor de arquivos SMB não funciona por meio do alias DNS CNAME.

Aviso

Não delete a conta do computador de origem. Desativá-la mantém a conta, seu identificador de segurança (SID) e suas associações a grupos intactos, de modo que você pode reverter a transição reativando a conta e restaurando seus SPNs. Deletar a conta torna o rollback muito mais difícil.

Importante

Execute as mudanças de diretório nesse procedimento contra o mesmo controlador de domínio, e de preferência contra o emulador PDC. O Active Directory usa replicação multi-master com consistência flexível, portanto não há garantia de que as réplicas sejam consistentes entre si em um determinado momento. Se você remover o registro antigo em um controlador de domínio e depois adicioná-lo em outro controlador de domínio, a verificação de duplicidade ainda poderá detectar o registro removido e se recusar a gravar. Para encontrar o emulador PDC, execute (Get-ADDomain).PDCEmulator, e então execute os comandos de uma sessão nesse servidor.

1. Desligue o servidor de arquivos de origem. O servidor de origem e o servidor de Namespaces DFS não podem responder ao mesmo nome. Desligue o servidor em vez de removê-lo do domínio.

2. Desative a conta do computador de origem. No Usuários e Computadores do Active Directory, clique com o botão direito no objeto computador e selecione Desabilitar Conta. Para fazer o mesmo no PowerShell em uma máquina com o módulo Active Directory instalado, execute:

   $oldServer = "MyServer"
   Disable-ADAccount -Identity ($oldServer + '$')
   

3. Remova os SPNs da conta de computador de origem. Desativar uma conta não remove seus SPNs. Registros deixados na conta antiga bloqueiam o próximo passo, porque o mesmo nome não pode ser registrado em duas contas. SPNs duplicados são uma causa documentada de KDC_ERR_PRINCIPAL_NOT_UNIQUE. Para mais informações, veja Kerberos gera erro KDC_ERR_S_PRINCIPAL_UNKNOWN ou KDC_ERR_PRINCIPAL_NOT_UNIQUE. Liste o que está cadastrado e depois exclua as entradas HOST e cifs:

   setspn -L MyServer
   setspn -D HOST/MyServer MyServer
   setspn -D HOST/MyServer.contoso.com MyServer
   

   Exclua qualquer entrada explícita cifs/ da mesma forma. Se setspn -L mostrar outras classes de serviço como TERMSRV ou MSSQLSvc, o nome antigo ainda serve a algo que não seja SMB. Resolva essa dependência antes de continuar.

4. Adicione o nome antigo como nome alternativo de computador no servidor de namespace. Execute netdom em um prompt de comando com privilégios elevados no servidor de namespace. Para um único servidor DFS Namespaces, mire a conta do computador desse servidor. Para um namespace clusterizado independente, o objetivo seja o objeto de nome do cluster (CNO), não as contas individuais dos nós. netdom vem com as ferramentas do AD DS nas Ferramentas de Administração de Servidor Remoto; instale RSAT-AD-Tools se o comando não estiver disponível.

   netdom computername CloudDFSN.contoso.com /add:MyServer.contoso.com
   

   Especifique ambos os nomes como domínios totalmente qualificados. netdom registra os SPNs HOST/MyServer e HOST/MyServer.contoso.com na conta de destino e adiciona o nome ao atributo msDS-AdditionalDnsHostName da conta, o que permite que o servidor SMB aceite conexões feitas usando o nome antigo.

   Verifique o resultado. O /verify switch verifica se existem registros DNS e SPN para cada nome registrado:

   netdom computername CloudDFSN.contoso.com /enumerate:AlternateNames
   netdom computername CloudDFSN.contoso.com /verify
   

   Se netdom houver relatos de que o nome já está em uso, ele ainda está registrado em outro lugar da floresta. Localize o objeto conflitante antes de continuar:

   setspn -T contoso -F -Q */MyServer
   

   Se o único objeto retornado for a conta do computador de origem que você editou na etapa anterior, a remoção ainda não foi replicada para o controlador de domínio que você está consultando. Espere a replicação convergir, ou execute novamente os comandos no emulador PDC.

Criar entradas DNS para nomes de servidores de arquivos existentes

Para que os Namespaces DFS respondam aos nomes de servidores de arquivos existentes, crie registros de alias (CNAME) que apontem os nomes antigos dos servidores de arquivos para o servidor de Namespaces DFS. O procedimento exato depende do servidor DNS que sua organização utiliza. Os passos a seguir utilizam o servidor DNS incluído no Windows Server.

Gerenciador de DNS

Em um servidor DNS Windows, abra o console de gerenciamento de DNS e vá para a zona de busca direta do seu domínio. Clique com o botão direito na zona e selecione Novo Alias (CNAME). Na caixa de diálogo, insira o nome abreviado do servidor de arquivos que você está substituindo. Depois, insira o nome do servidor DFS-N na caixa de texto Nome de domínio totalmente qualificado (FQDN) do host de destino. Selecione OK para criar o registro CNAME.

PowerShell

Em um servidor DNS Windows, execute os seguintes comandos a partir de uma sessão PowerShell elevada. Preencha $oldServer com o nome do servidor de arquivos que você está substituindo e $dfsnServer com o nome abreviado do seu servidor DFS Namespaces. Para um namespace clusterizado, use o nome de rede do cluster em vez do nome do nó. A $domain variável é preenchida a partir do domínio do computador local.

# Variables
$oldServer = "MyServer"
$dfsnServer = "CloudDFSN"
$domain = Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain

# Create CNAME record
Import-Module -Name DnsServer
Add-DnsServerResourceRecordCName `
    -Name $oldServer `
    -HostNameAlias "$dfsnServer.$domain" `
    -ZoneName $domain

Verifique a apropriação do nome

Teste a partir de um cliente conectado ao domínio, logado como usuário com permissões no compartilhamento de arquivos do Azure alvo. Não teste no próprio servidor DFS Namespaces, porque uma conexão de loopback não usa o mesmo caminho de autenticação que um cliente remoto usa.

1. Confirme que o registro de nome alternativo foi replicado para todos os controladores de domínio. O centro de distribuição de chaves do cliente não é necessariamente o controlador de domínio que você mudou, e as réplicas do Active Directory não garantem ser consistentes em nenhum momento:

   $oldServer = "MyServer"
   $dfsnServer = "CloudDFSN"
   Get-ADDomainController -Filter * | ForEach-Object {
       $spns = (Get-ADComputer -Identity $dfsnServer -Properties servicePrincipalName `
           -Server $_.HostName).servicePrincipalName
       [pscustomobject]@{
           DomainController = $_.HostName
           HasHostSpn       = [bool]($spns -contains "HOST/$oldServer")
       }
   }
   

   Se algum controlador de domínio reportar False, a replicação não está completa. Espere e verifique novamente antes de continuar, porque um cliente que autentica por esse controlador de domínio ainda falha.

2. Confirme que o nome antigo do servidor agora seja resolvido para o servidor DFS Namespaces:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Abra o compartilhamento pelo nome antigo e confirme que você vê o conteúdo do compartilhamento de arquivos do Azure:

   Test-Path -Path "\\MyServer\Finance"
   Get-ChildItem -Path "\\MyServer\Finance"
   

4. Confirme que a sessão foi autenticada com Kerberos em vez de voltar ao NTLM verificando se um ticket foi emitido para o nome antigo:

   klist
   

   Procure um ticket cujo campo de servidor seja cifs/MyServer. O Kerberos emite esse ticket para a conta do servidor de namespace porque o registro HOST/MyServer cobre a classe de serviço cifs. Se esse ticket não existir, as causas mais comuns são que o registro do nome alternativo não foi replicado para o controlador de domínio que o cliente está usando, que um registro permaneceu associado à conta desativada ou que haja uma duplicata em outro ponto da floresta.

Se as mudanças no DNS ou no Kerberos não entrarem em vigor imediatamente, limpe os caches do lado do cliente e tente novamente:

ipconfig /flushdns
klist purge

Limpar os caches do cliente não ajuda se a mudança subjacente ainda não foi replicada. Se uma tentativa ainda falhar, verifique novamente a convergência de replicação na etapa 1 antes de mudar qualquer outra coisa.

Enumeração baseada em acesso (ABE)

A enumeração baseada em acesso esconde arquivos e pastas que o usuário não tem permissão para acessar. Nos espaços de nomes DFS, habilitar o ABE em um namespace se aplica apenas às pastas DFS-N nesse espaço de nomes. Para controlar a enumeração do conteúdo de uma pasta-alvo, ative o ABE no próprio compartilhamento de arquivos de destino. O ABE exige que todos os servidores de namespace rodem o Windows Server 2008 ou posterior, e os namespaces baseados em domínio devem usar o modo Windows Server 2008. Para detalhes, veja Habilitar a enumeração baseada em acesso em um namespace.

Como você não pode ativar o ABE em um compartilhamento de arquivos do Azure, usar o ABE para controlar a visibilidade de arquivos e pastas dentro de um compartilhamento de arquivos SMB no Azure não é um cenário suportado. Essa limitação existe porque DFS-N funciona por indicação em vez de como um proxy diante do alvo da pasta. Quando um usuário digita \\mydfsnserver\share, o cliente SMB recebe a referência \\mydfsnserver\share => \\server123\share e monta este último diretamente, de modo que o servidor DFS-N deixa de estar no caminho dos dados.

O ABE só funciona onde o servidor DFS-N hospeda o nível da hierarquia que você quer filtrar, antes do redirecionamento. Ambos os layouts a seguir funcionam, porque os nomes das pastas por usuário ficam no namespace do servidor DFS-N:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, onde contosouser1 é uma subpasta do compartilhamento users.

Se cada usuário estiver em uma subpasta após o redirecionamento, o ABE não funciona, porque as subpastas individuais de usuário nunca são listadas pelo servidor DFS-N:

• \\DFSServer\SomePath\users => \\SA.file.core.windows.net\users

Consulte também

• Configuração do acesso ao compartilhamento de arquivos: Autenticação baseada em identidade e Considerações de rede para acesso direto.
• Visão geral dos Namespaces do DFS
• Implantando namespaces do DFS
• Escolha um tipo de namespace
• netdom computername
• setspn
• O acesso ao compartilhamento de servidores de arquivos SMB não tem sucesso via DNS CNAME alias
• Criar um cluster de failover