Serveur d'impression

Windows Server 2016: accès refusé pour les partages administrateur – Bien choisir son serveur d impression

Le 3 mai 2019 - 7 minutes de lecture

Nous avons récemment rencontré un problème lié à la promotion de certains contrôleurs de domaine dans Azure. Nous avions configuré le site sur le site VPN et souhaitions étendre la forêt à Azure. Cela semblait être un simple plan… Des problèmes sont survenus lorsque nous avons promu le contrôleur de domaine avec des erreurs telles que

  • Journal système: impossible de traiter le GPO xxx car l'accès est refusé
  • Journal d'application: impossible d'inscrire automatiquement un certificat car l'accès est refusé

Nous avons également constaté que tous les partages administratifs sont revenus avec Access Denied, quel que soit le compte utilisé ou le lieu d'accès au partage….

Nous savions maintenant que nous avions des problèmes, car Bing / Google ne montrait quasiment rien de valeur. Vous savez que c’est mauvais quand Oncle Google et Tante Bing ne vous donnent pas au moins un coup de barre…

Il s'agit d'un tout nouveau contrôleur de domaine, fraîchement joint à un presque nouveau domaine Windows Server 2016 avec des stratégies appliquées par Center for Internet Security (CIS) et désactivant également NetBIOS.

Après quelques jours de dépannage de base, puis une plongée plus poussée dans l'autorité de certification entreprise pour vérifier les autorisations, nous n'avons rien trouvé de grave. Nous avons essayé d’accorder des droits «Tout le monde» pour l’inscription / l’inscription automatique des certificats et avons relâché la sécurité DCOM par défaut, mais en vain. Aucun blocage sur aucun pare-feu, rien ne semblait fâcheux, à part le fait que le CD avait des problèmes pour appliquer les politiques et ne pas avoir de certificat Kerberos bien sûr.

Nous nous sommes ensuite rendus à Wireshark sur le CA pour voir ce qui se passait. Et bien, le DCOM à l'autorité de certification fonctionnait bien. Cependant, une fois que le CD a demandé à l'autorité de certification de lui fournir le certificat, l'autorité de certification se connecte à nouveau sur IPC $ et devinez quoi… Accès refusé. Wireshark a montré que la négociation SMB avait abouti et que les deux serveurs Windows Server 2016 avaient opté pour SMB3 avec SHA256 et AES256. Tout va bien jusqu'à présent, mais lorsque l'autorité de certification demande une connexion de session, elle se voit indiquer non, non, non, non. interdit'

Il s’agissait d’un indice massif car il montrait qu’en réalité le problème concernait le nouveau contrôleur de domaine et qu’il s’agissait d’un problème de type SMB. Maintenant, si vous avez déjà consulté les politiques CIS (732 pages pour le système d’exploitation de Windows Server uniquement), vous savez que déterminer la cause potentielle du problème n’est pas une mince affaire… mais je savais que c’était du SMB maintenant! J’ai exploré le durcissement UNC, qui s’est avéré ne pas être le problème, mais j’ai découvert un paramètre de sécurité appelé "Niveau de validation du nom de la cible du SPN du serveur".

Le texte d'explication de ce paramètre est le suivant:



Serveur réseau Microsoft: niveau de validation du nom de cible du SPN du serveur

Ce paramètre de stratégie contrôle le niveau de validation qu'un ordinateur avec des dossiers partagés ou des imprimantes (le serveur) applique au nom principal de service (SPN) fourni par l'ordinateur client lorsqu'il établit une session à l'aide du protocole SMB (Server Message Block).

Le protocole SMB (Server Message Block) constitue la base du partage de fichiers et d'impression, ainsi que d'autres opérations réseau, telles que l'administration Windows à distance. Le protocole SMB prend en charge la validation du nom principal de service du serveur SMB dans le blob d'authentification fourni par un client SMB afin d'empêcher une classe d'attaques contre les serveurs SMB, appelées attaques par relais SMB. Ce paramètre aura une incidence sur SMB1 et SMB2.

Ce paramètre de sécurité détermine le niveau de validation qu'un serveur SMB effectue sur le nom principal de service (SPN) fourni par le client SMB lors de la tentative d'établissement d'une session sur un serveur SMB.

Les options sont:

Désactivé - le SPN n'est pas requis ni validé par le serveur SMB à partir d'un client SMB.

Accepter si fourni par le client - le serveur SMB acceptera et validera le SPN fourni par le client SMB et autorisera l’établissement d’une session s’il correspond à la liste de SPN du serveur SMB. Si le SPN ne correspond pas, la demande de session de ce client SMB sera refusée.

Requis par le client - le client SMB DOIT envoyer un nom de SPN lors de la configuration de la session et le nom de SPN fourni DOIT correspondre au serveur SMB requis pour établir une connexion. Si aucun SPN n'est fourni par le client ou si le SPN fourni ne correspond pas, la session est refusée.

Par défaut: Off

Tous les systèmes d'exploitation Windows prennent en charge un composant SMB côté client et un composant SMB côté serveur. Ce paramètre affecte le comportement SMB du serveur et son implémentation doit être soigneusement évaluée et testée pour éviter toute interruption des fonctionnalités de service de fichiers et d'impression. Vous trouverez des informations supplémentaires sur la mise en œuvre et l'utilisation de cette stratégie pour sécuriser vos serveurs SMB sur le site Web de Microsoft (http://go.microsoft.com/fwlink/?LinkId=144505).

CIS recommande de le définir sur «Accepter s’il est fourni par le client» afin que le serveur vérifie le SPN auquel le client a demandé de se connecter et échoue s’il n’était pas un SPN pour le serveur. J'ai activé la journalisation d'audit des échecs de partage de fichiers avec Access Object: 5168: la vérification SPN pour SMB / SMB2 a échoué.

Ok, je sais donc qu’il utilise CIFS et je peux voir que l’objet ordinateur d’AD a eu les SPN HOST enregistrés, ce qui devrait fonctionner. Même ajouter explicitement des SPN CIFS ne résoudrait toujours pas le problème. Cependant, je connaissais maintenant le paramètre à l'origine du problème car le fait de rétablir le paramètre par défaut de Désactivé permettait de tout utiliser. Un rapide Google a renvoyé un certain nombre de résultats, notamment Windows Server UserVoice, qui suggère que la combinaison de l'activation de ce paramètre et de la désactivation de NetBIOS produit les symptômes observés.

Espérons que cette description des symptômes, le processus de dépannage et la solution aident quelqu'un à l'avenir et lui évite les 3 jours de travail qu'il doit également pour en arriver à une conclusion.

BONUS pour lire jusqu'au bout: la désactivation de NetBIOS se fait avec une doublure soignée de PowerShell

Get-WMIObject win32_networkadapterconfiguration | ? $ _. IpEnabled -eq $ true | % $ _. settcpipnetbios (2)

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.