[RESOLVED] WAPT server accessible from outside in an AD context

[arnaud.houdelette]

Hello,

We currently have a WAPT server (enterprise) 2.3.0.13516 (Bullseye).

Currently, it is only accessible on our internal network (private addressing) or via VPN.
In order to use the Active Directory OUs, we have enabled Kerberos authentication, with all clients being members of the domain.

With the increasing prevalence of remote work and the mobility of some employees, we unfortunately have machines that are almost never on the internal network, and therefore do not benefit from automatic updates.

We are considering making the WAPT server accessible from the internet, ideally via a reverse proxy, but we do not want to make the domain controllers public.

How can we proceed? Can we force agent registration via Kerberos and accept agents already registered without it?

Thank you for your advice.

[dcardon]

Hello Arnaud,

Currently, the latter is only accessible on our internal network (private addressing) or via VPN.
In order to use the AD OU units, we have enabled Kerberos authentication, with all clients being members of the domain.

With the widespread adoption of remote work and the mobility of some employees, we unfortunately have machines that are almost never on the internal network, and therefore do not benefit from automatic updates.

We are considering making the WAPT server accessible from the internet, if possible via a reverse proxy, but we do not want to make the domain controllers public.

How can we proceed? Can we force agent registration via Kerberos and accept agents already registered without it?

The workstations need to see the Active Directory servers for initial registration (if Kerberos registration is enabled). During registration, the workstation will send a Certificate Signing Request (CSR) to generate a client certificate. The workstation will then use this client certificate to authenticate itself on the WAPT server.

It is therefore possible to register the workstation on the local network where Active Directory is accessible. For the subsequent steps, it is not necessary to have AD accessible by the client workstation (only the WAPT server) [1].

It is then possible to secure the WAPT server at the nginx server level by enabling client certificate authentication directly in the nginx configuration (available in the enterprise version of WAPT). The WAPT server is then correctly configured and secured for direct internet access in a DMZ.

As for the reverse proxy, it's quite complicated to configure correctly (precisely because of client certificate authentication). Therefore, it's recommended to place the WAPT server directly in the DMZ without a reverse proxy.

Sincerely,

Denis Cardon

[1] Note: Regarding self-service, care must be taken to be in waptserver-ldap authentication mode (see documentation) if the workstation is in the wild.

[arnaud.houdelette]

Thank you for the clarification.

Our Active Directory is not accessible from the DMZ. Therefore, we cannot place the WAPT server there.
However, given the server's Nginx configuration, I shouldn't have too much trouble finding a solution on that end.
I simply wanted to ensure that the clients' lack of connection to the Active Directory wouldn't interfere with the WAPT client (for example, with the allocation of OU units).

[arnaud.houdelette]

[1] note: regarding self-service, care must be taken to be in waptserver-ldap authentication mode (see documentation) if the workstation is in the wild.

Good evening.
I managed to set up a reverse proxy quite easily. (with forced certificate authentication, except for the websocket).
The clients are successfully connecting to the server, updating, etc...

However, I had a little trouble getting the self-service to work.
The documentation gives 3 methods to enable LDAP authentication, but only specifies that an AD account is required for the 3rd one... or perhaps I misunderstood.
It's working now.

[florentR2]

Similarly, we also use a reverse Nginx instance, which allows us, for example, to restrict console access from outside our network.
If I remember correctly, it also allows us to keep the backend's self-signed certificate valid regardless of its validity. It works quite well.

[aurouze.eliott]

Hello, I'm having trouble accessing the remote self-service interface. I can only access it by specifying the DN, for example: INT\aurouze.e, whereas it works without it when accessed locally.
Thank you in advance for your help.

[dcardon]

@eliott, thank you for opening a new topic for a new question. I'm locking this topic.
Regards,
Denis