Il ne s'agit pas du fichier "hosts", mais de la rupture des partages auxquels on accède via un nom d'hôte différent du "vrai" nom du serveur. Votre résultat est normal, puisque c'est littéralement l'objectif de la GPO.
La GPO en question ressemble beaucoup à l'application de TLS SNI que l'on trouve dans certains serveurs web : le client déclare "Je suis ici pour parler au serveur SRV01.EXAMPLE.COM" et si le serveur ne reconnaît pas ce nom comme l'un des vhosts qu'il sert, il rejette complètement le client. Donc ici, si le client déclare qu'il veut parler à l'un de vos alias /etc/hosts, mais que le serveur ne connaît pas l'alias, il rejette le client.
Kerberos a déjà intégré une mise en application similaire (c'est pourquoi vous devez enregistrer des SPN pour les alias en utilisant la fonction setspn ), mais les GPO sont plus strictes. y étend la même protection à NTLM.
(Comme déjà mentionné dans la page Docs, ceci est censé empêcher les attaques par relais NTLM, où un serveur A malveillant accepte l'authentification NTLM puis transmet exactement les mêmes paquets NTLM à un vrai serveur B - l'attaque serait empêchée car le serveur B verrait "I want to talk to server A" du client).
Il est Il est toujours possible d'utiliser des alias d'hôtes, mais cela nécessite une quantité toujours plus grande de boutons de registre. La méthode officielle consiste à utiliser netdom computername REALHOST /add:THEALIAS dans le cas de ce billet de TechNet J'ai trouvé des articles de blog prétendant que cela suffit à rendre les alias utilisables même avec une validation stricte du SPN, mais il semble vraiment que ce soit le cas. no Il y a au moins une, voire deux valeurs de registre qu'il oublie de toucher.
-
Registres NETDOM Kerberos SPN pour l'alias dans AD, ce qui permet d'obtenir des tickets Kerberos pour eux, de la même manière qu'en émettant manuellement ces deux commandes :
setspn -S HOST/THEALIAS REALHOST$
setspn -S HOST/thealias.example.com REALHOST$
Ceci est nécessaire pour Kerberos et il n'y a aucune excuse pour ne pas utiliser Kerberos dans un environnement AD, donc que vous choisissiez d'utiliser NETDOM ou de le faire à la main, vous devez enregistrer les alias SPN de toute façon.
(Techniquement, SMB utilise des principals "cifs/", mais dans AD, ils sont implicitement présents dès que le SPN "host/" est enregistré).
-
NETDOM ajoute ensuite l'alias à deux endroits du registre du serveur, ce qui amène le serveur à enregistrer ses noms supplémentaires dans AD DNS et à les annoncer via NetBIOS Browser :
-
Chemin : HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Nom : AlternateComputerNames
Type : REG_MULTI_SZ
Données : { thealias.example.com }
-
Chemin : HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Nom : OptionalNames
Type : REG_MULTI_SZ
Données : { THEALIAS }
Ils ne semblent pas avoir d'effet sur l'authentification (pas même Kerberos), donc je crois que ces deux éléments sont complètement facultatifs si vous utilisez /etc/hosts ou si vous créez manuellement des enregistrements CNAME dans le DNS.
-
Un paramètre supplémentaire que NETDOM n'a pas mais que j'ai trouvé nécessaire pour accéder aux alias depuis le serveur lui-même :
- Chemin :
HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Nom : BackConnectionHostNames
Type : REG_MULTI_SZ
Données : { thealias.example.com }
Celle-ci n'est nécessaire que pour les connexions "loopback", donc peut-être pas strictement nécessaire en général, mais au moins dans mon cas le serveur a fait doit se connecter à son propre alias, ce paramètre était donc nécessaire.
-
Enfin, j'ai constaté que la fonction "validation du nom de la cible SPN" a son propre liste des noms autorisés qui doit être mise à jour manuellement - sinon les alias seraient rejetés en raison de la validation stricte du SPN, même si tous les paramètres ci-dessus sont présents :
- Chemin :
HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Nom : SrvAllowedServerNames
Type : REG_MULTI_SZ
Données : { THEALIAS , thealias.example.com }
Vous devez énumérer les deux noms courts y FQDNs de chaque alias - d'après mes expériences, l'énumération de l'un n'implique pas automatiquement l'autre.
Une fois que les SPN Kerberos sont enregistrés et que l'application SrvAllowedServerNames les alias devraient enfin fonctionner correctement, même avec une validation stricte de la cible.
