11. Renforcer la sécurité de votre installation WAPT - Côté Console¶
11.1. Génération de l’autorité de certification (CA) ¶
Lors de l’installation de WAPT, il vous est demandé de créer une paire .pem / .crt en cochant les cases Pour Signature de code et Pour usage en tant que CA.
Cette paire .pem / .crt permettra de signer les paquets WAPT et les nouveaux certificats.
11.1.1. Générer un nouveau certificat avec l’Autorité de Certification¶
Le nouveau certificat ne sera pas un certificat auto-signé ;
Ce nouveau certificat sera signé par le CA (la clé générée lors de la première installation de WAPT) ;
Vous devez ensuite remplir la Clé privée de l’autorité et le Certificat de l’autorité.
Lors de la génération de la nouvelle paire pem/ crt, vous avez la possibilité de choisir si le nouveau certificat sera de type Pour Signature de code ou non.
Indication
Pour rappel, un certificat Pour Signature de code est réservé aux personnes ayant le rôle Administrateur dans le contexte de WAPT et un simple certificat SSL sans l’attribut Pour Signature de code est réservé aux personnes ayant le rôle Déployeur de paquet.
Les Administrateurs seront autorisés à signer les paquets qui CONTIENNENT un fichier exécutable setup.py (c’est-à-dire les paquets base).
Les personnes ayant le rôle de Déployeur de paquet seront autorisées à signer les paquets qui NE CONTIENNENT PAS le fichier exécutable setup.py (c’est-à-dire les paquets host, unit et group).
Génération d’un certificat sans l’attribut Pour Signature de code¶
Les clés et les certificats qui ne sont pas Signature de code peuvent être distribués aux personnes chargées de déployer les paquets sur la base installée des appareils équipés de WAPT.
Une autre équipe disposant de certificats ayant l’attribut Pour Signature de code préparera les paquets WAPT contenant les applications qui devront être configurées conformément aux directives de sécurité de l’Organisation et aux personnalisations utilisateur souhaitées par celle-ci.
Génération d’un certificat avec l’attribut Pour Signature de code¶
La génération d’une nouvelle paire .pem / .crt permettra également d’identifier formellement la personne qui a signé un paquet en recherchant l’attribut CN du certificat de paquet WAPT.
Indication
Les nouveaux certificats ne seront pas des Autorités de Certification, ce qui signifie qu’ils ne seront pas autorisés à signer d’autres certificats.
En règle générale, il n’y a qu’une seule paire pem / crt d”Autorité de Certification par Organisation.
Attention
Il n’est pas nécessaire de déployer des certificats enfants avec l’Agent WAPT.
Les certificats enfants sont utilisés avec la Console WAPT pour autoriser ou restreindre les actions dans la console.
11.1.2. Déploiement des certificats des administrateurs informatiques locaux sur les clients¶
Indication
Certaines organisations choisiront de laisser les administrateurs informatiques locaux effectuer des actions sur les appareils équipés de WAPT en leur délivrant des certificats personnels qui fonctionneront sur l’ensemble des appareils dont les administrateurs informatiques locaux sont responsables.
Les administrateurs informatiques du siège déploieront les certificats des administrateurs informatiques locaux sur les ordinateurs que les administrateurs locaux gèrent sur leurs sites respectifs.
Ainsi, les administrateurs informatiques locaux ne pourront pas gérer les ordinateurs situés au siège, mais uniquement sur leurs propres sites.
Il est possible de gérer simplement et de manière plus fine en utilisant Access Control Lists avec la version Enterprise de WAPT.
Vous devrez copier les certificats des administrateurs informatiques locaux autorisés sur les clients WAPT dans C:\programfiles(x86)\wapt\ssl.
Indication
Ne pas oublier de redémarrer le service WAPT sur les clients pour qu’ils utilisent leur nouveau certificat. Ouvrez une console en ligne de commande cmd.exe.
netstopwaptservice&&netstartwaptservice
Si vous voulez déployer les certificats en utilisant WAPT, utilisez un paquet de certificat
11.2. Afficher l’onglet des certificats dans la Console WAPT¶
Dans cet onglet, vous pouvez voir les certificats auxquels la machine accepte de faire confiance.
Fenêtre montrant les certificats approuvés par la machine sélectionnée¶
11.3. Configuration des listes de contrôle d’accès ¶
Indication
L’utilisateur SuperAdmin de WAPT est authentifié par un mot de passe stocké dans waptserver.ini comme valeur de l’attribut wapt_password. Les autres utilisateurs WAPT peuvent être des utilisateurs locaux htpasswd_path) ou des utilisateurs de comptes AD (ldap_auth_server / ldap_auth_base_dn).
Les ACL définissent les actions autorisées pour tous les types d’utilisateurs dans le contexte WAPT.
Note
Les ACLs par défaut au niveau utilisateur sont définies par default_ldap_users_acls dans waptserver.ini.
L’ACL par défaut pour un nouvel utilisateur est vue.
Attention
La sécurité est définie par le certificat déployé sur les clients, et non par les ACL.
Les ACL limitent simplement les actions que le serveur est autorisé à relayer de la Console WAPT aux Agents WAPT.
A la date du 2026-06-15 , les Agents WAPT ne vérifient pas les droits ACL.
Pour configurer les ACL dans WAPT, allez dans Serveur ‣ Gérer les utilisateurs WAPT et des droits.
Note
Au premier lancement après l’installation du Serveur WAPT, seul le compte SuperAdmin est présent dans la liste des utilisateurs.
Si le compte SuperAdmin n’existe pas ou ne possède pas le droit admin, le compte est recréé en redémarrant le service du Serveur WAPT.
Le compte SuperAdmin est authentifié en utilisant la valeur de wapt_password dans le fichier de configuration waptserver.ini.
Si l’utilisateur local a un mot de passe dans waptusers.htpasswd, alors, le nom d’utilisateur apparaît en gras et Mots de passe est coché, sinon changez le mot de passe pour cet utilisateur.
Par défaut, le SuperAdmin est l’utilisateur du Certificat CA.
Pour les autres utilisateurs, il est possible d’associer un certificat généré à partir du WAPT PKI ou d’une autre CA.
Ces certificats peuvent ou non être des enfants de l’autorité de certification WAPT.
Important
Si les certificats ne sont pas émis par l’autorité de certification :
Les paquets WAPT mis à jour ne sont disponibles que sur les ordinateurs sur lesquels des certificats sont déployés. Utilisez cette section pour créer et déployer facilement des certificats utilisateur.
Les ACL sont valides uniquement sur le périmètre des hôtes où le certificat de l’administrateur est déployé.
Sélectionner un utilisateur.
Choisissez une ou plusieurs ACLs à assigner.
Définissez l’autorisation ( souvent interdire ou autoriser).
Sauvegarder vos changements.
Exemple : attribuer l’autorisation « enregistrer les hôtes » à l’utilisateur user1.¶
Ouvrir la console WAPT.
Accédez à Serveur → Gestion des utilisateurs et les droits Wapt → Nouveau role.
Saisissez le nom du rôle.
Une fois le rôle créé, vous pouvez y ajouter des listes ACL.
Attribuez le rôle aux utilisateurs concernés.
Enregistrez les modifications.
Exemple : attribuer le rôle local « waptpackages » à l’utilisateur user1.¶
Action AD (RSAT ou OpenRSAT)
Créer un groupe d’utilisateurs (par exemple, waptpackage).
Ajoutez les utilisateurs concernés à ce groupe.
Dans la console WAPT.
Accédez à Serveur → Gestion des utilisateurs et les droits Wapt → Nouveau role.
Aucune édition n’est autorisée pour aucun paquet (non coché).
Autoriser tous les paquets
Le droit de modification est autorisé pour tous les paquets WAPT.
Autoriser des noms de paquets spécifiques
Permet le droit d’édition pour les paquets WAPT sélectionnés dans la liste.
11.4. Re-signer les paquets sur le serveur WAPT en utilisant la console WAPT¶
Il est possible qu’un paquet ait été créé par un utilisateur WAPT dont le certificat n’est pas reconnu sur certaines machines. Toutefois, le paquet peut encore convenir à ces machines. Dans ce cas, vous pouvez re-signer le paquet en utilisant le certificat d’un autre utilisateur WAPT qui a des privilèges plus élevés au sein du réseau.
Allez dans Dépôt privé, identifiez votre paquet et cliquez avec le bouton droit sur Resigner les paquets.
A browser window will open, prompting you to grant access to the application. Check the consent box for your organization.
Expected Output:
Code: 1.AR8AbB103-z_eEidXlooPaYJLuvHmHHwvztCsV7nQNvj_yhMAbwfAA.AgABBAIAAABVrSpeuWamRam2jAF1XRQEAwDs_wUA9P9CWi14DUUxhFdifAJG6aygRZwO_bcwGzCXOSlkGUD_YmYsWHGIiBHLiUX5lWnYU0qk847CCOmJxnKZyDepL6-d40yYYhHq
...
ClientSecret is known, using it to exchange code for a token...
Token: {"aud":"00000003-0000-0000-c000-000000000000","iss":"https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/","iat":1758812637,"nbf":1758812637,"exp":1758817061,"acct":0,"acr":"1","acrs":
[...0","b79fbf4d-3ef9-4689-8143-76b194e85509"],"xms_ftd":"4Bv2ZusNHcpIBqPAClu5jRjnL-ldhsTz0S54w-3nbrABZXVyb3Bld2VzdC1kc21z","xms_idrel":"1 10","xms_st":{"sub":"xRnlPpQ8mrb2xYcinckhWxAIaaoeiUfLoX3sFoKidK8"},"xms_tcdt":1517
233874,"xms_tdbr":"EU"}
ID Token: {"aud":"7198c7eb-bff0-423b-b15e-e740dbe3ff28","iss":"https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0","iat":1758812637,"nbf":1758812637,"exp":1758816537,"rh":"1.A
R8AbB103-z_eEidXlooPaYJLuvHmHHwvztCsV7nQNvj_yhMAbwfAA.","sub":"xRnlPpQ8mrb2xYcinckhWxAIaaoeiUfLoX3sFoKidK8","tid":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","uti":"cABi3a7vQECEsCD_EAVUAA","ver":"2.0"}
User authenticated: XXXX XXXXXXX
End session: 1
6. Assign Application Roles:
In Microsoft Entra ID, navigate to Enterprise Applications.
Select your newly registered application.
Go to Users and groups > Add user/group.
Select the users who will have the waptadmins role.
7. Verify Role Assignment in Token:
Test the authentication again with the following command:
Ensure the token contains the role assignment: "roles":["waptadmins"].
8. Configure Roles in the WAPT Console:
Log in to the WAPT console with an admin account.
Navigate to User and Rights Management.
Check Roles > New Role.
Rename the default role (e.g., role1) to waptadmins.
Assign the desired permissions, then close the window and log out.
Reopen the console and log in using the OAuth2/OpenID Connect option.
Bearer Token
A Bearer Token can be generated using various authentication methods to verify the user’s identity, such as Kerberos or username/password credentials.
To enable this feature, add token to the login_auth_methods parameter in the waptserver.ini file. After making this change, restart the WAPT services to apply the modifications:
systemctlrestartwaptserverwapttasks
How to create a token examples:
Open a command prompt on the machine
Run wapt-getserver-login and enter your credentials (local account or user@mydomain.lan)
A token will be generated, which you can use to access the console
Run wapt-getserver-login--login_method=sessionkerberos
A token will be generated, which you can use to access the console
Note
For this moment token have a lifetime to 12h, to change it you can modify the value of the token_lifetime in the file /opt/wapt/waptserver/config.py .
x509 certificate
It is possible to connect to the WAPT Console using an X.509 certificate. This method provides a secure and passwordless authentication option.
How to configure it
In the WAPT Console:
Create a User Certificate: Generate a certificate with the same name as the user (example: certificate john for user john@domain.lan ).
Associate the Certificate with the User: In the WAPT Console, go to User Rights Management and link the certificate to the user.
In the WAPT Console, navigate to Server > Manage WAPT Users and Rights (ACLs).
Select the desired user.
Click Register User Certificate and upload the user’s X.509 certificate.
In the WAPT Server:
Update waptserver.ini: Add ssl to the authentication methods parameter login_auth_methods.
Create a Client Certificates File: Create a file (e.g., /opt/wapt/conf/ca-clients.crt) and append the public parts of user certificates to it.
Configure Nginx: Edit /etc/nginx/sites-enabled/wapt.conf and modify the line : ssl_client_certificate « /opt/wapt/conf/ca-clients.crt ».
¶
