À partir d'aujourd'hui, Microsoft indique que les pilotes pour les systèmes Windows 7, Windows Server 2008 et Windows Server 2008 R2 ne seront plus distribués par Windows Update.
Pourquoi une telle décision ? Tout simplement parce que le certificat racine de l'autorité de certification SHA-1 pour Windows 7 et Windows Server 2008 est expiré depuis le 9 mai 2021.
En 2019, Microsoft invitait déjà les utilisateurs de Windows 7 et Windows Server à 2008 à installer les signatures de code SHA-2 sur leur machine pour continuer à recevoir les mises à jour du système. À l'époque, Microsoft avait stoppé les signatures SHA-1 pour les mises à jour pour laisser la place aux signatures SHA-2. Tous les téléchargements signés avec SHA-1 avaient été retirés du site de Microsoft.
Malgré l'abandon des certificats SHA-1, les partenaires de Microsoft membres du programme Trusted Root peuvent toujours publier des pilotes signés avec SHA-2. Néanmoins, ces pilotes sont incompatibles sur des systèmes Windows 7 et Windows Server non patchés pour prendre en charge SHA-2, ce qui entraîner des problèmes de démarrage du système. Par précaution, Microsoft a pris la décision d'arrêter la diffusion des pilotes pour Windows 7, Windows Server 2008 et Windows Server 2008 R2.
Comme l'explique Microsoft, dans le cas où votre entreprise est membre du programme payant "Extended Security Updates", vous pouvez continuer à déployer les pilotes via WSUS ou un système équivalent. Cela permettra aux fabricants membres du programme Windows Hardware Compatibility de mettre à disposition des pilotes auprès des entreprises. D'ailleurs, Microsoft a publié sur son site la nouvelle procédure à appliquer pour signer des pilotes pour Windows 7 et Windows Server 2008/2008 R2.
La fonctionnalité PowerShell Just Enough Administration (JEA) est disponible depuis la version 5.0 de PowerShell. Dans ce tutoriel, je vous propose de découvrir comment mettre en œuvre la fonctionnalité JEA pour déléguer l'accès à certaines tâches d'administration à des utilisateurs qui ne sont pas administrateurs.
Tutoriel disponible au format vidéo :
Grâce à PowerShell Just Enough Administration, nous allons gagner en flexibilité dans la gestion des sessions PowerShell. Avec JEA, vous pouvez autoriser un utilisateur à effectuer une tâche spécifique sur un serveur, au travers de PowerShell et d'une session distante, sans qu'il soit administrateur du serveur ou du service cible.
Concrètement, on peut définir précisément quelles sont les commandes qu'un utilisateur peut exécuter ou non sur une machine au travers d'une session distante. Indépendamment du fait qu'il soit administrateur ou non de cette même machine. Par exemple, vous pouvez autoriser un utilisateur à redémarrer uniquement le service "DHCP" de votre serveur (ou votre serveur web "IIS"), mais aucun autre service (DNS, NTDS, etc...).
En bref, avec PowerShell JEA, on peut :
Réduire le nombre de personnes qui sont réellement "administrateur" d'un serveur
Limiter les actions réalisables par les utilisateurs sur un serveur grâce à des règles
Tracer les actions des utilisateurs par l'intermédiaire de la transcription (chaque commande exécutée sera consignée dans un fichier)
II. Comment implémenter PowerShell JEA ?
PowerShell Just Enough Administration est intégré à Windows 10 et à Windows Server 2016 (et versions supérieures), car il est inclus dans PowerShell 5.0. Cette version de PowerShell est native sur ces OS.
Pour les versions plus anciennes de Windows Server, à savoir Windows Server 2008 R2, Windows Server 2012 et Windows Server 2012 R2, il faudra passer sur PowerShell 5.0. Pour cela, l'installation de Windows Management Framework 5.0 (au minimum) est obligatoire.
Ensuite, PowerShell JEA ne demande qu'une chose : être utilisé, alors à vous de jouer !
III. Créer un fichier de configuration de session (PSSC)
Au fait qu'allons-nous mettre en place comme configuration PowerShel JEA ?
L'idée, c'est de créer une configuration sur notre serveur SRV-ADDS-01 pour permettre aux membres du groupe Active Directory "Support-IT" d'exécuter quelques commandes pour gérer le service DHCP. En effet, ce serveur est un contrôleur de domaine, mais c'est également un serveur DHCP. Les membres du groupe "Support-IT" doivent pouvoir redémarrer le service DHCP, redémarrer le serveur (sait-on jamais... en dernier recours), lister les services actifs sur le serveur et réaliser un ping à partir de ce serveur.
À la fin, nous allons tester la configuration depuis machine distante sous Windows 10 nommée "PC-W10-01".
Bon, le décor est planté, on va attaquer la configuration... Ouvrez une console Powershell en tant qu'administrateur sur votre serveur.
La première étape consiste à créer un fichier pour la configuration de notre session.
Ce fichier sera nommé "SRV-ADDS-01-Manage.pssc". L'extension PSSC correspond à PowerShell Session Configuration. On utilise le cmdlet prévu à cet effet : New-PSSessionConfigurationFile.
On se rend compte qu'il n'est pas vide ! C'est un template que nous allons modifier à notre sauce.
PowerShell JEA - Exemple de fichier PSSC (PowerShell Session Configuration File)
Il y a quatre paramètres qui m'intéressent particulièrement :
- SessionType
Nous allons remplacer la valeur "Default" par "RestrictedRemoteServer". C'est recommandé par Microsoft (et moi aussi !), car cela va restreindre directement les commandes accessibles.
SessionType = 'RestrictedRemoteServer'
Avec ce mode, l'utilisateur peut utiliser seulement les commandes suivantes :
Clear-Host
Exit-PSSession
Get-Command
Get-FormatData
Get-Help
Measure-Object
Out-Default
Select-Object
Des commandes pratiques, non dangereuses, tout va bien !
- TranscriptDirectory
Chaque session distante aura son propre journal de transcription. Ces fichiers de transcription doivent être stockés dans un dossier : précisez le chemin de ce dossier et pensez à le créer.
TranscriptDirectory = 'C:\Scripting\Transcripts\'
- RunAsVirtualAccount
Lorsque cette option est à $true (vrai), l'utilisateur bénéficie d'un compte virtuel qui est administrateur local du serveur. Autrement dit, les actions que l'utilisateur va exécuter seront effectuées avec des droits "admin" sur le serveur même si lui n'est pas administrateur du serveur.
RunAsVirtualAccount = $true
Si votre utilisateur va exécuter des actions sur le serveur distant qui ne nécessite pas des droits d'administration complets, il y a une option complémentaire à définir : RunAsVirtualAccountGroups. Elle sert à spécifier un ou plusieurs groupes locaux (et seulement locaux) auxquels doit appartenir l'utilisateur. Un état intermédiaire pour être administrateur d'un service spécifique. Par exemple :
Pour accéder à des ressources situées sur le réseau, il faut utiliser une autre directive et spécifier un gMSA : GroupManagedServiceAccount. Néanmoins, c'est à utiliser seulement lorsque c'est indispensable, car la traçabilité devient plus complexe étant donné que le compte peut avoir accès à des ressources du réseau. Par exemple :
Dans cet exemple, nous resterons sur l'utilisation standard avec "RunAsVirtualAccount = $true".
- RoleDefinitions
Nous allons préciser le groupe de sécurité Active Directory qui est autorisé à utiliser cette session, puis le nom du rôle associé. En fait, nous verrons que le rôle contient la liste des actions autorisées, notamment les commandes PowerShell que peut exécuter l'utilisateur.
Pour ma part, je déclare le groupe "it-connect.local\Support-IT" et je l'associe au rôle "Support-IT_Manage". Puisque ce groupe doit pouvoir gérer le service DHCP, j'aurais pu choisir un nom un peu plus parlant comme "DHCP_Admins". Mais bon, restons sur "Support-IT_Manage".
En complément, dans la configuration vous pouvez modifier le champ "Author" pour indiquer votre nom.
Note : lorsque cela est nécessaire, pensez à décommenter les lignes à activer, c'est-à-dire supprimer le "#" en début de ligne. Sinon, la ligne sera ignorée.
L'édition du fichier de configuration est terminée. Sauvegardez puis exécutez la commande ci-dessous. Cette commande va permettre de vérifier la syntaxe de notre fichier : s'il y a une erreur, autant le savoir maintenant.
IV. Créer un fichier pour la configuration du rôle (PSRC)
Dans notre fichier de configuration de la session, nous avons déclaré le rôle "Support-IT_Manage", mais elle n'a pas encore de configuration. Pas de panique, on s'en occupe maintenant.
Commencez par créer un dossier "RoleCapabilities" sur votre serveur pour stocker l'ensemble des fichiers de configuration de vos rôles.
Le dossier étant créé, on va créer notre fichier "Support-IT_Manage.psrc" tout en sachant que l'extension PSRC correspond à PowerShell Session Role Capabilities. Ce fichier doit être nommé de la même façon que le rôle, c'est impératif.
Là encore, on utilise un cmdlet spécifique pour créer ce fichier dans le but d'obtenir un template : New-PSRoleCapabilityFile.
Dans ce fichier, nous pouvons déclarer différents types d'éléments pour les autoriser : commandes PowerShell, outils externes (exécutables), fonctions, alias, modules, etc.
Pour déclarer les commandes PowerShell autorisées, nous allons devoir configurer l'option "VisibleCmdlets". Il y a plusieurs façons de renseigner cette option :
Préciser le nom d'une commande, par exemple "Get-Service", sans rien d'autre, l'utilisateur peut exécuter cette commande sans restriction, c'est-à-dire en utilisant tous les paramètres de cette commande
Préciser le nom d'une commande ainsi que les valeurs autorisées pour un ou plusieurs paramètres de cette commande
Pour rappel, nous souhaitons que les membres du groupe "Support-IT" soient autorisés à exécuter les actions ci-dessous (avec en prime la commande correspondante) :
Redémarrer le service DHCP
Restart-Service -Name DHCPServer
Redémarrer le serveur
Restart-Computer
Lister les services actifs sur le serveur
Get-Service
Réaliser un ping à partir de ce serveur.
ping
Il faut donc que l'on autorise les cmdlets "Restart-Computer" et "Get-Service", sans réelle restriction. Ensuite, il faut que l'on permette à l'utilisateur de redémarrer le service "DHCPServer" et seulement celui-ci !
Du coup, la commande PowerShell à autoriser est :
Restart-Service -NameDHCPServer
Au sein de la configuration, voici comment nous allons transposer cette commande :
@{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'DHCPServer' }}
On précise que l'on accepte seulement "DHCPServer" comme valeur pour le paramètre "-Name". Si l'on veut autoriser plusieurs valeurs, voici la syntaxe (pour autoriser aussi la valeur "NTDS") :
@{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'DHCPServer', 'NTDS'}}
Au final, voici la ligne complète pour autoriser les trois cmdlets :
VisibleCmdlets = 'Restart-Computer', @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'DHCPServer' }}, Get-Service
Pour autoriser le "ping" (car oui il est bloqué lui aussi même si c'est une commande basique !), il faut configurer l'option "VisibleExternalCommands". On précise tout simplement le chemin complet vers "ping.exe", ce qui donne :
Notre fichier de configuration du rôle est prêt ! Sauvegardez et fermez le fichier.
PowerShell JEA - Exemple de fichier PSRC (PowerShell Session Role Capabilities)
V. Enregistrer la nouvelle configuration de session
Nous devons enregistrer cette session PowerShell pour qu'elle soit utilisable. Le cmdlet Register-PSSessionConfiguration doit être utilisé. On va spécifier le nom de la configuration "Support-IT" et le chemin vers le fichier PSSC : SRV-ADDS-01-Manage.pssc.
Ce qui est intéressant, c'est de lister les configurations de sessions disponibles sur votre machine. La commande Get-PSSessionConfiguration est notre amie pour cela :
On voit bien notre configuration "Support-IT" et que l'accès est autorisé au groupe "IT-Connect\Support-IT".
Get-PSSessionConfiguration - Lister les configurations de sessions
C'est l'heure de tester notre configuration...
VI. Tester la session restreinte via PowerShell JEA
Je bascule sur mon poste client Windows 10.... J'ouvre une session avec l'utilisateur "Florian". Il s'agit d'un utilisateur du domaine membre du groupe "Support-IT".
À l'aide d'une console PowerShell, je vais essayer de me connecter sur mon serveur SRV-ADDS-01. Chose habituelle, j'utilise Enter-PSSession. Voici la commande :
Enter-PSSession -ComputerName SRV-ADDS-01
Et là, ça ne fonctionne pas : Accès refusé.
C'est normal, car nous devons spécifier le nom de la configuration à utiliser pour que le serveur autorise notre connexion à partir d'un utilisateur lambda. Reprenons la commande précédente en précisant "-ConfigurationName Support-IT" :
Là, ça fonctionne : parfait ! On peut essayer quelques commandes... Des commandes que l'on a autorisées et d'autres non pour voir ce qui se passe...
Quand la commande n'est pas autorisée, la console nous dit que le terme n'est pas reconnu, comme si la commande n'existait pas (idem pour un programme non autorisé). Quand la commande est autorisée, mais que la valeur d'un paramètre n'est pas correcte, on obtient une erreur qui fait référence à l'attribut ValidateSet (défini dans le fichier de configuration du rôle).
Note : sur la copie d'écran ci-dessous, "Get-Service" ne fonctionne pas, mais c'est normal, car il n'était pas dans ma configuration au moment du test.
Démonstration d'une session restreinte avec PowerShell JEA
Cela fonctionne vraiment bien ! Pour quitter la session, on précisera :
exit
Si vous modifiez votre fichier de rôle (PSRC) pour ajouter une commande par exemple, il n'est pas nécessaire de réinscrire votre session sur le serveur (Register-PSSessionConfiguration). Ce sera pris en compte directement. Par contre, si la session PowerShell distante est en cours, il faudra la fermer et la rouvrir pour que le changement soit pris en compte.
VII. La transcription de PowerShell JEA
Suite aux différents essais et à l'utilisation de la session PowerShell "Support-IT", il y a eu quelques fichiers de transcriptions créés sur notre serveur : un fichier par session.
Au début de chaque fichier, nous avons :
L'heure du début de la session
L'utilisateur qui a ouvert cette session distante
Le nom de la configuration
L'ordinateur cible
Ensuite, le fichier contient une trace de toutes les commandes exécutées, y compris lorsque l'utilisateur tente d'exécuter une commande non autorisée. Par exemple, voici la ligne générée lorsque j'ai exécuté "Restart-Service DHCPServer" :
PS>CommandInvocation (Restart-Service) : « Restart-Service »
>> Liaison de paramètre (Restart-Service) : nom = « Name » ; valeur = « DHCPServer »
À la fin du fichier, nous pouvons retrouver l'heure de fin, c'est-à-dire l'heure à laquelle notre session s'est terminée.
**********************
Fin de la transcription Windows PowerShell
Heure de fin : 20210526161044
**********************
VIII. Conclusion
PowerShell JEA est très pratique pour attribuer de façon précise des droits aux utilisateurs non administrateurs, que ce soit pour exécuter un cmdlet, un programme ou un script.
En tout cas, Powershell JEA n'est pas spécialement utile pour les utilisateurs "Admins du domaine" ou "Administrateurs" d'un serveur. En effet, un administrateur pourrait facilement contourner les restrictions de Powershell JEA en se connectant directement sur le serveur en RDP, par exemple.
Définir un rôle au sein de PowerShell Just Enough Configuration n'est pas toujours simple ! Il faut penser à toutes les commandes que pourraient avoir besoin la personne qui va intervenir, en fonction de ce qu'elle a besoin de faire. Par contre, ce qui est génial, c'est que l'utilisateur sera limité à ces quelques actions. D'un point de vue de la sécurité, c'est top !
Pour aller plus loin, je vous recommande de prendre connaissance de ce fichier du GitHub officiel de Microsoft. Il représente une base intéressante pour créer un fichier de rôle sur le support de niveau 1 d'un serveur : PowerShell JEA - Exemple
Bulletin d’actualité du 17/05/2021 Nous voici de nouveau ensemble dans notre rendez-vous de fin de semaine pour revenir sur les différents bulletins de sécurité publiés par le CERT-FR ! Durant la période du 10 mai au 16 mai 2021, le CERT-FR (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques en France) a …
À l'occasion du Patch Tuesday de mai 2021, Microsoft a corrigé une faille de sécurité critique dans la pile du protocole HTTP et plus particulièrement dans le pilote HTTP.sys. Cette faille est dite "wormable" c'est-à-dire qu'elle peut être exploitée par un ver informatique. Désormais, il existe un exploit pour tirer profit de cette faille de sécurité.
Référencée sous le nom CVE-2021-31166, la faille de sécurité touche la pile du protocole HTTP (HTTP.sys) intégrée à Windows 10 et Windows Server. Il s'avère que la faille touche HTTP.sys, un pilote en mode noyau qui permet à Windows de gérer les requêtes HTTP. Ce pilote est exploité par IIS (serveur Web), mais aussi par WinRM pour la gestion à distance, ainsi que SSDP.
Cette vulnérabilité est désormais corrigée par Microsoft et elle touche exclusivement Windows 10 en version 2004 et 20H2, ainsi que Windows Server 2004 et 20H2 également. Pour Windows Server, cela concerne aussi les installations en mode Core. Les versions antérieures ne sont pas concernées.
Microsoft recommande de patcher toutes les machines affectées dès que possible, car un attaquant, non authentifié, peut exploiter cette faille. En exploitant cette faille, il peut exécuter du code malveillant sur votre serveur, le tout à distance. Par "toutes les machines affectées", j'entends tous les serveurs et postes de travail qui exécutent une version de Windows concernée, et pas seulement celles qui exécutent un serveur IIS puisqu'il y a divers composants qui s'appuient sur ce pilote HTTP.sys.
CVE-2021-31166 : un exploit qui mène à un déni de service
Un chercheur en sécurité nommé Axel Souchet a publié un code de l'exploit sur GitHub en guise de proof-of-concept. Dans son exemple, l'attaque mène à un déni de service puisque la machine ciblée génère un écran bleu de la mort (BSoD).
Suite à la publication du code de cet exploit, le risque c'est qu'un ver informatique soit créé et qu'il soit en mesure de se déplacer de machine en machine en tirant profit de la faille CVE-2021-31166.
Voici le message publié par Axel Souchet sur Twitter :
La bonne nouvelle dans tout ça, c'est que la faille de sécurité touche les toutes dernières versions de Windows 10 et Windows Server : deux versions pas forcément adoptées par les entreprises pour le moment.
Microsoft introduced Storage Spaces Direct with Windows Server 2016. Since then, the OS has included all the components to set up a hyper-converged infrastructure. Based on the same technologies, the company announced Azure Stack HCI two years ago. What are the differences between the two solutions?
If you add computers or users to a security group in Active Directory, there will be no immediate effect. The associated permissions only take effect after a user has logged on again or the computer has been rebooted. This can be avoided by renewing the Kerberos tickets.
Microsoft a publié un nouveau type d'image baptisé Windows Base OS, en version preview, basé sur Windows Server 2022 et destinée à être utilisée dans des containers.
Pour rappel, actuellement, Windows Server est proposé sous la forme de trois types d'images :
Nano Server : une image ultra légère d'une centaine de Mo destiné à l'utilisation de quelques rôles spécifiques, au développement d'applications et à l'utilisation en mode container avec Docker
Core Server : une image de Windows Server sans l'interface graphique (et les composants associés)
Windows : une image complète de Windows Server, de quelques Go, avec l'interface graphique et tous les composants (l'image que l'on connaît depuis toujours)
Microsoft va ajouter un nouveau type d'images supplémentaires pour répondre à la demande de la communauté Windows Container : l'image Windows Base OS. En fait, il s'agit d'une image équivalente à Server Core, à la différence qu'elle est construite à partir d'une édition avec Desktop Experience active. Microsoft parle d'une image équivalente à "Server Core" + "Desktop UI", basée sur Windows Server 2022. Par ailleurs, il est bien précisé que même si cette image est basée sur une version de Windows avec une interface graphique, les containers Windows n'ont pas d'interface graphique : ce sera toujours le cas avec cette image.
Avec cette image, Microsoft a levé certaines limites en comparaison d'un container avec l'image complète de Windows Server. Par exemple, un serveur IIS en mode container avait une limite de 10 connexions, désormais cette limite est levée. En termes de performances et de fiabilité, cette image hérite de toutes les améliorations apportées à Server Core sur ces dernières années, ainsi que le support des GPU dans les containers. Par ailleurs, cette image bénéficiera d'un support LTSC de 5 ans. En fait, cette image semble être la solution adaptée pour vos futurs scénarios basés sur des containers Windows Server.
Au final, au niveau des poids des images, cela donne :
Nano Server : 112 Mo
Server Core : 1,2 Go
Windows : 3,4 Go
Windows Base OS / Server : 3,1 Go
Microsoft explique sur son site comment créer un nouveau container basé sur cette nouvelle image "Windows Base OS" de Windows Server 2022 (voir lien ci-dessous).
FreshRSS 
Tutoriel disponible au format vidéo :
