Renforcer la sécurité de votre installation WAPT

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

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.

Configuration du pare-feu pour le serveur WAPT sur Debian / Ubuntu

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

Configuration du pare-feu pour le serveur WAPT sur RedHat / CentOS

• 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

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 du dispositif.

Installation des composants kerberos et configuration du fichier krb5.conf

Debian / UbuntuCentOS / RedHat

apt install krb5-user msktutil libnginx-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 24 -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.

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

Debian / UbuntuCentOS / RedHat

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

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.

Cas particuliers d’utilisation

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.

Debian / UbuntuCentOS / RedHat

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

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.

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

Débugger les problèmes avec les kerberos

Attention

• L’adresse du serveur 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.

Avez-vous redémarré nginx correctement ?

systemctl restart nginx

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

Le mode kerberos est-il actif sur mon agent ?

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

Le mode Kerberos est-il actif sur mon serveur ?

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.

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

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

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

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/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)
 ...
* Expire in 0 ms for 1 (transfer 0x563dece09f90)
* Expire in 0 ms for 1 (transfer 0x563dece09f90)
*   Trying 192.168.149.37...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x563dece09f90)
* Connected to srvwapt.ad.tranquil.it (192.168.149.37) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1 Server certificate:
*  subject: C=FR; ST=PDLL; L=Saint Sebastien sur Loire; O=Tranquil IT Systems; OU=TIS; CN=srvwapt.ad.tranquil.it; name=PKI TIS; emailAddress=technique@tranquil.it
*  start date: Aug 3 12:48:03 2017 GMT
*  expire date: Aug 1 12:48:03 2027 GMT
*  issuer: C=FR; ST=PDLL; L=Saint Sebastien sur Loire; O=Tranquil IT Systems; OU=TIS; CN=Tranquil IT Systems CA; name=PKI TIS; emailAddress=technique@tranquil.it
*  SSL certificate verify ok.
> GET /add_host_kerberos HTTP/1.1
> Host: srvwapt.ad.tranquil.it
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Server: nginx
< Date: Fri, 05 Feb 2021 18:08:38 GMT
< Content-Type: text/html
< Content-Length: 188
< Connection: keep-alive
< WWW-Authenticate: Negotiate
< WWW-Authenticate: Basic realm=""
<
* Ignoring the response-body
* Connection #0 to host srvwapt.ad.tranquil.it left intact
* Issue another request to this URL: 'https://srvwapt.ad.tranquil.it/add_host_kerberos'
* 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'
* Found bundle for host srvwapt.ad.tranquil.it: 0x563dece07590 [can pipeline]
* Could pipeline, but not asked to!
* Re-using existing connection! (#0) with host srvwapt.ad.tranquil.it
* Connected to srvwapt.ad.tranquil.it (192.168.149.37) port 443 (#0)
* Expire in 0 ms for 6 (transfer 0x563dece09f90)
* Server auth using Negotiate with user ''
> GET /add_host_kerberos HTTP/1.1
> Host: srvwapt.ad.tranquil.it
> Authorization: Negotiate IIGagYGKwYBBQUCoIIGXjCCBlqgDTALBgkqhkiG9xIBAgKiggZHBIIGQ2CCBj8GCSqGSIb3EgECAgEAboIGLjCCBiqgAwIBBaEDAgEOogcDBQAgAAAAo4IFOmGCBTYwggUyoAMCAQWhEBsOQUQuVFJBTlFVSUwuSVSiKTAnoAMCAQOhIDAeGwRIVFRQGxZzcnZ3YXB0LmFkLnRyYW5xdWlsLml0o4IE7DCCBOigAwIBEqEDAgEDooIE2gSCBNac76E6ITct2DXZXMxVNKO5cvgXwU6F9LpnN7Zf6M2AEhvnDAaeD5VOqq/+lGapoxK1hCC62Mnye9zF4SzOEKBDLPD77KJp2xbW227lc5ZF/22wGXn8n6Sw1xndf1brq1mSEUo0TzpFUfY1wNoRDaw7WUNhQK2nbTTeMrsiiPACuQtG82W0VrZJZ+4z1Gq3ZFTLYUrlC010S1T8pNRzCLFRb47Q15B1f7rPAqaZLO/OBq9EQd+i/2Mfp8XWy46gGRtezTk8Dya+SH3henhB+L7G4ew0c3MKxFRkv0nXQ65qPAXWyogbivI/ReekU1anHLnGfDyfeBw2QUM8t2kEEcSBmNKfrQ1U/u1jnlRZJ1o067PiziZsH7w/zGpe7uhOa8a4RKYu1LeJEuU+CKrufulQWKuqdiwIBdq9ApoQqduCbNsE9ihH1srL3RYh9XdQ4Unx51eo49nZQA+c2Aj4JvCafbY/jeRBw6SNYCrfGETN1mXytjLRyVBtJlch7djBGUAYaH1HGNfEVt+VnCW4O9OoqgC0M++u6d7Ci5w494ZseNXnF7RBKr01aVEt0231geGglNvTyXzWJ3IGUOrhBnaTTSLAzai/arutH6c3CzLb+xPMAOUtCIup0M43SR0DC7gJ/xZ3BZyKHF6b3p3tAWiByat2XNMxfMbgjaiv7oLCNEIAga0IgTg5f0nlahTI9323vfIH8aLNNVYVJeFKNGX1ord0YpJ3RLDshNBnoDTPyCKnXcf5nM+tqabshzatuTP6PfFkal6evwZ/QXiFQAezmRut+hfXtoVch8LHC0OIaloDUk1eHlFbAqQ98OaE3SZ8Fx4m8Nw3JgQ0E+zXPt8DJCnNY4YV4j3+9b1093XhsJRyP97qEFazUGFhfg7/PzqFnxSHtikXjCnjtzfuHLePMWn0HKFbL/hEMmAnfZ15JiBgfBi82OXv3rCui+GKT/ZsjUFsgR8tCUJ58/gXBu9J/gY1R46CvWTnl03+2JHQyomm6k0XnAU+s2hX+n/QcKbIjT7ew/f/UuT0J1YV+bQ8MMTpQqbau4f5sVaembIB7hTVyttpfbBEqCOVk39xZ/r8b9CMpmukShPgeJI0x353i7bO9/mBkchFaeyOc45jA7Z4iJ3IHNiWLaWyYLktH/1N9/dXas8/CoZK0UsKjm9+xlkFFSP18CFHijILlIc1sTdMnAil/jwqQl1W2WRnBlt8r/yE56EDR/i8VkCMHT5XsiiMCHm4LldkmDnIo/+GgHTG+3Z78Pkq939rMati/gzd9geYM8aUuYwJpcb53YsjWvJD1gDEHEwS3K1MYxbyy9eiODCOCgvIeKmVPouNrugXs4TX6PJsCQDtzusSWxmZY4820HxmJkNT1lG5ZkktyHGsMjHnBLlSz5Ex01CnxwjVOHmSOrYfJnTzqYP5AF648wHbQ9ArikXg0pBQVQ832ChwR18N3jH5xeUljq3fjGzxA27YD6nTg6SV7hdcDkXmJvjUbIwGjrtfZU/b93cbD4oaOWlbPViBpwLZ+TTCkeGAxo3eBicENHSK81EIJYMBfEWTTsjYPEPsl5BK7IFcqArfEWG6HQDw3bOfYAB1ZJb0zSbhyD/rKnRmtSke/eWIAjYaeHDX0qYMruJCuI2lYofHtFwMEKSB1jCB06ADAgESooHLBIHIDVUTdDas6nA0obxBuM2bQiZ0ZUPhAVGMoTniuCmBXU/mFRAsD029zDjfl0nzeFsPdC4UBERcc8Vh4r3YeZIxUxzn5tXCW4oFypYi5kHAdx6Zd4GkZcEpzAhRF7JwSylerZiCF+fnSIiI5wdDG56PMFf46ZnT0gSnYiqYGWCv7y1pdc3P9VViECBNjpGSc9sn9fZ2HFTGaiuGLl1G8Jyjkymn2cilE0MOBpYuFUXnvyYErT5jajyKOUMexTCS1FxneLNUK6jBlWE=
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Fri, 05 Feb 2021 18:08:38 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 38
< Connection: keep-alive
< WWW-Authenticate: Negotiate oYG3MIG0oAMKAQChCwYJKoZIhvcSAQICooGfBIGcYIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvQoZWpMIm8fS3ZrHmI96KuJ4AnP1ztIwCCXGJy3HuI2+IQ4cccbhf2WLdbxjaf82eOb4MQDZDq8F/x0oFJX6n4DnhPZxrq/RnjwkoTnik7R8MJkKRuvYncBfTGBIHvTJktq6+j9pHqmBDH5D5L8A
< WWW-Authenticate: Basic realm=""
< Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
<
* Closing connection 0
kerberos connection seems to be working

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.

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 renvoie un message d’erreur 403.

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.

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.

É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 si vous migrez ou mettez à niveau votre serveur WAPT, si vous voulez que les agents WAPT puissent continuer à établir des connexions HTTPS de confiance.

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 :

Debian / UbuntuCentOS / RedHat

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

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

LinuxWindows:

systemctl restart nginx

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 du certificat 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.

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.

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 étendus et sécurisés, ce compte SuperAdmin ne doit pas être utilisé car il ne peut pas fournir la traçabilité nécessaire aux actions administratives effectuées sur le 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).

Activation de l’authentification Active Directory

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

#waptserver.ini

wapt_admin_group=waptadmins
ldap_auth_server=srvads.mydomain.lan
ldap_auth_base_dn=DC=mydomain,DC=lan
ldap_auth_ssl_enabled=False

Options d’authentification disponibles

Options / Valeur par défaut	Description	Exemple
wapt_admin_group_dn = (défaut [])	DN LDAP du groupe d’utilisateurs Active Directory autorisé à se connecter à la console WAPT.	wapt_admin_group_dn = CN=waptadmins,OU=groups,DC=ad,DC=mydomain,DC=lan
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.	ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn (défaut None)	Définit le DN de base de l’authentification LDAP.	ldap_auth_base_dn = dc=domain,dc=lan
ldap_auth_ssl_enabled (défaut True)	Définit l’authentification SSL sur les connexions LDAP.	ldap_auth_ssl_enabled = False
verify_cert_ldap (défaut True)	Vérifie le certificat SSL pour les connexions LDAP, à moins que ldap_auth_ssl_enabled soit à False (sinon il ne fera rien).	verify_cert_ldap = False

• Redémarrer le service waptserver.

Avertissement

Pour Microsoft Active Directory, Microsoft a annoncé que l’authentification SimpleBind sur MS-AD sans SSL/TLS sera bloquée par défaut à partir d’avril 2020. Si vous n’avez pas de certificat installé, vous devrez modifier une clé de registre pour que l’authentification fonctionne.

Note

Par défaut Samba-AD ne permet pas l’authentification SimpleBind sans SSL/TLS. Si vous ne disposez pas d’un certificat valide, vous devrez modifier le paramètre ldap server require strong auth dans /etc/samba/smb.conf. Pour plus d’informations, vous pouvez consulter la documentation de Tranquil IT sur https://dev.tranquil.it/samba/en/index.html.

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 : CentOS, Debian ou Ubuntu.

You can use Kerberos to authenticate yourself on the waptconsole and the selfservice. This way, users do not need to enter their password.

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.

Préparer le serveur pour Kerberos Single Sign On

Attention

Pour activer Kerberos sur le serveur WAPT avec l’option use_kerberos = True, lancez le script WAPT Server postconf.

/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

Il existe 3 méthodes pour configurer votre serveur WAPT avec Kerberos et l’authentification LDAP.

Pour chacun d’entre eux, vous devrez modifier le fichier waptserver.ini.

1. La première méthode est la moins sécurisée .

Cette méthode ne vérifie pas le certificat LDAP et n’utilise pas de port sécurisé pour contacter le Serveur WAPT.

ldap_auth_ssl_enabled = False
verify_cert_ldap = False

En effet, ldap_auth_ssl_enabled=False n’essaiera pas de requêter l’Active Directory avec le protocole LDAPS.

L’option verify_cert_ldap=False est définie si vous n’utilisez pas SSL/TLS support.

Indication

Si votre serveur Active Directory est un Samba-AD et que vous avez cette option dans le waptserver.ini, alors le serveur Samba-AD refusera la connexion.

ldap_auth_ssl_enabled = False

Par défaut Samba-AD ne permet pas l’authentification SimpleBind sans SSL/TLS.

Si vous n’avez pas de certificat valide, vous devrez modifier le paramètre ldap server require strong auth dans /etc/samba/smb.conf.

Pour plus d’informations, vous pouvez consulter la documentation de Tranquil IT sur https://dev.tranquil.it/samba/fr/index.html.

2. La deuxième façon plus sûre mais pas parfaite.

Cette méthode permet l’authentification SSL sans vérifier le certificat.

ldap_auth_ssl_enabled = True
verify_cert_ldap = False

Le serveur WAPT essaiera d’utiliser le protocole LDAPS mais sans vérification de certificat pour contacter Active Directory.

3. La méthode recommandée est la plus sûre.

ldap_auth_ssl_enabled = True
verify_cert_ldap = True

• Mais pour faire fonctionner cela, vous aller devoir activer le support SSL/TLS.

• 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, juste assez de droits pour lire les groupes et les membres des groupes. En d’autres termes, le serveur WAPT DOIT avoir des droits de lecture sur l’attribut memberof dans l’Active Directory.

• Puis redémarrez les services sur le serveur :

  systemctl restart waptserver wapttasks
  

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 :

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.

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 (CentOS) 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.

Debian / UbuntuCentOS / RedHatWindows

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

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

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

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 post-configuration .

Attention

Attention, à la date du 2024-09-20, 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;
}

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.

Generating a new certificate with the Certificate Authority

Construire une nouvelle paire .pem / .crt.

Note

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.

L”Administrateurs sera autorisé à signer les paquets qui CONTIENNENT un fichier exécutable setup.py (c’est-à-dire les paquets base).

Les personnes ayant le rôle 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.

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:\program files(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.

net stop waptservice && net start waptservice

Si vous voulez déployer les certificats en utilisant WAPT, utilisez un paquet de certificat

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 |date|, les agents WAPT ne vérifient pas les droits ACL.

Pour configurer les ACL dans WAPT, allez dans Outils ‣ Gérer les utilisateurs Wapt et des droits.

Note

Au premier lancement après l’installation du serveur, 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 waptserver.

Le compte SuperAdmin est authentifié en utilisant la valeur de wapt_password dans le fichier de configuration waptserver.ini.

Deux types de comptes sont gérables par ACL, local et Active Directory.

Compte d’utilisateur local

Les utilisateurs locaux sont définis par un fichier .htpasswd.

Configuration du serveur WAPT

Pour utiliser un compte utilisateur local, vous devez créer un fichier nommé waptusers.htpasswd dans le même dossier sur le serveur WAPT contenant le fichier waptserver.ini.

Linux:Windows

touch /opt/wapt/conf/waptusers.htpasswd
chown wapt /opt/wapt/conf/waptusers.htpasswd

• Sur waptserver.ini ajoutez les paramètres htpasswd_path.

htpasswd_path = password file location

Indication

Redémarrer le service waptserver

Création du compte utilisateur

• Dans la fenêtre Droits des utilisateurs WAPT, cliquez sur Nouveau compte.

Il est possible de renommer des comptes en appuyant sur F2 sur la colonne User.

• Sauvegardez en cliquant sur Enregistrer les comptes.

• Pour définir un mot de passe, voir le point Changez le mot de passe.

• Pour définir les droits, consultez la section gérer les droits ACL.

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.

Changer le mot de passe de l’utilisateur

Pour changer le mot de passe du compte sélectionné :

• Faites un clic droit sur le compte ‣ Changer le mot de passe utilisateur sur le serveur Wapt.

• Saisissez le nouveau mot de passe.

Boîte de dialogue permettant de modifier le mot de passe de l’utilisateur dans le fichier htaccess

L’utilisateur local apparaît en gras et la case Mots de passe est cochée.

Utilisateurs WAPT définis comme utilisateurs Active Directory

Pour gérer les utilisateurs WAPT avec votre Active Directory, vous devez activer l”authentification Active Directory.

Après une première connexion réussie, le compte AD apparaîtra automatiquement dans la liste des utilisateurs WAPT.

Blocage des comptes d’utilisateurs locaux

Pour désenregistrer les utilisateurs locaux, faites clic droit sur le compte ‣ Invalider le mot de passe de l’utilisateur sur le serveur WAPT.

Le compte sera bloqué et ne pourra plus gérer quoi que ce soit dans WAPT.

Liste des droits

De nombreux droits et restrictions peuvent être définis pour chaque utilisateur dans la console WAPT.

Liste des droits des utilisateurs

Droit	Description
Admin	Comme SuperAdmin, tous les droits sont accordés sauf Mot de passe.
Voir	Permet de visualiser uniquement les informations sur la console WAPT.
Inscrire machine	Permet d’utiliser les informations d’identification de l’administrateur pour enregistrer manuellement une machine avec le Serveur WAPT.
Désinscrire machine	Permet de supprimer une machine depuis la console WAPT.
Modif machine	Permet de modifier le paquet machine sur la console WAPT.
Modif paquets	Permet de modifier les paquets de base qu’elle est autorisée à modifier.
Modif groupes	Permet de modifier les paquets de groupe sur la console WAPT.
Modif self-service	Permet de modifier les règles de self-service sur la console WAPT.
Modif WUA	Permet de modifier les règles WUA / WSUS sur la console WAPT.
Modif paquets AD OU	Permet de modifier les paquets unit sur la console WAPT.
Modif paquets Profile	Permet de modifier les packages profile sur la console WAPT.
Lancer les instalations	Permet d’appliquer à distance des mises à jour sur son périmètre, si la machine est en statut PENDING.
Actions distantes machine	Permet d’utiliser les outils Windows de Gestion de l’ordinateur avec la console WAPT.
Modifier requêtes	Permet de créer ou modifier des requêtes de rapport.
Lancer requête	Permet de exécuter des rapports SQL existants.
Mot de passe	Définit un utilisateur local

Gestion des droits

Par défaut, le SuperAdmin est l’utilisateur du Certificat CA.

Pour les autres utilisateurs, il est possible d’associer un certificat qui a été généré à partir de la PKI WAPT ou d’une autre CA.

Ces certificats peuvent ou non être des enfants de l’autorité de certification WAPT.

Attention

Si les certificats ne sont pas émis par l’autorité de certification :

• Les paquets mis à jour sont disponibles uniquement sur les ordinateurs où les certificats sont déployés.

• Les ACL sont valides uniquement sur le périmètre des hôtes où le certificat de l’administrateur est déployé.

Associer un certificat à un utilisateur

Indication

Par défaut, aucun certificat n’est défini pour aucun utilisateur (y compris SuperAdmin).

Le compte dans la console WAPT apparaît en italic si aucun certificat n’est associé à l’utilisateur.

Pour associer un certificat à un utilisateur, faites clic droit sur l’utilisateur ‣ Associer un certificat à l’utilisateur.

Ensuite, choisissez le certificat à associer à l’utilisateur.

Ajouter / supprimer des droits

Pour ajouter ou supprimer des droits, sélectionnez la cellule avec clic gauche et cochez-la en appuyant sur la barre d'espace.

Indication

Il est possible d’effectuer une sélection multiple en utilisant les raccourcis clavier control+clic gauche et en appuyant sur la barre d'espace.

Restreindre le périmètre des droits accordés à l’utilisateur

Il est possible d’associer un périmètre à un droit donné à un utilisateur.

Vue

Définition du périmètre autorisé

Périmètre	Description
Tout refuser	Aucun droit de regard n’est autorisé (non coché).
Autoriser sur tout le périmètre	Permet de visualiser à droite tous les agents WAPT.
Autoriser des périmètres spécifiques	La visualisation est autorisée sur le périmètre sélectionné défini comme une liste de certificats.
Autoriser où le certificat d’utilisateur est déployé	La visualisation est autorisée uniquement sur le périmètre où le certificat de l’administrateur est déployé.

Modifier les paquets de groupe

Indication

Tous les paquets de groupe fonctionnent sur le même principe, décrit ci-dessous.

Définition du périmètre autorisé

Périmètre	Description
Interdire tous les paquets	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.
Autoriser des noms de paquets spécifiques	Permet le droit d’édition pour les packages WAPT sélectionnés dans la liste.