SMBv1 (Server Message Block), un protocole faible qui peut perdurer encore.
Dans un environnement contenant un ou plusieurs serveurs Windows Server 2003 et des systèmes d’exploitation de la même génération, en tant que machines jointes au domaine (scénarios suffisamment réalistes au regard de certaines applications métier), l’arrivée des contrôleurs de domaine Windows Server 2019 Active Directory engendre quelques interrogations légitimes.
Le protocole SMBv1 est celui utilisé par ces machines Windows Server 2003, tandis que ce même protocole SMBv1 n’est plus vraiment le protocole de prédilection des familles de systèmes d’exploitation à jour, e.g. Windows Server 2016, Windows Server 2019 et cætera en tant que serveurs d’infrastructure Windows Active Directory.
Cette situation pose clairement un problème vis-à-vis du maintien en condition opérationnelle des applications adossées aux serveurs applicatifs « obsolètes », typiquement Windows Server 2003. Le dilemme est davantage de taille si la mise à niveau de ces machines applicatives n’est pas une option facilement envisageable.
Le cadre étant maintenant posé, ce qui suivra nous montrera les actions techniques possibles à mettre en œuvre pour garantir une cohabitation entre des vieux systèmes d’exploitation et des serveurs d’infrastructure moderne Active Directory (2016 ou 2019).
L’activation de la fonctionnalité SMBv1, selon une commande tout à fait standard, est toujours faisable : dism /online /Enable-Feature /FeatureName:SMB1Protocol /All /source:%drive%:\wim\mount\windows\winsxs /limitaccess
Cette activation requiert un redémarrage.
Une fois la machine Windows Server 2019 ou 2016 redémarrée, vous pouvez exécuter la commande suivante afin de vérifier la bonne disponibilité du protocole SMBv1 : Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. La propriété State devrait alors indiquer Enabled, signe que l’installation s’est correctement déroulée.
Une fois ces étapes franchies, la cohabitation entre Windows 2016 ou 2019 Active Directory et un client Windows Server 2003 est donc faisable et vérifiable ; cela requiert distinctement l’utilisation d’un protocole faible.
Plusieurs recommandations semblent indiquer ne plus jamais activer SMBv1 ? Mais une analyse situationnelle reste de mise. C’est typiquement la question à un million de dollars devant être tranchée entre les départements techniques et métiers, sans rien délaisser de la gestion des risques.
Gardez quelque part dans l’esprit que dans certaines situations, à part cette activation du protocole faible SMBv1 (à l’encontre des recommandations techniques), il n’y a tout simplement aucune autre possibilité immédiate que votre application adossée à un vieux système d’exploitation puisse rester opérationnelle, dans le cadre d’une mise à niveau de l’infrastructure Active Directory.
Tout ceci pour dire que ce schéma typiquement IT est tout à fait valable pour des machines industrielles basées sur Windows Server 2003, Windows XP et autres systèmes d’exploitation du genre.
Dans l’IT et l’OT (deux environnements qui doivent être séparés pour rappel), c’est donc le même combat : comment sécuriser sans introduire aucune régression fonctionnelle applicative vis-à-vis du métier ?
Quelque part, si la cartographie applicative des entreprises existe (pour certains) et est à jour (pour tous), planifier et anticiper pour trouver des compromis moins douloureux dans le cadre d’une mise à niveau des serveurs d’infrastructure deviendraient une réalité.
Bref, tout ne peut pas complètement être à jour instantanément parce que la technique et les règles de sécurité poussées par des éditeurs l’exigent. Il y a parfois des enjeux prioritaires requérant une transgression nette des règles faites par des entités qui ignorent tout de votre business.
La technique, au service du business pour rappel, ne fait pas tout, même s’il est toujours bon de la maîtriser totalement.
Le métier l’emporte toujours, c’est une part de réponse 🙂