Migration de la définition des shares Windows

C'est ballot, mais Robocopy est incapable de faire une copie d'un répertoire en conservant son statut de répertoire partagé et les détails associés. Lorsqu'on migre un serveur de fichiers avec par exemple des homedirs, il faut donc transférer les dossiers vers le nouveau avec Robocopy, puis ensuite, appliquer les partages. Plutôt contraignant si il y a des centaines de répertoires à refaire.

Heureusement, si le serveur d'origine et de destination ont exactement la même configuration disque et les mêmes chemins, il est possible d'extraire la définition des shares et donc de l'importer sur le nouveau serveur pour que les répertoires soient de nouveau partagés.

La clef HKLM\System\CurrentControlSet\Services\LanmanServer\Shares contient ces définitions :

Ces clés contiennent le nom du partage, ainsi que d'autres informations (chemin, description)... Il est donc important que les chemins concordent ; en effet, ouvrir le fichier .reg contenant la clef et ses valeurs avec un éditeur de texte ne permettra pas une modification directe.

Un redémarrage est nécessaire après l'import de la clef sur le nouveau serveur afin que les partages soient visibles dans la console Computer Management.

Impossibilité de se connecter à Veeam après un changement de nom de machine

J'ai récemment été confronté à la situation où après un remplacement de serveur de sauvegarde fonctionnant sous Veeam Backup & Replication entraînant un changement de nom, je ne pouvais plus me connecter même en local.

La console ne peut pas se connecter car le service Veeam Backup Service n'est pas démarré. Il accepte de se lancer, mais se coupe aussitôt.

La solution se trouve dans le registre, où Veeam stocke en dur le nom de la machine lors de l'installation. Fatalement, lorsqu'il change par la suite, les deux valeurs ne concordent plus, et le service ne peut s'exécuter.

Il faut aller chercher dans HKLM\SOFTWARE\Veeam, les clefs Veeam Backup and Replication et Veeam Backup Catalog. Ces deux clefs contiennent une entrée chacune avec l'ancien hostname.

La valeur de SqlServerName doit être votre nom de serveur, p. ex. "srv-veeambkp"
Ici, le hostname fait partie d'un chemin. Par exemple, la valeur sera "\\srv-veeambkp\VBRCatalog".

L'information est disponible sur ce fil de discussion sur les forums Veeam, merci au contributeur d'avoir exposé la solution.

Powershell : modification du registre pour contourner CredSSP

Au mois de mars, des correctifs Microsoft ont corrigé certaines failles par rapport à CredSSP qui est notamment utilisé pour sécuriser des connexions RDP (voir ce lien). Un message d'erreur peut survenir si un client patché tente de se connecter à un serveur non patché ou vice-versa. Pour faire simple, il est nécessaire que client comme serveur soient patchés pour qu'ils puissent communiquer.

J'ai réalisé un script Powershell permettant de contourner la sécurité via le registre afin que le système ne tienne pas compte du delta de version entre le CredSSP client et serveur. Dans un monde parfait, cela ne devrait pas exister car postes de travail et serveurs devraient être patchés en temps et en heure, mais la réalité est bien évidemment tout autre pour tout un tas de raisons. 👍

#Requires -RunAsAdministrator
$CredSspPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$ParametersPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP"
$AllowEncryptionOraclePath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters"
New-Item -Path $CredSspPath -Name "CredSSP" -Force
New-Item -Path $ParametersPath -Name "Parameters" -Force
New-ItemProperty -Path $AllowEncryptionOraclePath -Name "AllowEncryptionOracle" -PropertyType DWORD -Value "2" -Force
Write-Host "If everything went fine, please reboot the system for the changes to take effect."
Sleep 5

Le script doit être lancé en administrateur ; une fois les clefs déployées, il est nécessaire de redémarrer la station qui devrait pouvoir se connecter sans le message d'erreur plus haut, ce qui ne dispense évidemment pas d'une campagne de patch ! 😉

Vous pouvez trouver une version commentée du script sur le serveur de fichiers en cliquant sur ce lien. 💾

Désactivation des ciphers AES 128, AES 256 et 3DES 168 sous Windows Server

Il y a peu, j'ai dû désactiver sur une plateforme TLS 1.0 et 1.1. Aujourd'hui, rebelote, mais avec les ciphers Triple DES, ainsi qu'AES 128 et 256.

J'ai placé un extract de ces clefs de registre dans une archive disponible sur mon miroir de téléchargement.

En ouvrant regedit, on va se placer dans le chemin suivant :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

Puis, il suffira de créer une clef par cipher que l'on souhaite désactiver. Dans notre cas, nous allons créer 3 clefs ayant les noms suivants :

  • Triple DES 168
  • AES 128
  • AES 256

Dans chacune de ces clefs, il faudra créer une valeur DWORD appelée Enabled et ayant pour valeur 0.

On obtient donc quelque chose de similaire à ceci :

Un redémarrage est nécessaire pour appliquer les modifications car la DLL schannel ne lit les paramètres du registre qu'au démarrage du système. Si jamais il y a besoin d'annuler les modifications réalisées, il suffit de supprimer les clefs tout juste créées. A noter que si il y a désactivation d'un cipher utilisé pour encrypter les pages web utilisées par le serveur IIS, ces pages ne seront plus accessbiles, il convient donc de faire un test au préalable et de désactiver avec parcimonie les ciphers.

Si l'on désactive le cipher AES 256 via le registre, cette page ne sera plus accessible

Plus d'informations concernant les ciphers désactivables sous Windows sont disponibles à ce lien.

Désactivation de TLS 1.0, TLS 1.1 et activation de TLS 1.2 sur Windows Server 2008 R2 et +

Il a été décidé par les responsables d'une plateforme sur laquelle je suis intervenu ce jour de la désactivation de TLS 1.0 et 1.1 au profit de 1.2 sur un serveur Windows 2008 R2 utilisant IIS 7. Je vais donc décrire dans cet article les modifications qui sont à réaliser en base de registre - je pense réaliser par la suite un script permettant l'automatisation de la création et peuplement de ces clefs.

En préalable, il est important de vérifier que le KB 3080079 soit installé sur le serveur si 2008 R2, sans quoi une fois la désactivation de TLS 1.0 effective il ne sera plus possible d'accéder en Remote Desktop sur le serveur. Je renvoie à cette page pour plus d'informations.

J'ai réalisé une archive ZIP des clefs de registre évoquées dans ce billet sur mon miroir de téléchargement.

Dans la base de registre, on ira jusqu'à la clef suivante :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Une fois dans cette clef, il suffira de créer une clef supplémentaire par protocole. On créé donc 3 clefs : TLS 1.0, TLS 1.1 et TLS 1.2. A noter qu'il est fort probable que soient déjà présentes d'autres clefs pour SSL, comme sur cette capture d'écran.

Dans chacune des clefs TLS, il faudra créer 2 sous-clefs : Client et Server. L'arborescence ressemble donc à cela :

Dans chacune des 6 clefs qui ont été crées, il faudra ajouter 2 valeurs DWORD en hexadécimal :

  • DisabledByDefault, qui aura toujours la valeur 0
  • Enabled, qui aura la valeur 0 pour TLS 1.0 et TLS 1.1 et la valeur 1 pour TLS 1.2.

Ce qui donne, pour TLS 1.0\Client, TLS 1.0\Server, TLS 1.1\Client et TLS 1.1\Server :

Pour TLS 1.2\Client et TLS 1.2\Server :

Ensuite, un redémarrage du serveur suffit pour que les modifications soient prises en compte. Les protocoles TLS 1.0 et 1.1 ne sont plus actifs. A noter que ces clefs de registre peuvent également être appliquées sur Windows Server 2012 et R2.

Si jamais le Remote Desktop ne fonctionne plus une fois TLS 1.0 désactivé et que le patch est bien installé sur le serveur (si antérieur à 2012), il faut forcer le Terminal Server à utiliser son encryption et non celle de TLS 1.0. Pour ce faire, on ouvrira tsconfig.msc, puis les propriétés du serveur. Cette fenêtre s'ouvre :

Il est important que le Security Layer soit basculé sur RDP Security Layer et non TLS 1.0, faute de quoi la connexion sera impossible.