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

# 11. Enhancing the security of your WAPT setup - Console side

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

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

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

## 11.2. Displaying the Certificates trusted by the hosts in the WAPT Console

In this tab, you can see the certificates that the host accepts to trust.

> Window showing the certificates trusted by the selected host

## 11.3. 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 2026-02-09 , the WAPT Agents do not check ACL rights.

To configure ACLs in WAPT, go to Server → 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.

### 11.3.1. Creating the user account

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

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

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

Fill in the user name, like user1 for example.

Note

Local users are defined by a .htpasswd file.

Fill in the user name and add @your_domain.lan, like user1@mydomain.lan.

Note

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.

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

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

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

### 11.3.4. 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.
view with certificate | Limits the view to the certificate associated with the user.
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.
Assign package | Allows to assign package(s) on hosts with the WAPT Console.
Remote hosts actions | Allows to make use of the Windows Computer Management tool with the WAPT Console.
Apply upgrade | Allows to remotely apply upgrades on her perimeter of hosts, if host is on PENDING status.
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.
Edit WUA | Allows to modify WUA / WSUS rules on the WAPT Console.
Edit AD groups | Allows to modify profiles packages on the WAPT Console.
Edit Org Units | Allows to modify unit packages on the WAPT Console.
Edit config packages | Allows to create, modify or delete configuration packages on the WAPT Console.
Edit Reports | Allows to create new or modify reporting queries.
Run Reports | Allows to run existing SQL reports.
View audit data | Allows to read the content of the tab audit data on the WAPT Console.
WADS admin | Allows a user to have the admin right for WADS on the WAPT Console.
WADS host deploy | Allows an user to activate the deploy button on the WAPT Console.
WADS view | Allows to read the content of the tab OS Deploy.
Update audit data | Allows to create, modify or delete the data on the tab Audit Data on the hosts.
Add asset | Allows to updates the host with custom data.

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

Important

If certificates are not issued from the Certificate Authority:

- Updated WAPT packages are available only to computers where certificates are deployed. Use this section to easily create and deploy user certificates.

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

1. Select a user.

2. Choose one or more ACLs to assign.

3. Set the permission (typically Deny ou Allow).

4. Save your changes.

Example: Assign Acl “register hosts” for user1.

1. Open the WAPT Console.

2. Navigate to: Server → Manage Wapt users and rights → New Role.

3. Enter the name of the role.

4. Once the role is created, you can add ACLs to it.

5. Assign the role to relevant users.

6. Save the changes.

Example: Assign the local role “waptpackages” for user1.

AD action ( RSAT or OpenRSAT)

1. Create a user group (e.g, waptpackage).

2. Add the relevant users to this group.

In the WAPT Console.

3. Navigate to: Server → Manage Wapt users and rights → New Role.

4. Enter the role name, followed by @your_domain.lan (e.g., waptpackage@your_domain.lan).

5. Once the role is created, you can add ACLs to it.

6. Automatically, all users in the AD group will inherit the ACLs assigned to the role.

7. Save the changes.

Example: Assign ad role “waptpackage@domain.lan” for AD users.

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

There are two classic ways for associationg a certificate with a user.

Select an user and do a Right-click → Register user certificate

Then, choose the certificate to associate to the user.

Select an user and click on Register user certificate in the top banner.

Then, choose the certificate to associate to the user.

#### 11.3.5.2. Adding / Removing rights

To add or remove rights:

1 - Select the user(s).

2 - Choose an ACL from the list.

3 - Enable or disable the desired right.

#### 11.3.5.3. Restricting the perimeter of rights permitted to user

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

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

When View with certificate is activate. The user will be able to see only hosts where is certificate are deployed.

Do not forget to assign certificate to user beforehand

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

## 11.4. Re-signing packages on the WAPT Server using the WAPT console

It is possible that a package was created by a WAPT user whose certificate is not recognized on certain machines. However, the package might still be suitable for those machines. In such cases, you can re-sign the package using the certificate of another WAPT user who has higher privileges within the network.

Go to Packages inventory, identify your package and do right-click Resign packages.

Re-signing with WAPT console

Then, click on `Resign` `packages`, and wait the OK, you can `close`.

Windows of re-signing with WAPT console

However, if this does not work the only way to perform the operation is to resign on the command line.