Por que uma opção MS GPO quebra compartilhamentos SMB que usam um arquivo de hosts para o nome da máquina?

Não se trata do arquivo 'hosts' - ele quebra os compartilhamentos acessados ​​por meio de um nome de host diferente do nome "real" do servidor. Seu resultado é normal, pois esse é literalmente todo o propósito do GPO.

O GPO em questão é muito parecido com a aplicação TLS SNI encontrada em alguns servidores web: o cliente informa "Estou aqui para falar com o servidor SRV01.EXAMPLE.COM" e se o servidor não reconhecer esse nome como um dos vhosts serve, rejeita completamente o cliente. Então aqui se o cliente declara que quer falar com um de seus aliases /etc/hosts, mas o servidor não está ciente do alias, ele rejeita o cliente.

O Kerberos já tem uma aplicação interna semelhante (é por isso que você precisa registrar SPNs para aliases usando setspn), mas o GPO o torna mais rigoroso e também estende a mesma proteção ao NTLM.

(Como já mencionado na página Docs, isso deve impedir ataques de retransmissão NTLM, onde um servidor malicioso A aceita autenticação NTLM e encaminha exatamente os mesmos pacotes NTLM para um servidor real B - o ataque seria evitado porque o servidor B veria " Eu quero falar com o servidor A" do cliente.)

Ainda é possível usar aliases de host, mas requer uma quantidade cada vez maior de botões de registro. O método oficial é usar netdom computername REALHOST /add:THEALIAScomo nesta postagem do TechNet , e encontrei postagens de blog alegando que é suficiente tornar os aliases utilizáveis ​​mesmo com validação estrita de SPN, mas realmente parece que não é suficiente - há pelo menos um se não dois valores de registro que ele esquece de tocar.

1. O NETDOM registra SPNs do Kerberos para o alias no AD, permitindo que os tíquetes do Kerberos sejam obtidos para eles, semelhante à emissão manual desses dois comandos:

   setspn -S HOST/THEALIAS REALHOST$
   setspn -S HOST/thealias.example.com REALHOST$
   

   Isso é necessário para o Kerberos e não há desculpa para não usar o Kerberos em um ambiente AD, portanto, se você optar por usar NETDOM ou fazê-lo manualmente, registre os SPNs de alias de qualquer maneira.

   (Tecnicamente, o SMB usa os principais "cifs/", mas no AD eles estão implicitamente presentes sempre que o SPN "host/" é registrado.)

2. Em seguida, o NETDOM adiciona o alias em dois lugares no registro do servidor, fazendo com que o servidor registre seus nomes adicionais no AD DNS, bem como os anuncie via NetBIOS Browser:

   • Caminho: HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
     Nome: AlternateComputerNames
     Tipo: REG_MULTI_SZ
     Dados: { thealias.example.com}

   • Caminho: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
     Nome: OptionalNames
     Tipo: REG_MULTI_SZ
     Dados: { THEALIAS}

   Eles não parecem ter nenhum efeito na autenticação (nem mesmo Kerberos), então acredito que ambos são completamente opcionais se você usar /etc/hosts ou criar registros CNAME manuais no DNS.

3. Um parâmetro adicional que o NETDOM não cria, mas que considero necessário para acessar os aliases de dentro do próprio servidor, é:

   • Caminho: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
     Nome: BackConnectionHostNames
     Tipo: REG_MULTI_SZ
     Dados: { thealias.example.com}

   Este é necessário apenas para conexões de "loopback", então talvez não seja estritamente necessário em geral, mas pelo menos no meu caso o servidor precisava se conectar ao seu próprio alias para que a configuração fosse necessária.

4. Por fim, descobri que o recurso "validação de nome de destino SPN" tem sua própria lista de nomes permitidos que devem ser atualizados manualmente - caso contrário, os aliases seriam rejeitados devido à validação estrita do SPN, mesmo com todas as configurações acima presentes:

   • Caminho: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
     Nome: Tipo: REG_MULTI_SZ Dados: { , }SrvAllowedServerNames

THEALIASthealias.example.com

   Você vai querer listar os nomes curtos e os FQDNs de cada alias – de meus experimentos, listar um não implica automaticamente o outro.

Com os SPNs do Kerberos registrados e o SrvAllowedServerNamesvalor do registro definido, os aliases devem finalmente funcionar corretamente, mesmo com validação de destino estrita.