[RESOLVED] WAPT Console - New user (Enterprise)

[alain17]

Good morning,

I'm currently running some tests on an Enterprise version as part of my WAPT product evaluation, and I've encountered a problem for which I haven't been able to find a solution anywhere. Therefore, I'm starting this thread here. I'm using an Enterprise version on Ubuntu 20.04 LTS for the server, and the deployment/administration workstations are running Windows 10.

I want to allow several administrators to manage our IT infrastructure of about a hundred workstations. This solves the problem of absences and the individual responsibility for deploying packages and updates. To this end, I created a user account for one of my colleagues in the WAPT console and granted him the necessary privileges (he can see all the options he needs). However, he is unable to deploy packages because the agents reject his certificate.

Here's what I've already checked:

• Its key is correctly listed on the server in /var/www/ssl/
• It can create packages (including the WAPT Upgrade) but cannot deploy them
• The packages he creates cannot be deployed by other users

How can I ensure that my certificate is correctly deployed on each agent so that it can manage them and the packages it creates are deployable? I haven't found any options anywhere.

Thank you in advance for your valuable help.

[sfonteneau]

Hello,

does each user have a certificate? Is it a certificate issued by an authority (signed by a CA) or is it a self-signed certificate?

Generally, the process is as follows:

A key is generated for each entity (site) or technician.
The certificate is assigned to the user in the ACL, and then the "Allow where user certificate is deployed" field is specified in the ACL.

Using the admin key (the key with the most privileges, your master key), a certificate package is created (Private Repository -> Generate a package template -> Certificate Package) and the certificate to be inserted into the package is selected.

This certificate package can then be pushed to the machines to which your technician has access.
Once the package is deployed on the machine, the technician will see the machine in the console (not before), and the machine will accept actions originating from this certificate.

[alain17]

Good morning,

Thank you for your prompt reply. Yes, each user has their own self-signed certificate generated upon their first login to the console. Does this mean I need to retrieve each technician's .crt file and upload it to the console as an administrator via ACLs?

Regarding deployment to workstations, does this mean that if I have 15 technicians (in addition to the admin), I need to create 15 certificate packages and deploy them to the necessary machines? Is that correct?

Once the package is deployed on the machine, the technician will see the machine in the console (not before) and the machine will accept the actions emanating from this certificate

Currently, my technician cannot push packages, but he can still see all of my test machines, which seemed strange to me (but not illogical).

[sfonteneau]

Hello,

Thank you for your prompt reply. Yes, each user has their own self-signed certificate generated upon their first login to the console. Does this mean I have to retrieve each technician's .crt file and add it to the console as an administrator via ACLs?

Regarding deployment to the workstations, does this mean that if I have 15 technicians (in addition to the administrator), I have to create 15 certificate packages and deploy them to the necessary machines? Is that correct?

Yes, that's it.

The other, sometimes simpler, method is to do it by entity (one CA per entity):

- CA Global
---- Global Technician 1
---- Global Technician 2
- CA Paris Site
---- Technician Paris 1
---- Technician Paris 2
- CA Nantes Site
---- Technician Nantes 1
---- Technician Nantes 2


The workstations at the Nantes site have the Nantes key and the Global key
The positions on the Paris site have the key Paris and Global

When you generate keys through the console for your technicians you can specify the parent (the authority).

For the agents, when a package is signed by the children of the authority, then the package is accepted.

This mode avoids deploying each technician's certificate on each machine, instead deploying only the authorities

Currently, my technician cannot push packages, but he can see all of my test machines, which seemed strange to me (but not illogical).

In fact, your technician can see everything right now because their "View" ACL must be in "Allow any perimeter" mode, or their ACL is set to admin

[alain17]

Good morning,

I tried again with the CA-oriented approach, which seems elegant to me. So I proceeded as follows:

1. I created a CA certificate for the organization to manage (self-signed)
2. I created a certificate for my technician, signed by the organization's board of directors
3. As an admin, I created a certificate package and sent my CA certificate to all the necessary machines
4. Still acting as administrator, I re-signed all packages with the CA certificate
5. I created a user for my technician and assigned him, via ACL, his own certificate signed by the CA
6. On the technician's workstation, I deployed the CA certificate via WAPT, copied the technician's certificate and key into the "private" directory (it is correctly recognized, by the way), and successfully logged in with his account

However, after all that, I still can't get it to deploy packages correctly. When I perform an action like checking for updates or launching installations, nothing happens (no task is created or executed). Yet it seems to me that I've done everything right, haven't I?

I also tried sending packets with a second administrator whose assigned certificate is that of the CA, but nothing works, no action is executed unless my initial administrator does it... I confess I don't understand anything anymore.

In fact, your technician can see everything right now because their "View" ACL must be in "Allow any perimeter" mode, or their ACL is set to admin

Absolutely, that explains it, thank you

[alain17]

Hello again,

I've made a little more progress by trying another idea that came to mind: I created a new version of the WAPT Upgrade package and signed it with the internal CA (self-signed). This deployed all the certificates, but didn't solve the initial problem: the packages still can't be deployed by the technician, nor by the second administrator.

I admit I'm getting a little desperate; I've spent a lot of time on this configuration and trying to understand what's wrong (including my weekend because my resources are very limited), and I really want to get to the end of this without having to use a single account (an admin account no less!) to manage everything.

[sfonteneau]

On the machines where the tests are performed, in the certificate tab, do you see the authorized certificates (CA) that you mentioned?

[alain17]

Yes, absolutely. The certificates are indeed deployed on the machines and appear in the "Certificates" tab, hence my confusion.

EDIT: That gave me an idea; I created a new technician with a new certificate whose parent is my main admin's CA certificate. The operation was successful, and the new technician can deploy. At this point, I'm wondering why the second CA isn't working.

EDIT 2: Well, after restarting everything, it's working. I don't know if it was the certificate package that took effect or the deployment of a WAPT Upgrade package, but the important thing is that it worked.