Installation¶
HGPM est un module PowerShell. Il demande PowerShell 7.4 ou plus sur toutes les plateformes ; le reste dépend de ce que vous en faites, et où.
Le module¶
Installez-le depuis la PowerShell Gallery, ou construisez-le depuis le dépôt (la branche master) :
Avec PSResourceGet, le module de PowerShell 7.4 et suivants qui remplace PowerShellGet
(Install-Module) :
Depuis la 0.2.0, HGPM a des versions publiées : plus de -Prerelease. Une version alpha installée
avant (0.1.x-alpha, avec -Prerelease) passe à la version publiée avec
Update-PSResource -Name HGPM, qui installe aussi les versions plus récentes ensuite
(mises à jour).
Le runtime Avalonia¶
La fenêtre fonctionne sur Avalonia 11. Ses assemblies ne sont pas livrées avec le module : à la
première ouverture d'une fenêtre, la console télécharge les 21 paquets NuGet de
Resources/AvaloniaPackages.json pour le runtime de l'ordinateur (win-x64, win-arm64,
linux-x64, linux-arm64, osx), vérifie chacun avec son SHA-512 épinglé (l'empreinte du
catalogue nuget.org) avant d'extraire quoi que ce soit, puis chaque fichier du runtime avec son
SHA-256 épinglé, et les met en place d'un coup. La console vérifie de nouveau ces fichiers à chaque
chargement, et refuse une bibliothèque ajoutée à côté.
- Ils vont dans le dossier du module quand on peut y écrire, sinon dans le dossier de données de l'utilisateur.
PSGPOTOOLS_AVALONIA_NO_DOWNLOAD=1interdit le téléchargement (ordinateurs hors ligne : les archives hors ligne de chaque release ont le runtime).PSGPOTOOLS_NUGET_SOURCEles prend dans un flux NuGet interne, ou un dossier de fichiers.nupkg, au lieu de nuget.org ; les empreintes épinglées s'appliquent de même (installation hors ligne). Un téléchargement est essayé trois fois, deux minutes chacune.Avalonia/Get-AvaloniaBinaries.ps1les installe à l'avance, ou pour un autre ordinateur. Il charge le module : depuis le dépôt, construisez-le d'abord (CI/03_Build.ps1).
Les commandes qui n'ouvrent pas de fenêtre (sauvegardes, écart, approbation…) n'ont jamais besoin d'Avalonia.
Les fichiers ADMX¶
Le module n'embarque pas de fichiers ADMX : la console lit ceux du magasin central du domaine
(\domaine\SYSVOL\domaine\Policies\PolicyDefinitions), de Windows (%windir%\PolicyDefinitions)
ou du SYSVOL d'un contrôleur de domaine Samba, sinon demande un dossier. Comme GPMC, elle prend
le magasin central du domaine qu'elle montre quand il a des fichiers ADMX, sauf si un autre dossier
a été choisi dans sa fenêtre, qui propose d'abord le magasin central ; Initialize-PSGPOAdmx sans
-Path prend aussi le magasin central. Les fichiers d'un dossier
sont analysés une fois, puis lus dans un cache de l'utilisateur tant qu'ils gardent leurs noms,
tailles et dates (%LOCALAPPDATA%\PSGPOTools\Admx sous Windows ; $XDG_CACHE_HOME/PSGPOTools/Admx,
sinon ~/.cache/PSGPOTools/Admx ailleurs ; -NoCache les analyse). Là où il n'y en a pas (un
ordinateur Linux, un domaine sans magasin central), Install-PSGPOAdmx installe ceux de Windows
depuis le paquet de Microsoft, Administrative Templates (.admx) for Windows 11 (un .msi de
download.microsoft.com : 236 fichiers .admx, leurs fichiers .adml en 22 langues). HGPM ne les
livre ni ne les redistribue : ce sont les fichiers de Microsoft, selon ses conditions. La commande
extrait le paquet sans l'installer (msiexec /a sous Windows ; sous Linux et macOS msiextract,
du paquet msitools : sudo apt install msitools, sudo dnf install msitools,
brew install msitools). Le module épingle le paquet (sa taille et son SHA-256) et chaque ensemble
de ses fichiers (les .admx, chaque langue) : un paquet ou des fichiers qui diffèrent sont refusés
avant que rien ne soit écrit.
Install-PSGPOAdmx # en-US et la langue de la session, à côté du module
Install-PSGPOAdmx -UICulture en-US, fr-FR # les langues choisies
Install-PSGPOAdmx -AllLanguages -Path ~/PolicyDefinitions
Install-PSGPOAdmx -CentralStore -Server dc.hardenbox.labo -UICulture en-US, fr-FR # le magasin central du domaine
Install-PSGPOAdmx -MsiPath './Administrative Templates (.admx) for Windows 11 Sep 2026 Update.msi' # sans internet
Sans -Path, les fichiers vont à côté du module quand on peut y écrire, sinon dans le dossier de
données de l'utilisateur (PSGPOTools/PolicyDefinitions) : la console les y trouve. Avec
-CentralStore, ils vont dans SYSVOL\<domaine>\Policies\PolicyDefinitions du contrôleur de
domaine (un compte qui peut écrire SYSVOL : un administrateur du domaine), comme pour GPMC : toutes
les consoles du domaine les lisent alors. Les fichiers ADMX déjà présents sont gardés, ceux de même
nom remplacés ; s'il y en a déjà, ajoutez -Force. Un ordinateur sans internet : téléchargez le
paquet sur un autre (la page de Microsoft est dans l'erreur d'un téléchargement qui échoue) et
donnez-le avec -MsiPath ; il est vérifié comme un téléchargement.
Le cache des fichiers ADMX¶
Analyser un dossier PolicyDefinitions prend quelques secondes, et chaque console du lanceur
s'ouvre dans un processus à elle : ce qu'un chargement lit est gardé dans un cache de
l'utilisateur, un fichier par dossier et par langue (%LOCALAPPDATA%\PSGPOTools\Admx sous
Windows ; $XDG_CACHE_HOME/PSGPOTools/Admx, sinon ~/.cache/PSGPOTools/Admx ailleurs).
- Quand il est écrit : la première fois qu'un dossier est chargé dans une langue, par ce qui le
charge : la console des GPO la première fois qu'elle a besoin des stratégies (l'éditeur, les
onglets Paramètres et Historique, un rapport ; jamais pour les liaisons, la délégation ou
l'approbation), ou avant de s'ouvrir avec
-PolicyDefinitions; l'éditeur seul (-NoDirectory) et Policy Analyzer à leur démarrage ; Charger dans la fenêtre des ADMX ;Initialize-PSGPOAdmx. Il est écrit à côté, puis renommé : une console qui s'ouvre pendant ce temps lit l'ancien fichier ou le nouveau, jamais la moitié d'un. - Quand il est lu : tant que les fichiers
.admx, et les fichiers.admlde la langue et d'en-US, gardent leurs noms, tailles et dates, avec la même version de HGPM. Un fichier ajouté, modifié ou supprimé (un nouveau modèle dans le magasin central), ou une mise à jour de HGPM, et le chargement suivant analyse de nouveau les fichiers et réécrit le cache : quelques secondes encore une fois. - Quand il n'est pas écrit : avec
-NoCache, après une erreur, ou quand un fichier a été écarté pour une raison qui peut passer (le réseau, les droits) : le chargement suivant analyse de nouveau les fichiers plutôt que de garder un chargement auquel il en manque. Un cache qui ne peut pas être écrit ne fait que ralentir le chargement suivant. - Le vider : supprimez son dossier, rien d'autre n'est perdu ; le chargement suivant le réécrit.
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\PSGPOTools\Admx" # Windows
Remove-Item -Recurse -Force ~/.cache/PSGPOTools/Admx # Linux, sans XDG_CACHE_HOME
Windows¶
| Besoin | Pourquoi | Comment |
|---|---|---|
| Un compte du domaine | la console lit le domaine avec l'identité de la session (Kerberos) | ouvrez une session avec, ou -Credential avec -UseSsl |
| Outils RSAT de gestion des stratégies de groupe | créer et supprimer des GPO (New-GPO, Remove-GPO) |
Add-WindowsCapability -Online -Name 'Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0' (Windows 10/11), Install-WindowsFeature GPMC (Server) |
| Outils RSAT Active Directory | facultatif : seuls les scripts de test s'en servent | Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0' |
Le module GroupPolicy est un module Windows PowerShell : PowerShell 7 le masque à
Get-Module -ListAvailable et le charge par sa compatibilité Windows PowerShell. La console le
trouve avec -SkipEditionCheck.
SYSVOL est lu et écrit par son chemin UNC (\\dc\SYSVOL\domaine\Policies\{GUID}), avec
l'identité de la session.
Une session ouverte en SSH avec une clé
Une session OpenSSH ouverte avec une clé n'a pas d'identifiants réseau (ouverture S4U) : les connexions LDAP échouent et SYSVOL est inaccessible. Lancez la console dans une session interactive, ou en SSH avec un mot de passe.
Linux¶
| Besoin | Pourquoi | Debian / Ubuntu | RHEL / Fedora |
|---|---|---|---|
| Bibliothèque cliente OpenLDAP | LDAP depuis .NET | apt install libldap2 |
dnf install openldap |
| Module SASL GSSAPI | Kerberos sur LDAP | apt install libsasl2-modules-gssapi-mit |
dnf install cyrus-sasl-gssapi |
| Client Kerberos | le ticket qu'utilise la console | apt install krb5-user |
dnf install krb5-workstation |
smbclient |
lire et écrire SYSVOL | apt install smbclient |
dnf install samba-client |
samba-tool, bindings Python de Samba |
créer et supprimer des GPO, droits SYSVOL | apt install python3-samba samba-common-bin |
dnf install samba-tools python3-samba |
| Une session graphique | la fenêtre (X11, ou Wayland avec XWayland) |
La console s'authentifie en Kerberos : prenez d'abord un ticket, et donnez le contrôleur de domaine par son nom DNS (Kerberos demande le nom, pas l'adresse IP).
Aucun mot de passe n'est jamais donné à samba-tool ni à smbclient, ni envoyé en LDAP en
clair : avec -Credential, utilisez -UseSsl (LDAPS), et les modifications demandent tout de
même un ticket Kerberos.
-Credential sous Windows
Sous Windows, un domaine lu avec -Credential (et -UseSsl) est modifié avec ce compte dans
l'annuaire et dans SYSVOL : la console ouvre une connexion SMB à \\<dc>\SYSVOL avec
lui, comme net use \\<dc>\SYSVOL /user:.... Windows n'a qu'un compte par serveur dans une
session : si la session atteint déjà ce serveur avec un autre compte, la console le dit
(net use \\<dc>\* /delete ferme ces connexions). Créer et supprimer une GPO passent par RSAT,
qui ne connaît que l'identité de la session : ils sont refusés avec -Credential.
Vérifier l'installation¶
Import-Module HGPM
Get-Command -Module HGPM # les commandes publiques
Get-PSGPODirectory -Server dc.hardenbox.labo | Select-Object DomainName, Account, Source
La barre d'état de la fenêtre dit aussi ce que la console a trouvé : cet ordinateur, son domaine, le contrôleur de domaine et son service d'annuaire.
Mises à jour¶
L'import du module donne sa version, et la commande qui installe une version plus récente quand la PowerShell Gallery en a une :
PS> Import-Module HGPM
HGPM 0.2.0
HGPM 0.2.1 is available on the PowerShell Gallery: Update-PSResource -Name HGPM, then open a new PowerShell session.
L'import lit la Gallery au plus une fois par jour (UpdateCheck.json dans le dossier de données
local de l'utilisateur, PSGPOTools), et attend 8 secondes au plus : sans réseau, il ne donne que
la version, et ne réessaie pas avant une heure. Il ne la lit pas dans une CI, dans une session lancée avec -NonInteractive, ni avec
PSGPOTOOLS_SKIP_UPDATE_CHECK=1. La nouvelle version sert à une nouvelle session PowerShell : celle
en cours garde le module qu'elle a importé.
Test-PSGPOUpdate dit si une version plus récente de HGPM est publiée sur la PowerShell Gallery,
et donne la commande qui l'installe. Elle compare la version chargée à la dernière de la Gallery
comme des versions sémantiques : 0.1.4-alpha passe avant 0.1.4-beta, elle-même avant 0.1.4.
Les préversions comptent quand la version chargée en est une (ou avec -Prerelease).
Test-PSGPOUpdate
# Name : HGPM
# InstalledVersion : 0.2.0
# LatestVersion : 0.2.1
# UpdateAvailable : True
# UpdateCommand : Update-PSResource -Name HGPM
if (Test-PSGPOUpdate -Quiet) { Update-PSResource -Name HGPM }
Mettre à jour HGPM¶
- Fermez les consoles (
Show-GPOManagerAvalonia,Show-PSOManagerAvalonia) et les sessions PowerShell qui ont importé HGPM : une session garde le module qu'elle a importé. -
Installez la nouvelle version, comme le module a été installé :
La nouvelle version s'installe à côté de l'ancienne (un dossier par version dans
Modules/HGPM). Un module installé pour tous les utilisateurs (-Scope AllUsers) se met à jour en administrateur, avec-Scope AllUsers(sudo pwshsous Linux). Installé avec PowerShellGet (Install-Module) :Update-Module -Name HGPM. -
Vérifiez dans une nouvelle session PowerShell : l'import donne la nouvelle version, sans la ligne
is available, et la pastille de la barre d'état des consoles est verte. -
Si besoin, supprimez une ancienne version :
Uninstall-PSResource -Name HGPM -Version <version>.
Les changements de chaque version sont dans le journal des modifications.