8. Renforcer la sécurité de votre installation WAPT - Côté Serveur¶

Par défaut, tous les paquets WAPT sont signés avec votre clé privée, ce qui offre déjà un haut niveau de sécurité. Cependant, vous pouvez améliorer davantage la sécurité de WAPT.

Pour sécuriser complètement votre installation WAPT, vous devez procéder comme suit :

Activez l’enregistrement authentifié pour filtrer les personnes autorisées à enregistrer le périphérique auprès du Serveur WAPT.
Activez la vérification du certificat https sur les Agents et la Console WAPT pour vous assurer que les Agents WAPT et la Console WAPT se connectent au bon Serveur WAPT.
Configurez l’authentification Active Directory pour permettre l’accès à la Console WAPT uniquement aux administrateurs WAPT autorisés.
Activez l’authentification par certificat côté client pour n’autoriser que les appareils authentifiés à accéder au Serveur WAPT (Remarque : c’est particulièrement important si vous voulez exposer votre Serveur WAPT à l’extérieur dans une DMZ).
Si vous utilisez la version Enterprise de WAPT et que vous exploitez une grande flotte avec plusieurs administrateurs, vous serez peut-être intéressé de savoir comment configurer et appliquer correctement les ACLs.

8.1. Configuration du pare-feu sur le Serveur WAPT¶

La configuration du pare-feu du Serveur WAPT est essentielle et devrait être la première étape pour obtenir une meilleure sécurité dans WAPT.

Comme WAPT vise à être sécurisé dès la conception, seul un ensemble minimal de ports ouverts est nécessaire sur le Serveur WAPT par rapport aux autres solutions.

Vous trouverez dans la documentation suivante des conseils autour des configurations de pare-feu pour renforcer la sécurité du Serveur WAPT.

8.1.1. Configuration du pare-feu pour le serveur WAPT sur Debian et dérivées¶

Par défaut sur Debian Linux, aucune règle de pare-feu ne s’applique.

Désactivez ufw et installez firewalld à la place.

ufw disable
apt update
apt -y install firewalld

Il suffit d’appliquer cette configuration firewalld.

systemctl start firewalld
systemctl enable firewalld
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --add-port=443/tcp --permanent
systemctl restart firewalld

8.1.2. Configuration du pare-feu pour le Serveur WAPT sur RedHat et dérivées¶

Il suffit d’appliquer cette configuration firewalld.

systemctl start firewalld
systemctl enable firewalld
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --add-port=443/tcp --permanent
systemctl restart firewalld

8.2. Configuration de l’authentification kerberos¶

Note

Sans l’authentification kerberos, vous devez soit faire confiance à l’enregistrement initial, soit saisir un mot de passe pour chaque poste de travail lors de l’enregistrement initial.
Pour plus d’informations, consultez la documentation sur l’enregistrement d’une machine auprès du Serveur WAPT et la signature des mises à jour d’inventaire.
L’authentification kerberos sera utilisée uniquement lors de l’enregistrement de la machine.

8.2.1. Installation des composants kerberos et configuration du fichier krb5.conf¶

apt install krb5-user msktutil libnginx-mod-http-auth-spnego

yum install krb5-workstation msktutil nginx-mod-http-auth-spnego

Note

L’enregistrement avec kerberos n’est pas disponible avec un Serveur WAPT fonctionnant sous Windows.

Modifiez le fichier /etc/krb5.conf et remplacez tout le contenu par les 4 lignes suivantes en remplaçant MYDOMAIN.LAN par votre nom de domaine Active Directory (i.e. <MYDOMAIN.LAN>).

Attention

La valeur default_realm doit être écrit en MAJUSCULES ! ! !

[libdefaults]
  default_realm = MYDOMAIN.LAN
  dns_lookup_kdc = true
  dns_lookup_realm=false

Récupérer un keytab de service. Utiliser les commandes kinit et klist. Vous pouvez utiliser un compte Administrateur ou tout autre compte ayant le droit délégué de joindre un ordinateur au domaine dans le conteneur de destination approprié (par défaut CN=Computers).

Dans la transcription shell ci-dessous, les commandes sont en noir et le texte renvoyé est commenté en gris clair :

sudo kinit administrator
## Password for administrator@MYDOMAIN.LAN:
## Warning: Your password will expire in 277 days on Mon. 17 sept. 2018 10:51:21 CEST
sudo klist
## Ticket cache: FILE:/tmp/krb5cc_0
## Default principal: administrator@MYDOMAIN.LAN
##
## Valid starting       Expires              Service principal
## 01/12/2017 16:49:31  02/12/2017 02:49:31  krbtgt/MYDOMAIN.LAN@MYDOMAIN.LAN
## renew until 02/12/2017 16:49:27

Si la demande d’authentification est réussie, vous pouvez alors créer votre Keytab HTTP avec la commande msktutil.

Veillez à modifier la chaîne <DOMAIN_CONTROLER> avec le nom de votre contrôleur de domaine (par exemple : srvads.mydomain.lan).

sudo msktutil --server DOMAIN_CONTROLER --precreate --host $(hostname) -b cn=computers --service HTTP --description "host account for wapt server" --enctypes 28 -N
sudo msktutil --server DOMAIN_CONTROLER --auto-update --keytab /etc/nginx/http-krb5.keytab --host $(hostname) -N

Attention

Assurez-vous d’avoir correctement configuré votre nom d’hôte de Serveur WAPT avant d’exécuter ces commandes ;

Afin de vérifier votre nom d’hôte, vous pouvez exécuter echo $(hostname) et il DOIT renvoyer le nom qui sera utilisé par l’Agent WAPT exécuté sur les postes de travail clients. Si votre Serveur WAPT est disponible sur Internet, vous devez ajouter un autre servicePrincipalName (SPN) pour qu’il corresponde à l’URL publique WAPT. Pour pouvoir mettre à jour le fichier keytab, vous devez lancer une seconde fois la commande msktutil à chaque fois que vous allez ajouter un nouveau SPN.

Vous pouvez ajouter une tâche de mise à jour automatique dans la crontab. Elle modifiera fréquemment le mot de passe du compte machine dans Active Directory afin que vous puissiez passer les audits de sécurité. Contenu de la crontab :

32 23 * * * root msktutil --auto-update --keytab /etc/nginx/http-krb5.keytab

Appliquez les droits d’accès appropriés au fichier http-krb5.keytab. Si vous avez un système d’exploitation basé sur Redhat avec selinux, veuillez fixer les droits avec restorecon.

sudo chmod 640 /etc/nginx/http-krb5.keytab
sudo chown root:www-data /etc/nginx/http-krb5.keytab

sudo chown root:nginx /etc/nginx/http-krb5.keytab
sudo chmod 640 /etc/nginx/http-krb5.keytab
restorecon -v -R /etc/nginx/http-krb5.keytab

8.2.2. Post-configuration de kerberos pour le Serveur WAPT¶

Vous pouvez maintenant utiliser le script de post-configuration pour configurer le Serveur WAPT afin d’utiliser kerberos.

Le script de post-configuration va configurer Nginx et le Serveur WAPT pour utiliser l’authentification kerberos.

Indication

Ce script de post-configuration DOIT être exécuté en tant que root.

/opt/wapt/waptserver/scripts/postconf.sh --force-https

L’authentification Kerberos sera maintenant configurée.

8.2.3. Cas particuliers d’utilisation¶

8.2.3.1. Mon Serveur WAPT n’a pas accès à un Active Directory en écriture¶

Connectez-vous à votre Active Directory (pas un RODC).
Créez un compte d’ordinateur srvwapt.
Ajouter un SPN sur le compte srvwapt$.

setspn -A HTTP/srvwapt.mydomain.lan srvwapt

Créer un keytab pour ce Serveur WAPT.

ktpass -out C:\http-krb5.keytab -princ HTTP/srvwapt.mydomain.lan@MYDOMAIN.LAN rndpass -minpass 64 -crypto all -pType KRB5_NT_PRINCIPAL /mapuser srvwapt$@MYDOMAIN.LAN
Reset SRVWAPT$'s password [y/n]? y

Note

Si l’adresse de votre Serveur WAPT est différente de celle de votre domaine Active Directory, remplacez HTTP/srvwapt.mydomain.lan@MYDOMAIN.LAN par HTTP/srvwapt.othername.com@MYDOMAIN.LAN.

Transférez ce fichier dans /etc/nginx/ (avec winscp par exemple).
Appliquez les droits d’accès appropriés au fichier http-krb5.keytab. Si vous avez un système d’exploitation basé sur Redhat avec selinux, veuillez fixer les droits avec restorecon.

sudo chmod 640 /etc/nginx/http-krb5.keytab
sudo chown root:www-data /etc/nginx/http-krb5.keytab

sudo chown root:nginx /etc/nginx/http-krb5.keytab
sudo chmod 640 /etc/nginx/http-krb5.keytab
restorecon -v -R /etc/nginx/http-krb5.keytab

8.2.3.2. L’Agent WAPT n’a accès qu’à un contrôleur de domaine RODC¶

Pour RODC, ajoutez le compte srvwapt au groupe de mots de passe autorisés pour la réplication.
N’oubliez pas de précharger le mot de passe du Serveur WAPT avec les différents serveurs RODC.

Précharger le mot de passe du compte srvwapt

8.2.3.3. Vous avez plusieurs domaines Active Directory, avec ou sans relations¶

Si vous avez plusieurs domaines Active Directory, vous devez créer un keytab par domaine en suivant la procédure ci-dessus, ex :

http-krb5-domain1.local.keytab ;
http-krb5-domain2.local.keytab ;
http-krb5-domain3.local.keytab.

Vous devrez ensuite fusionner tous ces keytabs en un unique keytab :

ktutil
read_kt http-krb5-domain1.local.keytab
read_kt http-krb5-domain2.local.keytab
read_kt http-krb5-domain3.local.keytab
write_kt http-krb5.keytab

8.2.4. Débugger les problèmes avec les kerberos¶

Attention

L’adresse du Serveur WAPT ne peut pas être une IP, Kerberos ne fonctionne bien qu’avec le DNS.
Dans votre test, l’url utilisée doit être exactement la même adresse que celle indiquée dans C:\Program Files (x86)\waptwapt-get.ini.

8.2.4.1. Avez-vous redémarré nginx correctement ?¶

systemctl restart nginx

8.2.4.2. Vérifier les permissions du fichier http-krb5.keytab¶

[root@srvwapt.mydomain.lan]# ls -l /etc/nginx/http-krb5.keytab
-rw-r----- 1 root www-data 921 janv. 4 16:20 /etc/nginx/http-krb5.keytab

8.2.4.3. Le mode kerberos est-il actif sur mon Agent WAPT ?¶

Sur la machine Windows :

Vérifiez dans votre C:\Program Files (x86)\wapt\wapt-get.ini que la valeur use_kerberos est True.

[global]
use_kerberos=True

Si vous modifiez cette valeur, n’oubliez pas de redémarrer le service WAPT.

net stop waptservice
net start waptservice

8.2.4.4. Le mode Kerberos est-il actif sur mon Serveur WAPT ?¶

Sur la machine linux :

Vérifiez dans votre /opt/wapt/conf/waptserver.ini que la valeur use_kerberos est True.

[options]
use_kerberos=True

Vérifiez dans votre /etc/nginx/sites-enabled/wapt.conf que cette configuration est présente.

location ~ ^/.*_kerberos$ {

      proxy_http_version 1.1;
      proxy_request_buffering off;

      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      # be sure these headers are not forwarded
      proxy_set_header X-Ssl-Client-Dn "";
      proxy_set_header X-Ssl-Authenticated "";

      auth_gss on;
      auth_gss_keytab /etc/nginx/http-krb5.keytab;
      proxy_pass http://127.0.0.1:8080;

  }

Si l’une des deux configurations n’est pas présente, redémarrez la post-configuration et activez kerberos.

8.2.4.5. Vérification que le fichier keytab contient l’url correcte¶

[root@srvwapt.mydomaine.lan]# KRB5_KTNAME=/etc/nginx/http-krb5.keytab klist -k
Keytab name: FILE:/etc/nginx/http-krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   ...
   3 HTTP/srvwapt.ad.mydomain.lan@AD.MYDOMAIN.LAN
   ...

8.2.4.6. Essayer d’enregistrer l’hôte en utilisant un compte système¶

Pour passer à un compte système, vous DEVEZ utiliser l’outil psexe de Microsoft : psexe.

Dans cmd en tant qu’administrateur.

C:\Users\\xxxxxx\\Downloads\\PSTools\\psexec.exe -accepteula -s -i cmd

Dans la nouvelle fenêtre cmd, vérifiez que vous êtes identifié comme System.

C:\WINDOWS\\system32>whoami

NT AUTHORITY\System

Exécutez la commande register.

wapt-get register

8.2.4.7. Tenter une authentification avec le keytab de votre Serveur WAPT¶

Sur la machine linux.

[root@srvwapt.ad.tranq ~]# ktutil
ktutil: read_kt /etc/nginx/http-krb5.keytab
ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
  1    3                  srvwapt$@AD.TRANQUIL.IT
  2    3                  srvwapt$@AD.TRANQUIL.IT
  3    3                  srvwapt$@AD.TRANQUIL.IT
  4    3                  SRVWAPT$@AD.TRANQUIL.IT
  5    3                  SRVWAPT$@AD.TRANQUIL.IT
  6    3                  SRVWAPT$@AD.TRANQUIL.IT
  7    3              host/srvwapt@AD.TRANQUIL.IT
  8    3              host/srvwapt@AD.TRANQUIL.IT
  9    3              host/srvwapt@AD.TRANQUIL.IT
 10    3 HTTP/srvwapt.ad.tranquil.it@AD.TRANQUIL.IT
 11    3 HTTP/srvwapt.ad.tranquil.it@AD.TRANQUIL.IT
 12    3 HTTP/srvwapt.ad.tranquil.it@AD.TRANQUIL.IT
ktutil: quit
[root@srvwapt.ad.tranq ~]# kinit -k -t /etc/nginx/http-krb5.keytab srvwapt\$@AD.TRANQUIL.IT
[root@srvwapt.ad.tranq ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: srvwapt$@AD.TRANQUIL.IT

Valid starting       Expires              Service principal
05/02/2021 19:06:05  06/02/2021 05:06:05  krbtgt/AD.TRANQUIL.IT@AD.TRANQUIL.IT
  renew until 06/02/2021 19:06:05

8.2.4.8. Tentative d’authentification avec curl¶

Sur la machine linux.

[root@srvwapt.ad.tranq ~]# kdestroy
[root@srvwapt.ad.tranq ~]# kinit sfonteneau
Password for sfonteneau@AD.TRANQUIL.IT:
[root@srvwapt.ad.tranq ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: sfonteneau@AD.TRANQUIL.IT

Valid starting       Expires              Service principal
05/02/2021 19:10:42  06/02/2021 05:10:42  krbtgt/AD.TRANQUIL.IT@AD.TRANQUIL.IT
  renew until 06/02/2021 19:10:39

root@srvwapt.ad.tranq ~]# curl -v --negotiate -u : https://srvwapt.ad.tranquil.it/api/v3/add_host_kerberos -k
* Expire in 0 ms for 6 (transfer 0x563dece09f90)
* Uses proxy env variable no_proxy == 'localhost,127.0.01/8,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,ad.tranquil.it'
* Expire in 1 ms for 1 (transfer 0x563dece09f90)
...
{"success":true,"msg":"Authentication OK","result":{"auth_result":{"auth_method":"kerb","user":"sfonteneau","auth_date":"2024-11-04T16:53:03.817821","with2fa":false},"server_uuid":"7j54647e-1b54-11ea-bcbe-cae466b691e5","version":"2.6.0","server_domain":"ad.tranquil.it","edition":"enterprise","user_acls":{},"token":null},"request_time":0.006450653076171875}

8.2.4.9. Vérification de la réussite de l’obtention d’un ticket Kerberos¶

Attention

Exécutez toujours les commandes dans le compte système (voir le point précédent) !

klist purge
klist get http/srvwapt.ad.mydomain.lan

Vous devez obtenir (dans votre langue) :

C:\Windows\System32>klist get http/srvwapt.ad.mydomain.lan

LogonId est 0:0x13794d
Un ticket pour http/srvwapt.ad.mydomain.lan a été récupéré.

Tickets mis en cache : (2)

#0> Client : sfonteneau @ AD.MYDOMAIN.LAN
  Serveur : krbtgt/AD.MYDOMAIN.LAN @ AD.MYDOMAIN.LAN
  Type de chiffrement KerbTicket : AES-256-CTS-HMAC-SHA1-96
  Indicateurs de tickets 0x40e00000 -> forwardable renewable initial pre_authent
  Heure de démarrage : 2/4/2021 15:51:07 (Local)
  Heure de fin :   2/5/2021 1:51:07 (Local)
  Heure de renouvellement : 2/11/2021 15:51:07 (Local)
  Type de clé de session : AES-256-CTS-HMAC-SHA1-96
  Indicateurs de cache : 0x1 -> PRIMARY
  KDC appelé : srvads.AD.MYDOMAIN.LAN

#1> Client : sfonteneau @ AD.MYDOMAIN.LAN
  Serveur : http/srvwapt.AD.MYDOMAIN.LAN @ AD.MYDOMAIN.LAN
  Type de chiffrement KerbTicket : AES-256-CTS-HMAC-SHA1-96
  Indicateurs de tickets 0x40a80000 -> forwardable renewable pre_authent 0x80000
  Heure de démarrage : 2/4/2021 15:51:07 (Local)
  Heure de fin : 2/5/2021 1:51:07 (Local)
  Heure de renouvellement : 2/11/2021 15:51:07 (Local)
  Type de clé de session : AES-256-CTS-HMAC-SHA1-96
  Indicateurs de cache : 0
  KDC appelé : srvads.AD.MYDOMAIN.LAN

Si cela ne fonctionne pas, vérifier dans votre Active Directory que l’attribut serviceprincipalname sur le compte de l’ordinateur du Serveur WAPT a cette valeur : HTTP/srvwapt.mydomain.lan.

8.2.4.10. Vérifiez qu’il fonctionne avec Firefox¶

Note

Vous devez d’abord configurer Firefox pour l’authentification kerberos.

Tapez about:config dans la barre d’URL de votre Firefox.
Editez network.negotiate-auth.trusted-uris, et ajoutez l’url du serveur wapt : srvwapt.mydomain.lan.
Vous pouvez maintenant visiter l’url : https://srvwapt.mydomain.lan/add_host_kerberos.
Si l’authentification ne fonctionne pas, le Serveur WAPT renvoie un message d’erreur 403.

8.2.4.11. En cas d’erreur lors d’un des contrôles précédents¶

Supprimez le compte de la machine de l’Active Directory.
Supprimez le fichier /etc/nginx/http-krb5.keytab.
Redémarrez la machine avec laquelle vous effectuez le test et exécutez à nouveau le processus de création de la keytab.

Note

Il est important de redémarrer la machine pour purger les tickets kerberos précédemment obtenus par la machine.
Pour éviter le redémarrage, vous pouvez également exécuter la commande « klist purge » en tant que SYSTEM.

8.3. Activation de la vérification du certificat SSL / TLS¶

Lors de l’exécution du script de post-configuration du Serveur WAPT, le script générera un certificat auto-signé afin d’activer les communications HTTPS.

L’Agent WAPT vérifie le certificat du serveur HTTPS en fonction de la valeur verify_cert de la section [global] dans C:\Program Files (x86)\wapt\wapt-get.ini.

Options pour `verify_cert`¶
Options pour `verify_cert`	Fonctionnement de l’Agent WAPT
`verify_cert` = 0	l’Agent WAPT ne vérifiera pas le certificat HTTPS du Serveur WAPT.
`verify_cert` = 1	l’Agent WAPT vérifiera le certificat HTTPS du Serveur WAPT à l’aide du paquet de certificats `C:\Program Files (x86)\wapt\lib\site-packages\certifi\cacert.pem`
`verify_cert` = C:\Program Files (x86)\wapt\ssl\srvwapt.mydomain.lan.crt	l’Agent WAPT vérifiera le certificat HTTPS du Serveur WAPT avec le groupe de certificats `C:\Program Files (x86)\wapt\ssl\srvwapt.mydomain.lan.crt`

Indication

Pour activer rapidement et facilement la vérification du certificat HTTPS, vous pouvez utiliser la méthode Pinning.

8.3.1. Épingler le certificat¶

L”épinglage de certificat consiste à vérifier le certificat SSL/ TLS à l’aide de la définition d’un paquet bien défini et restrictif.

Indication

Cette méthode est la plus simple lorsqu’on utilise un certificat auto-signé.

Pour cela, vous devez lancer les commandes suivantes dans le shell Windows cmd.exe (avec des privilèges élevés si UAC est actif).

Si vous avez déjà un shell Windows cmd.exe ouvert, fermez-le et ouvrez un nouveau shell afin de prendre en compte les variables d’environnement mises à jour :

wapt-get enable-check-certificate
wapt-get restart-waptservice

Validez le certificat avec wapt-get update

Lorsque vous avez exécuté la commande update, assurez-vous que tout s’est bien passé, et en cas de doute, vérifiez Problème lors du enable-check-certificate.

Attention

Si wapt-get enable-check-certificate renvoie une erreur, supprimez le .crt de même nom sur C:\Program Files (x86)\wapt\ssl\server

Note

La commande enable-check-certificate télécharge le certificat srvwapt.mydomain.lan.crt dans le dossier C:\Program Files (x86)\WAPT\ssl\server.
Il modifie ensuite le fichier wapt-get.ini pour spécifier la valeur verify_cert = C:\Program Files (x86)\wapt\ssl\server\srvwapt.mydomain.lan.crt.
L’Agent WAPT va maintenant vérifier les certificats en utilisant le certificat épinglé.

Attention

Si vous utilisez la méthode d”épinglage de certificat, n’oubliez pas de SAUVEGARDER le dossier /opt/wapt/waptserver/ssl sur votre Serveur WAPT.

Le fichier devra être restauré sur votre Serveur WAPT si vous migrez ou mettez à niveau votre Serveur WAPT, si vous voulez que les Agents WAPT puissent continuer à établir des connexions HTTPS de confiance.

8.3.2. Comment utiliser un certificat commercial ou des certificats fournis par votre organisation ?¶

Si la méthode d’épinglage ne vous convient pas, vous pouvez remplacer le certificat auto-signé généré lors de l’installation de WAPT.

Remplacez l’ancien certificat par le nouveau dans le dossier /opt/wapt/waptserver/ssl/ (linux) ou c:\wapt\waptserver\ssl\ (windows).

La nouvelle paire de clés doit être au format PEM encodé en Base64.

Note

Cas particulier où votre certificat a été signé par une Autorité de Certification interne

Les certificats émis par une Autorité de certification interne doivent avoir la chaîne de certificats complète de l” Autorité de certification.

Vous pouvez ajouter manuellement la chaîne de certificats de l’autorité de certification au certificat qui sera utilisé par Nginx.

Exemple : echo srvwapt.mydomain.lan.crt ca.crt > cert.pem

Pour les serveurs Linux, il est également nécessaire de réinitialiser les ACLs, si vous êtes avec un OS basé sur Redhat avec selinux, veuillez fixer les droits avec restorecon :

chown root:www-data /opt/wapt/waptserver/ssl/*.pem

chown root:nginx /opt/wapt/waptserver/ssl/*.pem
restorecon -v -R /opt/wapt/waptserver/ssl/

Redémarrez Nginx pour prendre en compte les nouveaux certificats.

systemctl restart nginx

net stop waptnginx
net start waptnginx

8.3.2.1. Configuration de l’Agent WAPT¶

Pour un certificat commercial, vous pouvez définir verify_cert = 1 dans wapt-get.ini.

Pour un certificat émis par une autorité de certification interne, vous devez placer le certificat dans le dossier C:\Program Files (x86)\wapt\ssl\server\ca.crt et spécifier le chemin de la CA avec verify_cert dans le fichier :wapt-get.ini de l’Agent WAPT.

Pour appliquer la nouvelle configuration à l’ensemble de votre flotte :

Régénérer un Agent WAPT avec les paramètres appropriés.
Utilisation du paquet WAPT pour modifier wapt-get.ini et pousser le certificat.

8.3.3. Vérification du certificat dans la Console WAPT¶

Lorsque la Console WAPT démarre pour la première fois, elle lit le contenu du fichier C:\Program Files (x86)WAPT\wapt-get.ini et elle construit son fichier de configuration C:\Usersadmin\AppData\Local\waptconsole\waptconsole.ini.

Ceci définit correctement l’attribut verify_cert pour la communication HTTPS entre la Console WAPT et le Serveur WAPT.

8.4. Configuration de l’authentification des utilisateurs par rapport à l’Active Directory ¶

Par défaut, le Serveur WAPT est configuré avec un seul compte SuperAdmin dont le mot de passe est défini lors de la post-configuration initiale.

Sur les réseaux de grande taille et soucieux de la sécurité, le compte SuperAdmin ne doit pas être utilisé, car il ne permet pas d’assurer la traçabilité nécessaire des actions administratives effectuées sur les actifs du réseau.

Il est donc nécessaire de configurer l’authentification par rapport à l’Active Directory pour les utilisateurs de la Console WAPT ; cela permettra d’utiliser des comptes nommés pour les tâches.

Note

L’authentification Active Directory est utilisée pour authentifier l’accès à l’inventaire via la Console WAPT.
Cependant, toutes les actions sur les appareils distants équipés du WAPT sont basées sur des signatures X.509, donc un Administrateur aura besoin à la fois d’une connexion Active Directory ET d’une clé privée dont le certificat est reconnu par les appareils distants pour gérer sa base installée d’appareils utilisant WAPT.
Seul le compte SuperAdmin et les membres du groupe de sécurité Active Directory waptadmins seront autorisés à télécharger des paquets sur le dépôt principal (mode d’authentification par login et mot de passe).

8.4.1. Activation de l’authentification Active Directory¶

Avertissement

Nous recommandons fortement d’utiliser l’authentification Kerberos plutôt que LDAP. Il est toutefois possible de configurer une connexion LDAP sécurisée.

Pour activer l’authentification du Serveur WAPT sur Active Directory, configurez le fichier waptserver.ini comme suit.

Note

Le fichier de configuration du Serveur WAPT sur les systèmes GNU/ Linux et macOS se trouve dans /opt/wapt/conf/waptserver.ini ou dans /opt/wapt/waptserver/waptserver.ini.

Le fichier de configuration du Serveur WAPT sur les systèmes Windows se trouve dans C:\wapt\conf\waptserver.ini.

8.4.1.1. Le plus sécurisé : LDAP SASL Bind over GSSAPI¶

Pré-requis réseau : DNS (53 TDP), Kerberos (88 TDP), LDAP/CLDAP (389 TDP/UDP) du Serveur WAPT au Contrôleur de Domaine.

#waptserver.ini

wapt_admin_group=waptadmins      # parameter wapt_admin_group_dn is deprecated since WAPT 2.6
ad_domain_name=mydomain.lan

Vous devez supprimer toutes les propriétés commençant par « ldap_* » si elles existent.

Maintenant vous pouvez configurer le fichier /etc/krb5.conf comme suit (Royaume Kerberos en MAJUSCULES obligatoirement):

[libdefaults]
  default_realm = MYDOMAIN.LAN
  dns_lookup_kdc = true
  dns_lookup_realm = true

Si le Lookup DNS ne fonctionne pas, vous pouvez configurer le fichier comme suit : (Royaume Kerberos en MAJUSCULES obligatoirement).

[libdefaults]
  default_realm = MYDOMAIN.LAN
  dns_lookup_kdc = false
  dns_lookup_realm = false
[realms]
  MYDOMAIN.LAN = {
  kdc = 192.168.1.13        # KDC IP equals to Domain Controller IP
  kdc = 192.168.1.12
  }

8.4.1.2. Connexion LDAPS¶

Cette méthode est moins sécurisée que LDAP SASL Bind over GSSAPI

Pré-requis réseau : DNS (53 TDP), LDAP (389 TDP) du Serveur WAPT au Contrôleur de Domaine.

#waptserver.ini

wapt_admin_group=waptadmins      # parameter wapt_admin_group_dn is deprecated since WAPT 2.6
ldap_auth_server=ldaps://ldapserver.mydomain.lan

Options d’authentification disponibles¶
Options (Valeur par défaut)	Description	Exemple
`wapt_admin_group` (défaut [])	Définit le sAMAccountName du groupe d’utilisateurs Active Directory autorisé à se connecter à la Console WAPT, c’est une liste qui peut contenir plusieurs groupes. Vous pouvez utiliser cette option plutôt que `wapt_admin_group_dn`, mais NE PAS UTILISER les deux attributs en même temps.	wapt_admin_group = waptadmins, wapttech
`ldap_auth_server` (défaut `None`)	Définit le serveur d’authentification LDAP. Si non spécifié, une requête cldap sera utilisée avec l’option ad_domain_name pour trouver le meilleur contrôleur de domaine basé sur les Sites et Services de l’Active Directory.	ldap_auth_server = srvads.mydomain.lan
`ldap_auth_base_dn` (défaut `None`)	Définit le base DN pour l’authentification LDAP. Si non spécifié, la racine sera utilisée	ldap_auth_base_dn = dc=domain,dc=lan
`ad_domain_name` (`None` par défaut)	Définit le nom de domaine.	ad_domain_name = mydomain.lan

Redémarrer le service waptserver.

8.4.2. Activer le Single Sign On (SSO) pour la Console WAPT et le selfservice¶

Avertissement

Cette configuration n’est disponible que pour les serveurs sous Linux : Red Hat and its derivatives, Debian and its derivatives ou Ubuntu.

Vous pouvez utiliser Kerberos pour vous authentifier sur la waptconsole et le selfservice. De cette manière, les utilisateurs n’ont pas besoin d’entrer leur mot de passe.

Il n’est pas nécessaire d’enregistrer l’Agent WAPT en utilisant kerberos pour utiliser le SSO kerberos avec la Console WAPT et avec le Self-Service.

8.4.2.1. Préparer le Serveur WAPT pour Kerberos Single Sign On¶

Attention

Pour activer Kerberos sur le serveur WAPT avec l’option use_kerberos = True, lancer le script de postconf du serveur WAPT.

/opt/wapt/waptserver/scripts/postconf.sh

Veuillez consulter la documentation sur la configuration de kerberos pour l’authentification au préalable.

Si vous ne souhaitez pas utiliser Kerberos pour l’enregistrement des clients, mettre l’option allow_unauthenticated_registration` à True`.

Enfin, redémarrez les services waptserver et wapttasks.

systemctl restart waptserver wapttasks

Vous devrez modifier waptserver.ini.

Ensuite, vous devrez ajouter ces options dans le fichier waptserver.ini :
```
ldap_account_service_login = wapt-ldap@ad.tranquil.it
ldap_account_service_password = PASSWORD
ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn = dc=mydomain,dc=lan
use_kerberos = True
```
Les options ldap_account_service_login et ldap_account_service_password nécessitent un compte utilisateur dans votre Active Directory.

Il n’est pas nécessaire que le compte de service ait des droits élevés, seulement des droits de lecture sur les groupes et les membres.
Puis redémarrez les services sur le Serveur WAPT :
```
systemctl restart waptserver wapttasks
```

8.4.2.2. Configuration de l’Agent WAPT¶

Du côté du client, vous allez devoir vous assurer que ces 2 options sont définies dans wapt-get.ini de l’Agent WAPT :

service_auth_type = waptserver-ldap
use_kerberos = True

Il est possible de faire des changements dans wapt-get.ini manuellement ou en déployant un paquet WAPT avec les nouveaux paramètres de configuration.

Un paquet d’exemple est disponible dans le dépôt Tranquil IT.

Avec cette configuration, vous pouvez lancer votre Console WAPT ou votre selfservice sans demander de mot de passe.

Pour que cette fonctionnalité fonctionne, l’Active Directory doit être disponible.

Note

La Console WAPT continuera à vous demander un login/mot de passe : c’est tout à fait normal, de cette façon vous pouvez utiliser un autre utilisateur que votre utilisateur actuel dans votre session Windows.

Sinon, il vous suffit de mettre votre login et de cliquer sur OK.

8.4.3. Activez le support SSL/ TLS pour les connexions LDAP dans le Contrôleur de Domaine Active Directory¶

Par défaut, l’authentification sur Active Directory repose sur LDAP SSL (port 636 par défaut).

SSL/ TLS n’est pas activé par défaut sur Microsoft Active Directory tant qu’un certificat SSL n’a pas été configuré pour le contrôleur de domaine.

Note

Le Serveur WAPT utilise les paquets d’autorité de certification du système d’exploitation (Red Hat and its derivatives) pour valider la connexion SSL/ TLS à Active Directory.

Si le certificat Active Directory est auto-signé ou a été signé par une autorité de certification interne, vous devrez ajouter ces certificats au magasin de certificats.

Ajouter un Autorité de Certification dans le dossier /etc/pki/ca-trust/source/anchors/ et mettez à jour le magasin des CA.

cp cainterne.crt /usr/local/share/ca-certificates/cainterne.crt
update-ca-certificates

cp cainterne.crt /etc/pki/ca-trust/source/anchors/cainterne.crt
update-ca-trust

certutil -addstore -f "ROOT" cainterne.crt

Une fois que vous avez configuré LDAP SSL/ TLS sur votre Active Directory (veuillez vous référer à la documentation de Microsoft pour cela), vous pouvez activer le support de la sécurité SSL/TLS pour AD dans waptserver.ini.

ldap_auth_ssl_enabled = True

Redémarrer le service waptserver.

8.5. Configuration de l’authentification par certificat côté client ¶

Si votre entreprise a besoin d’un Serveur WAPT ouvert sur Internet, il peut être sécurisé grâce à l’authentification par certificat côté client.

Cette configuration restreint la visibilité du Serveur WAPT aux seuls clients enregistrés. Cela se fait en s’appuyant sur la clé privée de l’Agent WAPT générée lors de l’enregistrement. Elle fonctionne comme suit :

L’Agent WAPT envoie un CSR au Serveur WAPT qui le signe et le renvoie à l’Agent WAPT.
Grâce au certificat signé, l’Agent peut accéder aux parties protégées du serveur Web Nginx.

Note

Nous recommandons fortement d’activer l’enregistrement Kerberos ou par login/mot de passe dans la post-configuration du Serveur WAPT.

Avertissement

Toutes les actions sont à mener sur le Serveur WAPT

8.5.1. Activation de l’authentification des certificats côté client sur le Serveur WAPT¶

Avertissement

Pour Linux, vérifiez si le lien symbolique dans sites-enabled existe :

cd /etc/nginx/sites-enabled/
find . -maxdepth 1 -type l -ls

Le résultat escompté devrait être :

269091      0 lrwxrwxrwx   1 root     root           36 juil. 22 15:51 ./wapt.conf -> /etc/nginx/sites-available/wapt.conf

Sinon, utilisez la commande suivante :

ln -s /etc/nginx/sites-available/wapt.conf ./wapt.conf

Pour activer l’authentification, vous devez ajouter ces paramètres dans le fichier de configuration du Serveur WAPT dans la section option :

use_ssl_client_auth = True

Relancez le script de post-configuration.

Attention

Attention, à la date du 2025-02-14, WAPT ne supporte pas les CRL, ce qui signifie que lorsque vous supprimez une machine dans la Console WAPT, la machine aura toujours accès au dépôt WAPT.

WAPTDeploy ne peut pas utiliser le https pour récupérer l’Agent WAPT, vous devrez ajouter cette section dans le fichier :

server {
  listen                      80;
  listen                      [::]:80;
  server_name                 _;

  location ~ ^/(wapt/waptsetup-tis.exe|wapt/waptagent.exe|wapt/waptdeploy.exe)$ {
      add_header Cache-Control "store, no-cache, must-revalidate, post-check=0, pre-check=0";
      add_header Pragma "no-cache";
      root "/var/www";
  }

  return 301                  https://$host$request_uri;
}