Restriction du Windows Update Delivery Optimization par groupe ActiveDirectory

Le WUDO ou Windows Update Delivery Optimization est un composant Windows présent sous Windows 10 qui permet d’optimiser la bande passante réseau consommée lors de la distribution de mises à jour système via WSUS par exemple. En imaginant un réseau d’une dizaine de stations, une seule d’entre elles pourrait utiliser le WAN pour récupérer les mises à jour depuis un serveur WSUS situé en central et les autres utilisent le LAN pour les télécharger à partir de celle les ayant obtenues via le WAN afin d’éviter une saturation de ce dernier. Ce qui peut être un gain de bande passante peut avoir des effets de bord notables ; c’est pourquoi il est possible de contrôler finement le comportement du WUDO via GPO. Un moyen de mieux centrer son action est de passer par la création de groupes ActiveDirectory pour regrouper des stations ; c’est ce que je vais présenter dans cet article.

La problématique est la suivante : des stations du site fictif de Paris utilisent le WAN pour télécharger des mises à jour WSUS sur des stations à Londres. Afin d’éviter de saturer ce lien, on souhaite donc limiter le WUDO à récupérer des données depuis des stations d’un même site uniquement.

Voici la composition de cette maquette de test :

  • OU computers, comprenant 3 OU paris, bxl et london, comprenant les stations propres à chaque site.
  • OU wudo-grp, qui contiendra les groupes AD wudo_paris, wudo_bxl et wudo_ldn dans lesquels seront placées les stations de chaque site.

Il est nécessaire de créer une GPO par groupe AD, d’où l’importance de bien définir ses besoins et surtout, l’organisation qui va être adoptée pour bien séparer les flux de communication WUDO. Une séparation trop granulaire demandera beaucoup de travail d’administration et l’inverse n’aura probablement aucun effet de correction des effets de bord ! Cette GPO va prendre en paramètre unique le GUID du groupe, il faut donc le récupérer et surtout, le stocker quelque part pour toujours avoir une association facile entre GUID et GPO associée.

En Powershell, l’instruction suivante nous permettra de récupérer le GUID du groupe.

(Get-AdGroup wudo_paris).ObjectGuid.Guid

Bien entendu, une boucle foreach dans un script récupérant tous les groupes d’une OU permettra de tous les obtenir facilement.

Désormais, il faut s’occuper de la création des GPO. Les réglages qui nous intéressent sont dans Computer Configuration > Policies > Administrative Templates > Windows Components > Delivery Optimization.

La première option est le Download Mode, qu’il faut passer à 2. La description du paramètre explique bien les différentes options possibles. Il est important de noter que ce qui est désigné comme « LAN » ici n’est pas un LAN au sens physique du terme mais un réseau interne ActiveDirectory. Par exemple, si votre domaine s’appelle schmitouille.net, alors le LAN englobera toutes les stations dans schmitouille.net. Si vous avez des sous-domaines, alors le LAN considèrera les stations du sous-domaine, par exemple fr.schmitouille.net.

Ensuite, l’autre paramètre est Group ID. C’est ici que devra être renseigné le GUID du groupe correspondant. Ici, je vais placer le GUID du groupe wudo_bxl car c’est la GPO qui va régir le WUDO des stations du site fictif de Bruxelles.

Il ne me reste plus qu’à lier cette GPO sur l’OU contenant les stations, et non celle contenant les groupes. Toujours en restant dans le cadre du site de Bruxelles :

… et à répéter l’opération autant de fois que nécessaire. En fonction de l’architecture de l’ActiveDirectory, il peut être nécessaire d’appliquer un Security Filtering sur le groupe d’ordinateurs concerné afin d’être sûr que la GPO ne s’applique que sur les stations désirées.

Afin de faire en sorte que les paramètres soient pris en compte le plus rapidement possible, il est possible de forcer un gpupdate à distance via Powershell. Voici un snippet que j’ai réalisé permettant de passer sur toutes les stations désormais régies par ces politiques de groupe pour mettre à jour ces dernières (à noter qu’en fonction de la disponibilité des stations, des paramètres firewall ou des droits du compte l’exécutant, il peut y avoir des erreurs) :

$grouplist = Get-ADGroup -Filter 'Name -like "wudo_*"'
foreach ($group in $grouplist){
    $complist = Get-AdGroupMember $group
    foreach ($comp in $complist){
        Write-Host "Processing:"$comp.Name
        Invoke-GPUpdate -Computer $comp.Name -RandomDelayInMinutes 0
    }
}

Enfin, pour vérifier que la GPO est bien redescendue, il est possible d’utiliser la fonctionnalité Group Policy Result et d’avoir un rapport indiquant si oui ou non la GPO a bien été appliquée. Si oui, le WUDO de la station concernée ne pourra donc interroger que les membres du groupe AD dont le GUID correspond à la GPO appliquée.

Désactivation de OneDrive via GPO

Petite problématique du jour, désactiver proprement OneDrive sur les stations du domaine via GPO. Rien de bien difficile, tout est déjà prévu dans les politiques pour désactiver le composant OneDrive sur des OS Windows 7 ou plus récents.

Tout d’abord, création d’un groupe d’ordinateurs dans l’ActiveDirectory ; à terme il faudra cibler tous les postes et donc un filtre par défaut suffira une fois la GPO liée à l’OU comprenant les stations, mais étant donné qu’au départ il s’agit d’un pilote, le plus simple était de créer un groupe et d’ajouter dedans petit à petit les stations concernées par la GPO et utiliser le groupe comme filtre.

Les paramètres concernant OneDrive se trouvent dans Computer > Policies > Administrative Templates > Windows Components > OneDrive :

Il suffit d’activer l’option visant à empêcher l’utilisation de OneDrive pour le stockage de fichiers.

Ensuite, lier la GPO sur l’OU concernée ; attention, en utilisant en filtre un groupe d’ordinateurs, il faut lier la GPO sur l’OU englobant toutes les stations concernées, sans quoi la politique ne redescendra pas sur lesdites stations.

Un gpupdate /force plus tard sur les stations visées par la GPO, on a bien disparition du lien OneDrive sur le bandeau de navigation sur la gauche et il est impossible pour certaines applications installées sur la machine de sauvegarder les données sur OneDrive ou même de les charger ; par ailleurs un appel de l’application OneDrive ne donne rien.

Avant.
Après.

Quelques billes pour crypter des stations avec BitLocker

Je travaille en ce moment sur BitLocker et après quelques jours de recherches, de tests et d’usure intensive de disques durs, je suis enfin arrivé à un résultat satisfaisant pour obtenir une GPO définissant des paramètres de sécurité rassurants. Je n’ai pas pour prétention d’avoir trouvé la formule magique vous permettant de crypter dès demain en quelques heures 25,000 stations mais ces quelques notes que je vais partager peuvent constituer une bonne base de travail ou d’appréhension de la technologie. Dans mon exemple, je pars sur des postes clients en Windows 10 équipés d’une puce TPM et avec un AD en niveau 2008 R2.

Il s’agit donc de définir proprement la GPO qui sera récupérée par les postes éligibles et ensuite de lancer le cryptage. Tous les paramètres se retrouvent dans l’arborescence suivante : Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption. Il y a 3 politiques à définir : l’une concernant le disque (au sens logique du terme), la deuxième pour les disques internes et la troisième pour les disques externes.

Concernant les disques hébergeant l’OS :

  • Require additional authentication at startup propose plusieurs réglages et c’est ici que l’on définit ce qui est nécessaire pour continuer le boot du système : la puce TPM simple, un code PIN et la puce TPM, une clef USB avec la puce TPM avec informations de démarrage, ou les 3 à la fois. Attention, un seul de ces 4 paramètres peut être en « requis » (paramètre strict).
  • Si la solution choisie est celle du PIN, il est possible de modifier la longueur minimale de celui-ci dans la très claire propriété Configure minimum PIN length at startup. Par défaut, il ne s’agit que de caractères numériques mais en activant le paramètre dans Allow enhanced PINs for startup, alors les caractères alphanumériques seront autorisés.
  • Dans Enforce Drive encryption type on operating system drive on peut choisir ce qui est crypté sur le disque : l’espace utilisé ou tout le disque. Ce paramètre existe pour les disques locaux non-systèmes.
  • Choose how BitLocker-protected operating system drives can be recovered est un paramètre intéressant car c’est ici que l’on va définir comment récupérer la boulette d’un utilisateur ayant perdu son PIN ou sa clef de déverrouillage. Cela peut se faire soit par un mot de passe de 48 caractères généré aléatoirement lors du cryptage du disque, soit par une clef 256-bits (ou les 2). Ce qui est intéressant ici, c’est que l’on peut stocker dans AD DS ces informations, ce qui fait que l’utilisateur n’a pas à les noter (sous-entendu à écrire la clef de récupération sur un post-it collé sous le laptop ou sur une feuille volante dans la sacoche) et d’un point de vue administrateur, cela permet de tout avoir centré dans un dispositif déjà existant. Afin de stocker ces informations dans l’AD, il y a plusieurs pré-requis, je vous renvoie à cette documentation Microsoft pour plus d’informations. Pour plus de robustesse, il est possible de rendre impossible l’encryption du disque si la sauvegarde des moyens de récupération ne peut pas être effectuée dans l’AD.

Concernant les disques locaux non-système :

  • En fonction de la sécurité à apporter à la station, il est possible de refuser toute écriture sur un disque qui n’est pas crypté par BitLocker dans Deny write access to fixed drives not protected by BitLocker.
  • Les disques non-système ne pouvant évidemment pas demander un PIN, ils peuvent être protégés par un mot de passe. Avec Configure use of passwords for fixed data drives, on définit une politique par rapport à ces mots de passe : longueur et complexité ; la complexité adoptée pour le mot de passe du disque étant la même que celle pour les mots de passe du domaine. Attention à l’éventuel côté pénible d’avoir à se souvenir de « 5847562369 » comme PIN de démarrage et de « @nt1c0n$TitUt10n€II3mEn|- » pour déverrouiller le disque des données…
  • Tout comme les disques système, les moyens de récupération des disques locaux peuvent être stockés dans l’ActiveDirectory grâce aux mêmes réglages offerts dans Choose how BitLocker-protected operating system drives can be recovered.

Concernant les disques amovibles :

  • Une liberté peut être donnée à l’utilisateur de crypter ou non une clef USB ou un disque externe grâce à Control use of BitLocker on removable drives.
  • Et l’on retrouve les mêmes réglages que pour les disques locaux usuelsConfigure use of passwords for fixed data drives et Choose how BitLocker-protected operating system drives can be recovered.

De manière générale :

  • La sauvegarde des mots de passe de récupération et des clefs 256-bits de décryptage s’active grâce au paramètre Store BitLocker recovery information in Active Directory Domain Services. En activant l’option et en demandant de stocker ces informations dans AD DS, la sécurité est augmentée et le travail des administrateurs facilité. Il est également possible de stocker la clef dans un emplacement réseau dans Choose default folder for recovery password.
  • En fonction de l’OS cible, divers algorithmes de cryptages sont disponibles. Avec Windows 10, on peut choisir XTS-AES 256-bit qui semble être le plus sécurisé, avec un inconvénient : cet algorithme n’est pas pris en charge sur les versions inférieures. Les disques internes des stations n’ayant pas pour but d’être démontées et changées de station dans un modèle et avec un OS différent tous les jours, cela ne pose pas de problème en soi ; concernant les périphériques amovibles, la question se pose car il peut être branché sur divers appareils exécutant des OS différents : on peut donc se rabattre sur un algorithme AES-CBC.

Ensuite, côté poste de travail, c’est l’outil manage-bde qui permet d’appliquer le cryptage BitLocker sur les stations ; à noter qu’il faut préalablement que BitLocker ait été activé dans le Panneau de configuration sans quoi manage-bde sera incapable de voir l’intégralité des disques. Il est important de saisir que manage-bde crypte et possède des fonctionnalités basés sur la GPO définie plus haut. Vous ne pourrez par exemple pas crypter la station sans PIN ou ne pas obtenir de mot de passe de récupération si ils sont requis ou crypter avec un algorithme différent de celui renvoyé par la GPO.

Par exemple, si je souhaite crypter mon disque système et qu’un code PIN ainsi que mot de passe de récupération sont nécessaires, cela va se dérouler ainsi dans un cmd en administrateur :

manage-bde -on c: -tpmandpin -rp

Le PIN est demandé après la validation de l’instruction. Dans le cadre d’un disque non-système :

manage-bde -on d: -rp -password

Le mot de passe est demandé après l’envoi de la commande. Bien évidemment, l’outil manage-bde offre d’autres possibilités avec d’autres arguments, je vous renvoie à la documentation de MS à ce sujet.

A noter que l’utilisateur peut ensuite changer son PIN ou le mot de passe de déverrouillage de son disque. D’autres paramètres sont accessibles si l’utilisateur est administrateur du poste.

Une fois le cryptage commencé, on peut retrouver dans l’AD sur les propriétés d’un objet Ordinateur les informations de récupérations définies dans la GPO grâce à l’onglet BitLocker Recovery.

Oui, j’ai réalisé de nombreux tests sur mon poste pilote.

Cet onglet est visible une fois que les outils de management BitLocker ont été déployés sur le contrôleur de domaine (ou sur la machine hébergeant les outils de management).