Hide navigation sidebar
Hide table of contents sidebar
Skip to content
Quickstart Official documentation Setuphelpers Changelog FAQ
Back to top
View this page
Toggle table of contents sidebar

# 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.

Adaptez la commande à votre contexte.

    sudo msktutil --server srvads.mydomain.lan --create --host srvwapt --computer-name srvwapt -b cn=computers --service HTTP/srvwapt.ad.mydomain.lan --keytab /etc/nginx/http-krb5.keytab --no-reverse-lookups --dont-update-dnshostname  --enctypes 0x18

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  --enctypes 0x18

Avertissement

Le compte ordinateur doit être capable de changer son propre mot de passe (Onglet Sécurité, groupe SELF, permission « Modifier le mot de passe ».

- 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 est intégré dans un environnement Active Directory (AD) global.

Considérations relatives à la sécurité

L’Agence Nationale de la Cybersécurité (ANSSI) constate régulièrement que les compromissions de systèmes d’information (SI) basés sur Active Directory (AD) proviennent souvent de mauvaises pratiques d’administration et d’un cloisonnement insuffisant. Ces atteintes commencent typiquement par des attaques visant les postes de travail. Les attaquants exploitent ensuite les vulnérabilités du SI pour se déplacer latéralement, élever leurs privilèges et finalement prendre le contrôle total de l’AD.

Une fois qu’un pirate informatique a atteint ce niveau de contrôle, il peut créer des portes dérobées persistantes, lui permettant de conserver un accès à long terme au système d’information, y compris aux processus métier et aux données critiques de l’organisation.

Guide de l’administration sécurisée de l’ANSSI.

Le Guide pour une administration sécurisée des systèmes d’information basée sur un annuaire AD traite des défis spécifiques liés à l’administration des environnements AD et fournit des recommandations pour partitionner le SI en zones de confiance. Ce guide complète les recommandations générales de l’ANSSI en matière de sécurité pour une administration sécurisée des SI, indépendamment des technologies utilisées.

#### 8.2.3.2. 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.3. 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.

#### 8.2.3.4. 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

Important

Lorsque vous configurez un certificat (PKI, commercial ou auto-signé), vérifiez toujours sa date d’expiration.

- Si le certificat arrive bientôt à expiration, vous pouvez vous préparer à l’avance en suivant cette procédure.

- Si le certificat a déjà expiré, il n’existe que deux façons de reprendre le contrôle de votre environnement :

  - Utilisation d’objets de stratégie de groupe (GPO) — bien que les GPO aient leurs limites et ne garantissent pas nécessairement la validation complète d’un déploiement réussi.

  - Connecter manuellement un périphérique USB à chaque machine.

  Plus d’informations ici.

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.

Danger

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

Mais Ne jamais épingler un certificat commercial : L’épinglage de certificats commerciaux peut entraîner de graves problèmes de renouvellement.

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èmes lors de l’activation de 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 vous recommandons fortement d’utiliser *Kerberos authentication* au lieu de LDAP. Cependant, il est 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:636

Note

Si votre certificat n’est pas reconnu, vous pouvez modifier le verify_cert à false, dans le `waptserver.ini`.

    verify_cert = False

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` :

      ad_domain_name = mydomain.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 2026-01-30, 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;
    }