Foro de TI tranquilo

Hola,

actualmente tenemos un servidor WAPT (empresarial) 2.3.0.13516 (Bullseye).

Actualmente, solo es accesible desde nuestra red interna (direccionamiento privado) o mediante VPN.
Para utilizar las OU de Active Directory, hemos habilitado la autenticación Kerberos, y todos los clientes son miembros del dominio.

Debido a la creciente prevalencia del teletrabajo y la movilidad de algunos empleados, lamentablemente tenemos equipos que casi nunca están en la red interna y, por lo tanto, no se benefician de las actualizaciones automáticas.

Estamos considerando hacer que el servidor WAPT sea accesible desde internet, idealmente mediante un proxy inverso, pero no queremos que los controladores de dominio sean públicos.

¿Cómo podemos proceder? ¿Podemos forzar el registro de agentes mediante Kerberos y aceptar agentes ya registrados sin él?

Gracias por su ayuda.

Hola Arnaud,

arnaud.houdelette escribió: ↑11 de abril de 2023 - 11:17 a. m. Actualmente, este último solo es accesible en nuestra red interna (direccionamiento privado) o a través de VPN.
Para usar las unidades OU de AD, hemos habilitado la autenticación Kerberos, con todos los clientes siendo miembros del dominio.

Con la adopción generalizada del trabajo remoto y la movilidad de algunos empleados, lamentablemente tenemos máquinas que casi nunca están en la red interna y, por lo tanto, no se benefician de las actualizaciones automáticas.

Estamos considerando hacer que el servidor WAPT sea accesible desde Internet, si es posible a través de un proxy inverso, pero no queremos hacer públicos los controladores de dominio. ¿

Cómo podemos proceder? ¿Podemos forzar el registro de agentes a través de Kerberos y aceptar agentes ya registrados sin él?

Las estaciones de trabajo necesitan acceder a los servidores de Active Directory para el registro inicial (si el registro Kerberos está habilitado). Durante el registro, la estación de trabajo enviará una solicitud de firma de certificado (CSR) para generar un certificado de cliente. La estación de trabajo utilizará este certificado de cliente para autenticarse en el servidor WAPT.

Por lo tanto, es posible registrar la estación de trabajo en la red local donde Active Directory es accesible. Para los pasos posteriores, no es necesario que la estación de trabajo cliente pueda acceder a AD (solo el servidor WAPT) [1].

Es posible proteger el servidor WAPT a nivel de servidor nginx habilitando la autenticación del certificado de cliente directamente en la configuración de nginx (disponible en la versión empresarial de WAPT). El servidor WAPT queda entonces correctamente configurado y protegido para el acceso directo a internet en una DMZ.

En cuanto al proxy inverso, su configuración correcta es bastante compleja (precisamente debido a la autenticación del certificado del cliente). Por lo tanto, se recomienda colocar el servidor WAPT directamente en la DMZ sin un proxy inverso.

Atentamente,

Denis Cardón

[1] Nota: Con respecto al autoservicio, se debe tener cuidado de estar en el modo de autenticación waptserver-ldap (ver documentación) si la estación de trabajo está en estado salvaje.

Gracias por la aclaración.

Nuestro Active Directory no es accesible desde la DMZ. Por lo tanto, no podemos ubicar el servidor WAPT allí.
Sin embargo, dada la configuración Nginx del servidor, no debería tener mayores problemas para encontrar una solución.
Simplemente quería asegurarme de que la falta de conexión de los clientes con Active Directory no interfiriera con el cliente WAPT (por ejemplo, con la asignación de unidades organizativas).

dcardon escribió: ↑11 de abril de 2023 - 12:11 [1] nota: con respecto al autoservicio, se debe tener cuidado de estar en el modo de autenticación waptserver-ldap (consulte la documentación) si la estación de trabajo está en la naturaleza.

Buenas noches.
Logré configurar un proxy inverso con bastante facilidad (con autenticación de certificado forzada, excepto para el websocket).
Los clientes se están conectando exitosamente al servidor, actualizando, etc.

Sin embargo, tuve un pequeño problema para conseguir que el autoservicio funcionara.
La documentación proporciona 3 métodos para habilitar la autenticación LDAP, pero solo especifica que se requiere una cuenta AD para el tercero... o quizás entendí mal.
Está funcionando ahora.

De forma similar, también utilizamos una instancia inversa de Nginx, que nos permite, por ejemplo, restringir el acceso a la consola desde fuera de nuestra red.
Si no recuerdo mal, también nos permite mantener válido el certificado autofirmado del backend, independientemente de su vigencia. Funciona bastante bien.

Hola, tengo problemas para acceder a la interfaz de autoservicio remota. Solo puedo acceder a ella especificando el DN, por ejemplo: INT\aurouze.e, mientras que funciona sin él cuando accedo localmente.
Gracias de antemano por su ayuda.

@eliott, gracias por abrir un nuevo tema para una nueva pregunta. Voy a cerrar este tema.
Saludos,
Denis