Compartilhamento de arquivos do Windows por meio do FQDN

Question

Atualmente, minha empresa está em processo de substituir qualquer alias ou referência de IP por FQDNs em nosso código. Qualquer coisa que tenha um IP ou nome de computador será substituído por algo como fileserver.example.com, databaseserver.example.com, etc.

Este processo está trabalhando para conexões de banco de dados, referências de serviços da Web, referências de API. Onde estamos tendo problemas é com acesso a compartilhamento de arquivos através de caminhos UNC. Acessar arquivos através de um caminho UNC como este \fileserver.example.com\path\to\files não funciona EM ALGUNS CASOS .

O EM ALGUNS CASOS é a parte importante aqui.

O caminho UNC pode ser acessado com sucesso nos seguintes casos

1. Ao visualizar manualmente pelo Windows Explorer com o caminho do FQDN.
2. Ao executar um processo que acessa os arquivos que NÃO usam o FQDN, usa o nome do computador ( \COMPUTER_NAME\path\to\files ).

O caminho UNC NÃO PODE ser acessado no seguinte caso

1. Ao executar um processo que acessa os arquivos que usam o FQDN ( \fileserver.example.com\path\to\files ).

Recebo a seguinte mensagem de erro.

Logon failure: unknown user name or bad password.

Esta mensagem de erro leva você a acreditar que é um problema de acesso, mas não creio que seja esse o caso, pois o usuário do serviço que está executando o processo pode acessar o arquivo usando o COMPUTER_NAME no caminho e aponta para o mesmo local o FQDN.

Alguém tem experiência com esse problema?

Os FQDNs devem ser usados para acessar compartilhamentos de arquivos por meio de caminhos UNC?

    

Answer 1

Depois de ler Claytons postar e examinar os logs de segurança no visualizador de eventos, percebemos que isso era apenas um problema quando uma máquina tentava acessar um arquivo com um caminho UNC apontado para si mesmo . p>

Isso me levou à verificação de loopback documentada no seguinte artigo no microsoft.com. link

Usamos Método 1: especificar nomes de host (método preferencial se a autenticação NTLM for desejada)

1. Disabled DisableStrictNameChecking no registro

2. Inseriu fileserver.example.com no BackConnectionHostNames no registro

Answer 2

Quando você usa um nome abreviado, ele volta a usar a autenticação NTLM. Mas com um FQDN, ele precisa usar a autenticação Kerberos. O problema é que o Kerberos funcione, você precisa de um nome DNS e de um SPN (Nome Principal de Serviço) que está faltando. Você tem duas opções:

Opção 1: Mantenha o alias e desative o recurso "Strict Name Checking" do Windows criando a seguinte chave reg no servidor. Também precisa reiniciar.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD name: DisableStrictNameChecking
DWORD value: 1

Opção 2: Remova o alias e crie um nome "alternativo" pelo Windows que também criará um nome principal do serviço Kerberos para que o nome alternativo seja válido para a autenticação Kerberos.

NETDOM NEWNAME /ADD

Substitua NEWNAME pelo FQDN do alias que você criou anteriormente. Isso deve ser executado a partir do servidor real que será atendido pelo alias.

link

    

Answer 3

Começou a pesquisar o assunto como parecia interessante. Eu comecei a navegar usando o FDQN do domínio em diferentes ambientes (eu trabalho para um MSP, então tenho acesso a alguns poucos domínios).

A versão curta é que eu estava experimentando algo que eu nunca tinha visto / notado antes. A navegação pelo Windows Explorer usando o FDQN do domínio exibiria a pasta raiz do compartilhamento de arquivos, mas nada mais. A navegação usando o nome IP / computer exibiria o (s) mesmo (s) compartilhamento (s) e exibiria as pastas / arquivos dentro dos compartilhamentos como deveria.

Um pouco mais de googling descobriu isso

O que deveria acontecer quando navego para o meu nome de domínio do Windows via UNC? .

Responde parcialmente à sua pergunta e a um motivo, mas não é uma correspondência exata do seu problema.

Pessoal, acho que implementar os compartilhamentos de arquivos via DFS permitiria que você usasse um namespace (conceito semelhante ao FDQN) e, quando se trata de remover a implementação de novos servidores de arquivos, não seria necessário refatorar código para apontar para um novo servidor de arquivos com nome de servidor.

Ele também deve ignorar o problema que você está enfrentando.

Espero que isso ajude.

Visão geral do DFS link