Attention : support for WAPT 2.2 ended on March the 3rd 2023.

Please upgrade to the latest supported version

Enhancing the security of your WAPT setup

By default, all WAPT packages are signed with your private key, which already provides a great level of security. However you can further improve the security of WAPT.

To fully secure your WAPT setup; you will want to do the following:

• Enable authenticated registration to filter who is authorized to register the device with the WAPT Server.

• Enable https certificate verification on the WAPT Agents and the WAPT Console to ensure that the WAPT Agents and the WAPT Console are connecting to the correct WAPT Server.

• Configure authentication against Active Directory to allow access to the WAPT Console only to authorized WAPT admins.

• Enable Client-Side Certificate Authentication to only allow authenticated devices to access the WAPT Server (Note: it is especially important if you want to expose your WAPT Server to the outside in a DMZ).

• If you are using the Enterprise version of WAPT and you operate a large fleet with multiple administrators, you may be interested in knowing how to properly configure and apply the ACLs.

Configuring the firewall on the WAPT Server

WAPT Server firewall configuration is essential and should be the first step towards achieving better security in WAPT.

As WAPT aims to be secure by design, only a minimal set of open ports is needed on the WAPT Server compared to other solutions.

You will find in the following documentation firewall tips to improve WAPT security.

Configuring the firewall for WAPT Server on Debian / Ubuntu

By default on Debian Linux, no firewall rule applies.

• Disable ufw and install firewalld instead.

ufw disable
apt update
apt -y install firewalld

• Simply apply this firewalld configuration.

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

Configuring the firewall for WAPT Server on RedHat and derivatives

• Simply apply this firewalld configuration.

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

Configuring kerberos authentication

Note

• Without kerberos authentication, you have to either trust initial registration or enter a password for each workstation on initial registration.

• For more information, visit the documentation on registering a host with the WAPT Server and signing inventory updates.

• The kerberos authentication will be used only when registering the device.

Installing the kerberos components and configuring krb5.conf file

Debian / UbuntuCentOS / RedHat

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

Note

Registering with kerberos is not available with a WAPT Server running on Windows.

Modify the /etc/krb5.conf file and replace all the content with the following 4 lines replacing MYDOMAIN.LAN with your Active Directory domain name (i.e. <MYDOMAIN.LAN>).

Attention

default_realm value MUST be written with ALL CAPS!!

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

Retrieving a service keytab. Use the kinit and klist. You can use an Administrator account or any other account with the delegated right to join a computer to the domain in the proper destination container (by default CN=Computers).

In the shell transcript below, commands are in black and returned text is commented in light gray:

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

If the authentication request is successful, you can then create your HTTP Keytab with the msktutil command.

Be sure to modify the <DOMAIN_CONTROLER> string with the name of your domain controller (eg: 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

Be sure to have properly configured your WAPT Server hostname before running these commands;

In order to double check your hostname, you can run echo $(hostname) and it MUST return the name that will be used by WAPT Agent running on client workstations. If your WAPT server is available from the internet, you should add another servicePrincipalName (SPN) to match with the WAPT public URL.

• Apply the proper access rights to the http-krb5.keytab file.

Debian / UbuntuCentOS / RedHat

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

Post-configuring kerberos for the WAPT Server

You can now use post-configuration script to configure the WAPT Server to use kerberos.

The post-configuration script will configure Nginx and the WAPT Server to use kerberos authentication.

Hint

This post-configuration script MUST be run as root.

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

Kerberos authentication will now be configured.

Special use cases

My WAPT Server does not have access to a writeable Active Directory

• Connect to your Active Directory (Not a RODC).

• Create a computer account srvwapt.

• Add a SPN on the srvwapt$ account.

setspn -A HTTP/srvwapt.mydomain.lan srvwapt

• Create a keytab for this WAPT Server.

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

If the address of your WAPT Server is different from your active directory domain, replace HTTP/srvwapt.mydomain.lan@MYDOMAIN.LAN with HTTP/srvwapt.othername.com@MYDOMAIN.LAN.

• Transfer this file to /etc/nginx/ (with winscp for example).

• Apply the proper access rights to the http-krb5.keytab file.

Debian / UbuntuCentOS / RedHat

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

WAPT Agents only have access to a RODC domain controller

• For RODC, add the srvwapt account to the allowed password group for replication.

• Remember to preload the password of the WAPT Server with the different RODC servers.

You have multiple Active Directory domains with or without relationships

If you have multiple Active Directory domains, you MUST create one keytab per domain by following the procedure above, ex:

• http-krb5-domain1.local.keytab;

• http-krb5-domain2.local.keytab;

• http-krb5-domain3.local.keytab.

You will then have to merge all these keytabs into a 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

Debug problems with the kerberos

Attention

• The WAPT Server address cannot be an IP, Kerberos works well only with DNS.

• In your test, the url used MUST be exactly the same address as the one indicated in C:\Program Files (x86)\wapt\wapt-get.ini.

Did you restart nginx correctly?

systemctl restart nginx

Check the permissions of the http-krb5.keytab file

[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

Is kerberos mode active on my WAPT Agent?

On the Windows host:

• Check in your C:\Program Files (x86)\wapt\wapt-get.ini that the use_kerberos value is True.

[global]
use_kerberos=1

• If you change the value, do not forget to restart the WAPT service.

net stop waptservice
net start waptservice

Is Kerberos mode active on my WAPT Server?

On the Linux host:

• Check in your /opt/wapt/conf/waptserver.ini that the use_kerberos value is True.

[options]
use_kerberos=1

• Check in your /etc/nginx/sites-enabled/wapt.conf that this configuration is present.

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;

  }

• If one of the two configurations is not present, restart the post-configuration and activate kerberos.

Checking that the keytab file contains the correct url

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

Trying to register the host using a system account

To switch to a system account you MUST use the psexe tool from Microsoft: psexe.

• In cmd as an Administrator.

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

• In the new cmd window, check that you are identified as System.

C:\WINDOWS\\system32>whoami

NT AUTHORITY\System

• Run register.

wapt-get register

Trying an authentication with the keytab from your WAPT Server

• On the Linux host.

[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

Attempting an authentication with curl

• On the Linux host.

[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

Verifying that you are successfully obtaining a Kerberos ticket

Attention

Always execute commands in system account (see previous point)!

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

You should get (in your language):

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

If that does not work, check in your Active Directory that the serviceprincipalname attribute on the computer account of the WAPT Server has this value: HTTP/srvwapt.mydomain.lan.

Check that it works with Firefox

Note

You need to first configure Firefox for kerberos authentication.

• Type about:config in the URL bar in your Firefox.

• Edit network.negotiate-auth.trusted-uris, and add the url of the WAPT Server: srvwapt.mydomain.lan.

• You can now visit the url: https://srvwapt.mydomain.lan/add_host_kerberos.

• If the authentication does not work, then the WAPT Server will return a 403 error message.

In case of an error on one of the previous checks

• Delete the host account from the Active Directory.

• Delete the /etc/nginx/http-krb5.keytab file.

• Reboot the host you are testing with and re-run the keytab creation process again.

Note

• It is important to restart the host to purge the kerberos tickets previously obtained by the host.

• To avoid restarting you can also execute the command “klist purge” as SYSTEM.

Activating the verification of the SSL / TLS certificate

When running the WAPT Server post-configuration script, the script will generate a self-signed certificate in order to enable HTTPS communications.

The WAPT Agent checks the WAPT HTTPS Server certificate according to the verify_cert value in section [global] in C:\Program Files (x86)\wapt\wapt-get.ini.

Options for verify_cert

Options for verify_cert	Working principle of the WAPT Agent
verify_cert = 0	the WAPT Agent will not check the WAPT Server HTTPS certificate.
verify_cert = 1	the WAPT Agent will check the WAPT Server HTTPS certificate using the certificate bundle. C:\Program Files (x86)\wapt\lib\site-packages\certifi\cacert.pem
verify_cert = C:\Program Files (x86)\wapt\ssl\srvwapt.mydomain.lan.crt	the WAPT Agent will check the WAPT Server HTTPS certificate with the certificate bundle. C:\Program Files (x86)\wapt\ssl\srvwapt.mydomain.lan.crt

Hint

To quickly and easily enable verification of the HTTPS certificate, you can use the Pinning method.

Pinning the certificate

The pinning of certificate consists of verifying the SSL/ TLS certificate with a well defined and restricted bundle.

Hint

This method is the easiest when using a self-signed certificate.

For this, you need to launch the following commands in the Windows cmd.exe shell (with elevated privileges if UAC is active).

If you already have a Windows cmd.exe shell open, close it and open a new shell so to take into account the updated environment variables:

wapt-get enable-check-certificate
net stop waptservice
net start waptservice

Validate the certificate with wapt-get update

When you have executed the update command, make sure that everything has gone well, and if in doubt check Problems when enabling enable-check-certificate.

Attention

If wapt-get enable-check-certificate returns an error, remove the .crt with same name on C:\Program Files (x86)\wapt\sslserver

Note

• The command enable-check-certificate downloads the certificate srvwapt.mydomain.lan.crt in the folder C:\Program Files (x86)\WAPT\ssl\server.

• It then modifies the file wapt-get.ini to specify the value verify_cert = C:\Program Files (x86)\wapt\ssl\server\srvwapt.mydomain.lan.crt.

• The WAPT Agent will now verify certificates using the pinned certificate.

Attention

If you use the certificate pinning method, BE REMINDED to archive the /opt/wapt/waptserver/ssl folder on your WAPT Server.

The file will have to be restored on your WAPT Server if you migrate or upgrade your WAPT Server, if you want the WAPT Agents to continue to be able to establish trusted HTTPS connections with the WAPT Server.

How to use a commercial certificate or certificates provided by your Organization?

If the pinning method does not suit you, you can replace the self-signed certificate generated during the installation of WAPT.

Replace the old certificate with the new one in the folder /opt/wapt/waptserver/ssl/ (Linux) or C:\wapt\waptserver\ssl\ (Windows).

The new key pair MUST be in PEM encoded Base64 format.

Note

Special case where your certificate has been signed by an internal Certificate Authority

Certificates issued by an internal Certificate Authority MUST have the complete certificate chain of the Certificate Authority.

You can manually add the certificate chain of the Certificate Authority to the certificate that will be used by Nginx.

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

• For Linux servers it is also necessary to reset the ACLs:

Debian / UbuntuCentOS / RedHat

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

• Restart Nginx to take into account the new certificates.

LinuxWindows:

systemctl restart nginx

Configuring the WAPT Agent

For a commercial certificate you can set verify_cert = 1 in wapt-get.ini.

For a certificate issued by an internal Certificate Authority, you MUST place the certificate in the C:\Program Files (x86)\wapt\ssl\server\ca.crt folder and specify the certificate path with verify_cert in the wapt-get.ini file of the WAPT Agent.

To apply the new configuration to your entire fleet:

• Regenerate a WAPT Agent with the appropriate settings.

• Use a WAPT package to modify wapt-get.ini and push the certificate.

Verifying the certificate in the WAPT Console

When the WAPT Console first starts, it reads the content of C:\Program Files (x86)\WAPT\wapt-get.ini and it builds its configuration file C:\Users\admin\AppData\Local\waptconsole\waptconsole.ini.

This properly sets the verify_cert attribute for the HTTPS communication between the WAPT Console and the WAPT Server.

Configuring user authentication against Active Directory

By default, the WAPT Server is configured with a single SuperAdmin account whose password is setup during initial post-configuration.

On large and security-minded networks, the SuperAdmin account should not be used since it cannot provide the necessary traceability for administrative actions that are done on the network assets.

It is thus necessary to configure authentication against the Active Directory for the WAPT Console users; this will allow to use named accounts for tasks.

Note

• Active Directory authentication is used to authenticate access to the inventory via the WAPT Console.

• However, all actions on the WAPT equipped remote devices are based on X.509 signatures, so an Administrator will need both an Active Directory login AND a private key whose certificate is recognized by the remote devices that the Administrator manages using WAPT.

• Only the SuperAdmin account and the members of the Active Directory security group waptadmins will be allowed to upload packages on the main repository (authentication mode by login and password).

Enabling Active Directory authentication

• To enable authentication of the WAPT Server with Active Directory, configure the file waptserver.ini as follows.

Note

The WAPT Server configuration file on GNU/ Linux and macOS systems is found in /opt/wapt/conf/waptserver.ini or in /opt/wapt/waptserver/waptserver.ini.

The WAPT Server configuration file on Windows systems is found in C:\wapt\conf\waptserver.ini.

#waptserver.ini

wapt_admin_group_dn=CN=waptadmins,OU=groupes,OU=tranquilit,DC=mydomain,DC=lan
ldap_auth_server=srvads.mydomain.lan
ldap_auth_base_dn=DC=mydomain,DC=lan
ldap_auth_ssl_enabled=False

Available authentication options

Options (Default Value)	Description	Example
wapt_admin_group_dn = []	LDAP DN of Active Directory User Group allowed to connect to WAPT Console	wapt_admin_group_dn = CN=waptadmins,OU=groups,DC=ad,DC=mydomain,DC=lan
ldap_auth_server = None	Defines LDAP authentication server	ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn = None	Defines LDAP authentication base DN	ldap_auth_base_dn = dc=domain,dc=lan
ldap_auth_ssl_enabled = True	Sets SSL authentication on LDAP connections	ldap_auth_ssl_enabled = False

• Restart waptserver service.

Warning

For Microsoft Active Directory, Microsoft has announced that SimpleBind* authentication on MS-AD without SSL/TLS will be blocked by default from April 2020. If you do not have a certificate installed, you will have to modify a registry key to have authentication working.

Note

By default Samba-AD does not allow SimpleBind authentication without SSL/TLS. If you do not have a valid certificate you will need to modify the ldap server require strong auth parameter in /etc/samba/smb.conf. For more information you may refer to Tranquil IT’s documentation on Samba-AD.

Enabling Single Sign On (SSO) for the WAPT Console and the self-service

Warning

This configuration is only available for WAPT Servers running on WAPT supported Linux distributions.

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

Hint

Is not necessery to use Kerberos for Agent registering in order to use SSO.

Preparing the WAPT Server for Kerberos Single Sign On

Attention

To enable Kerberos on the WAPT Server with use_kerberos = True option, please, refer to Configuring kerberos authentication beforehand.

There are 3 ways to configure your WAPT Server for Kerberos and LDAP authentication.

For each of these methods, you will need to modify the waptserver.ini.

1. The first way is the least secure.

This method does not verify the LDAP certificate nor does it use a secured port to contact the WAPT Server.

ldap_auth_ssl_enabled = False
verify_cert_ldap = False

Indeed, ldap_auth_ssl_enabled = False will not try to query the Active Directory using the LDAPS protocol.

The verify_cert_ldap = False option is set if you do not use SSL/TLS support.

Hint

If your Active Directory Server is a Samba-AD and you have this option in the waptserver.ini, then the Samba-AD server will refuse the connection.

ldap_auth_ssl_enabled = False

By default Samba-AD does not allow SimpleBind authentication without SSL/TLS.

If you do not have a valid certificate you will need to modify the ldap server require strong auth parameter in /etc/samba/smb.conf.

For more information you may refer to Tranquil IT documentation on Samba-AD.

2. The second method is more secure but still not perfect.

The method enables SSL authentication without verifying the certificate.

ldap_auth_ssl_enabled = True
verify_cert_ldap = False

The WAPT Server will try to use by default the LDAPS protocol without verifying the certificate when contacting the Active Directory.

3. The third and recommanded way is the most secure.

ldap_auth_ssl_enabled = True
verify_cert_ldap = True

• To make the method work, you will have to enable the SSL/TLS support.

• Then, you will need to add these options in the 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
  

• Finally, restart services on the WAPT Server:

  systemctl restart waptserver wapttasks
  

Note

The ldap_account_service_login and ldap_account_service_password require a service user account on your Active Directory.

It is not necessary that the service account had elevated right, just enough rights to read groups and group members.

Configuring the WAPT Agent

On the client side, you will have to make sure that theses 2 options are set in the wapt-get.ini of the WAPT Agent:

service_auth_type = waptserver-ldap
use_kerberos = True

It is possible to make changes in wapt-get.ini manually or by deploying a WAPT package with the new configuration settings.

An example package is available from the Tranquil IT repository.

With this configuration, you can launch your WAPT Console or your selfservice without being prompted for a password.

Note

The WAPT Console will continue to ask for a login / password. It is perfectly normal, this way you can use another user than the current user logged in the underlying desktop session.

Otherwise, you just have to put your login and click on OK.

Enabling SSL/ TLS support for the LDAP connection to the Active Directory Domain Controller

By default, authentication on Active Directory relies on LDAP SSL (default port 636).

SSL / TLS is not enabled by default on Microsoft Active Directory until a SSL certificate has been configured for the Domain Controller.

Note

The WAPT Server uses Certificate Authority bundles from the operating system for validating the SSL/ TLS connection to Active Directory.

If the Active Directory certificate is self-signed or the certificate has been signed by an internal CA, you will need to add the certificates to the operating system certificate store.

To do so, just add a Certificate Authority in the /etc/pki/ca-trust/source/anchors/ and update the certificate store.

Debian / UbuntuCentOS / RedHatWindows

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

• Once you have setup LDAP SSL/ TLS on your Active Directory (please refer to Microsoft documentation for that), then you can enable support for SSL/TLS security for AD in waptserver.ini.

ldap_auth_ssl_enabled = True

• Restart waptserver service.

Configuring Client-Side Certificate Authentication

If your business needs a public WAPT Server on Internet, it can be secured with Client-Side Certificate Authentication.

That configuration restricts the visibility of the WAPT Server only to registered WAPT clients. It is done by relying on the WAPT Agent private key generated during registration. It works as follows:

• The WAPT Agent sends a CSR to the WAPT Server which the WAPT Server signs and sends back to WAPT Agent.

• Using the signed certificate, the Agent can access protected parts of the Nginx web server.

Note

We strongly recommend enabling Kerberos or login / password registration in the WAPT Server post-configuration.

Warning

All actions are to be carried out on the WAPT Server

Enabling Client-Side Certificate Authentication on WAPT Server

Warning

For Linux check if the symbolic link in sites-enabled exists:

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

The expected result should be:

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

Otherwise use the following command:

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

To enable the authentication, you need to add those parameters on WAPT server configuration file in the option section:

use_ssl_client_auth = True

Relaunch the post-configuring script.

Attention

Please note that as of 2024-09-20, WAPT does not support CRL, which means that when you delete a host in the WAPT Console, the host will still have access to the WAPT repository.

The WAPT Deployment utility cannot use https to retrieve the WAPT Agent, you will have to add this section in the file:

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;
}

Generating the Certificate Authority (CA)

When installing WAPT, you are asked to create a .pem / .crt pair by checking the boxes Tag as code signing and Tag as CA Certificate.

This .pem / .crt pair will allow to sign WAPT packages and new certificates.

Generating a new certificate with the Certificate Authority

Build a new .pem / .crt pair.

Note

The new certificate will not be a self-signed certificate;

This new certificate will be signed by the CA (the key generated at the time of the first installation of WAPT);

You MUST then fill in the Authority Signing Key and the Authority Signing Certificate.

When generating the new pem/ crt pair, you have the option to choose whether or not the new certificate will be a Code Signing type.

Hint

For recall, a Code Signing certificate is reserved to individuals with the Administrator role in the context of WAPT and a simple SSL certificate without the Code Signing attribute is reserved to individuals with the role of Package Deployer.

Administrators will be authorized to sign packages that CONTAIN a setup.py executable file (i.e. base packages).

Individuals with the Package Deployer role will be authorized to sign packages that DO NOT CONTAIN setup.py executable file (i.e. host, unit and group packages).

Generating a certificate without the Code Signing attribute

Keys and certificates that are Not Code Signing may be distributed to individuals in charge of deploying packages on the installed base of WAPT equipped devices.

Another team with certificates having the Code Signing attribute will prepare the WAPT packages that contain applications that will need to be configured according to the security guidelines of the Organization and the user customizations desired by her.

Generating a certificate with the Code Signing attribute

Generating a new .pem / .crt pair will also allow to formally identify the individual who has signed a package by looking up the CN attribute of the WAPT package certificate.

Hint

The new certificates will not be CA Certificates, which means that they will not be authorized to sign other certificates.

As a general rule, there is only one CA Certificate pem / crt pair per Organization.

Attention

It is not necessary to deploy child certificates with the WAPT Agent.

Child certificates are used with the WAPT Console to allow or restrict actions.

Deploying certificates of local IT admins on clients

Hint

Some Organizations will choose to let local IT administrators perform actions on WAPT equipped devices by issuing them personal certificates that will work on the set of devices for which the local IT admins are responsible.

The headquarter IT admins will deploy the certificates of local IT admins on the computers that local admins manage on their respective sites.

This way, local IT admins will not be able to manage computers located in headquarters, but on their own sites only.

It is possible to manage simply and in a finer way using Access Control Lists with the Enterprise version of WAPT.

You will need to copy the certificates of allowed local IT admins on WAPT clients in C:\program files(x86)\wapt\ssl.

Hint

Do not forget to restart the WAPT service on clients for them to use their new certificate. Open a command line cmd.exe.

net stop waptservice && net start waptservice

If you want to deploy the certificates using WAPT, use WAPT package templates

Configuring Access Control Lists

Hint

The SuperAdmin user of WAPT is authenticated by a password stored in waptserver.ini as a value of the wapt_password attribute. Others WAPT users may be local users htpasswd_path) or AD account users (ldap_auth_server / ldap_auth_base_dn).

ACLs define actions enabled for all types of users in the WAPT context.

Note

Default ACLs user level are defined by default_ldap_users_acls in waptserver.ini.

The default ACL for a new user is view.

Attention

Security is define by the certificate deployed on clients, not by ACLs.

ACLs simply limit what actions the WAPT Server is allowed to relay from the WAPT Console to the WAPT Agents.

As of |date|, the WAPT Agents do not check ACL rights.

To configure ACLs in WAPT, go to Tools ‣ Manage WAPT users and rights.

Note

On first launch after the WAPT Server installation, only the SuperAdmin account is present in the list of users.

If the SuperAdmin account does not exist or does not have the admin right, then the account is recreated by restarting the WAPT Server service.

The SuperAdmin account is authenticated using the value of wapt_password in the waptserver.ini configuration file.

Two types of account are manageable by ACL, local and Active Directory.

Local user account

Local users are defined by a .htpasswd file.

WAPT Server configuration

For using local user accounts, you need create a file named waptusers.htpasswd in the same folder on the WAPT Server containing the waptserver.ini file.

Linux:Windows

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

• On waptserver.ini add htpasswd_path settings.

htpasswd_path = password file location

Hint

Restart the WAPT Server service

Creating the user account

• In WAPT Users rights window, click on New account.

It is possible to rename accounts by pressing F2 on the User column.

• Save by clicking on Save account.

• For setting a password, see below.

• For setting rights, see the section on managing ACL rights.

If the local user has a password in waptusers.htpasswd, then the username appears in bold and Local User is checked, else change the password for this user.

Changing the user password

To change the password for the selected account:

• Do a right click on the account ‣ Change User Password on Wapt Server.

• Enter the new password.

Dialog box for changing the user password in the htaccess file

The local user appears in bold and the Local User is checked.

WAPT users set as Active Directory users

To manage WAPT users with Active Directory, you need to activate Active Directory authentication.

After a first successful login, the AD account will appear automatically in the list of WAPT users.

Blocking local user accounts

To unregister local users, do right click on the account ‣ Invalidate User Password on WAPT Server.

The user account will be blocked from managing anything in WAPT.

List of rights

Many rights and restrictions can be set for each user in the WAPT Console.

List of user rights

Right	Description
Admin	Grants the same rights as SuperAdmin, all rights are granted except local user.
View	Allows only view information on the WAPT Console.
Register hosts	Allows to use the Admin credentials to register manually a host with the WAPT Server.
Unregister hosts	Allows to remove a host from the WAPT Console.
Edit hosts	Allows to edit the host profile on the WAPT Console.
Edit packages	Allows to modify base packages on the WAPT Console.
Edit groups	Allows to modify group packages on the WAPT Console.
Edit self-service	Allows to modify self-service rules on the WAPT Console.
WUA	Allows to modify WUA / WSUS rules on the WAPT Console.
Edit unit package	Allows to modify unit packages on the WAPT Console.
Edit profiles package	Allows to modify profiles packages on the WAPT Console.
Apply upgrades	Allows to remotely apply upgrades on her perimeter of hosts, if host is on PENDING status.
Remote hosts actions	Allows to make use of the Windows Computer Management tool with the WAPT Console.
Edit Reports	Allows to create new or modify reporting queries.
Run Reports	Allows to run existing SQL reports.
Local user	Defines a Local User

Managing rights

By default, the SuperAdmin is the CA certificate user.

For other user, it is possible to associate a certificate that has been generated from the WAPT PKI or from another CA.

These certificates may or may not be children of the WAPT Certificate Authority.

Attention

If certificates are not issued from the Certificate Authority:

• Updated WAPT packages are available only to computers where certificates are deployed.

• ACLs are valid only on the perimeter of the hosts where the certificates are deployed.

Associating a certificate to a user

Hint

By default no certificate is set for any user (including SuperAdmin).

The account in the WAPT Console appears in italic if no certificate is associated to the user.

To associate a certificate to an user, do Right-Click on user ‣ Register user certificate.

Then, choose the certificate to associate to the user.

Adding / Removing rights

To add or remove rights, select the cell with left click and check-it by pressing the spacebar.

Hint

It is possible to do a multiple selection by using keyboard shortcuts Crtl+left-click and pressing the spacebar.

Restricting the perimeter of rights permitted to user

It is possible to associate a perimeter to a right given to a user.

View

Definition of the allowed perimeter

Perimeter	Description
Deny all	Denies any view right (not checked).
Allow on any perimeter	Allows view right for all WAPT Agents.
Allow specific perimeters	Allows view right on the selected perimeter defined as a list of certificates.
Allow where user certificate is deployed	Allows view only on the perimeter where the certificate of the WAPT Administrator is deployed.

Edit group packages

Hint

All group packages work on the same principle as described below.

Definition of the allowed perimeter

Perimeter	Description
Deny all packages	Denies any edit right to any package (not checked).
Allow any packages	Allows edit right to all WAPT packages.
Allow specific packages name	Allows edit right for the WAPT packages selected in the list.