Foro de TI tranquilo

Buen día,

Tras implementar la autenticación Kerberos en nuestro servidor WAPT y configurar una estación de trabajo de prueba con Kerberos habilitado, encontramos un problema al implementar nuevas estaciones de trabajo mediante WADS. Las estaciones de trabajo son visibles en la sección de implementación del sistema operativo, Windows se instala, pero la estación de trabajo arranca normalmente, pero no se registra en WAPT. Debemos ejecutar el comando `register`, que nos solicita el nombre de usuario y la contraseña de WAPT, registra la estación de trabajo e inicia las actualizaciones de paquetes como de costumbre. Intentamos modificar el script `conf` de la estación de trabajo de la siguiente manera:
Se supone que el ordenador se registra automáticamente al finalizar la instalación de Windows, pero se bloquea en la fase "Usuario: Ejecutando script postinstalación", que nunca termina. El ordenador permanece bloqueado en la pantalla de inicio de Windows (el logotipo de Windows con un pequeño punto dentro). Si apagamos el ordenador y volvemos a iniciar sesión, podemos registrarlo manualmente.

No tenemos otros problemas con la gestión de WAPT; las estaciones de trabajo son accesibles y las actualizaciones se realizan correctamente, ya sea que Kerberos esté en 0 o en 1.

¿Alguien más se ha encontrado con este problema y, de ser así, cómo lo resolvió?



Si es necesario:

Archivo waptserver.ini:
wat-get.ini desde la estación de prueba:

Ver archivo adjunto poste1.png estación de trabajo de producción wat-get.ini:

Ver archivo adjunto poste2.png
Gracias de antemano por sus respuestas
Atentamente,

Hola Paul,

¿reiniciaste postconf después de modificar el archivo waptserver.ini? Hay algunos cambios que deben reflejarse en el archivo de configuración de nginx.

Saludos,

Denis

Hola,

lo intenté de nuevo solo para asegurarme (aunque estoy seguro de que ya lo había hecho), pero no cambió nada.

Actualmente, las estaciones de trabajo se quedan atascadas en el "script de postinstalación" y tengo que apagarlas incorrectamente, reiniciarlas y finalmente registrarlas con WAPT.

Modifiqué el script de postinstalación para agregar el comando: "C:\Program Files (x86)\wapt\wapt-get.exe" register --wapt-server-user=XXXX--wapt-server-passwd=XXXX""
pensando que eso haría que se registraran, pero no fue así. Después de restaurar el script a su estado normal, el problema persiste (mientras que antes de la modificación, la PC completó la instalación de Windows normalmente pero simplemente no se registró con wapt).

Aquí está el script actual:
ping 127.0.0.1 -n 30
net stop waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" update
"C:\Program Files (x86)\wapt\wapt-get.exe" install base_software
net start waptservice

Saludos,

Hola Pablo,

¿Funciona el registro de Kerberos en un agente WAPT fuera de los WAD?

Para probar, puede usar una máquina limpia o una que ya esté integrada. Si la máquina está integrada, debe eliminarla del inventario y eliminar los archivos del certificado de cliente c:\program files (x86)\wapt\private\*.{crt,p12,pem}

Después de eso, realiza una escalada de privilegios en el SISTEMA LOCAL usando psexec
Luego, ejecuta un registro wapt-get sin nombre de usuario ni contraseña para verificar que la máquina pueda registrarse con Kerberos.

Atentamente,

Denis

Hola,

lo he probado. Después de configurar `use kerberos` a 1 en el agente y reiniciar el servicio WAPT, la autenticación funciona directamente sin contraseña. Si `use kerberos` se configura a 0, se requiere un nombre de usuario y una contraseña.

Por lo tanto, el registro de Kerberos parece funcionar. Luego probé la opción de autoservicio y recibí un mensaje de error de "contraseña incorrecta". Ingresé mi contraseña de Windows y todo funcionó. Pero con Kerberos, ¿no debería ser esto automático?

Esto aún plantea el problema del registro de nuevos PC. ¿Cómo puedo ver la configuración predeterminada implementada y verificar que esté usando Kerberos? Si no lo está usando, ¿puedo simplemente generar un nuevo agente que use Kerberos para resolver el problema?

Si es así, ¿qué sucede con los agentes actualmente implementados? ¿Se volverán a registrar todos?

Atentamente,

Hola de nuevo Paul,

PaulSLA escribió: ↑24 de julio de 2024 - 10:13 a. m. Prueba realizada: después de configurar `use kerberos` en 1 en el agente y reiniciar el servicio WAPT, la autenticación funciona directamente sin contraseña. Si `use kerberos` se establece en 0, se requiere un nombre de usuario y una contraseña.

Bien, eso significa que la parte Kerberos está configurada correctamente.

El registro de Kerberos parece funcionar. Probé la opción de autoservicio, pero me apareció un mensaje de error de "contraseña incorrecta". Ingresé mi contraseña de Windows y todo funcionó. Pero con Kerberos, ¿no debería ser automático?

Sí, debería funcionar automáticamente. Tiene `service_auth_type=waptserver-ldap` en la máquina de prueba, pero no en la otra. ¿Se realizó la prueba en la máquina de prueba?

Esto siempre causa problemas al registrar nuevas PC. ¿Cómo puedo ver la configuración de implementación predeterminada y verificar que usa Kerberos? Si no es así, ¿puedo simplemente generar un nuevo agente que use Kerberos para resolver el problema?

¿Las estaciones de trabajo recién implementadas muestran la hora correcta? Kerberos es algo sensible al tiempo. Cabe destacar que WinPE registra la hora de su BIOS en UTC, mientras que un sistema Windows instalado localmente registra la hora de su BIOS en la zona horaria local. Esto es bastante inconsistente. No hay zona horaria en la BIOS, y Windows no es consistente en el uso de la hora dentro de la BIOS... (Linux también registra la hora en UTC).

De ser así, ¿qué pasa con los agentes actualmente desplegados? ¿Se volverán a registrar?

Si un agente está registrado, tiene su certificado de cliente (.pem/.p12) y lo usa para autenticarse en el servidor. Solo usará la autenticación Kerberos si no tiene un certificado de cliente o si no funciona (es decir, si ha sido revocado). Por lo tanto, no se volverán a registrar las estaciones de trabajo ya implementadas o registradas.

Atentamente,

Denis

Hola,

gracias por las respuestas. Tengo la línea "service_auth_type=waptserver-ldap" en [global] en la máquina donde realizo la prueba. Todavía no la he implementado en las máquinas de producción porque no estoy seguro de comprender completamente todos los detalles de esta configuración.
También tengo la línea, que encontré en el foro, que solucionó un problema similar en su momento: "ldap_auth_ssl_enabled=False".

Logré solucionar el problema en los nuevos equipos. Por alguna razón que desconozco, el script de postinstalación se bloquea y la instalación no continúa. Dado que este script ya no realiza ninguna función útil, pude eliminarlo y la instalación prosigue. Una vez finalizada la instalación, el equipo se registra correctamente con Kerberos (después de generar un nuevo agente compatible, por supuesto).


Gracias por la información sobre las máquinas existentes. Entonces, ¿puedo cambiar `use_kerberos` de 0 a 1 en mis máquinas? ¿Esto no afectará a producción? Pero si entiendo correctamente, esto es de poca utilidad, solo para volver a registrarlos si fuera necesario algún día.

Así que el único problema restante es que la función de autoservicio no funciona con SSO a pesar de la presencia de las líneas mencionadas anteriormente y la configuración del servidor ya publicada.
Si la línea "service_auth_type=waptserver-ldap" está presente, el autoservicio se inicia con un mensaje de error en rojo que indica que la contraseña es incorrecta. Si la elimino, no aparece ningún mensaje y simplemente se me pide la contraseña. Desafortunadamente, no tengo muchas otras ideas para solucionar este problema.

Atentamente,

Hola Paul,

tengo algunas dudas sobre la configuración de autoservicio. Tu organización tiene contratado el soporte telefónico. Lo mejor es abrir un ticket y que alguien revise la configuración contigo en directo; no debería ser muy complicado.

Saludos,

Denis

Hola,

seguí investigando y el método 2 de la documentación funciona:

"ldap_auth_ssl_enabled = True
verify_cert_ldap = False".

Sin embargo, el tercer método no funciona, pero como también planeamos habilitar la verificación de certificados, abriremos un ticket para ambos problemas al mismo tiempo, ya que ambos parecen estar relacionados con un problema de certificado. ¡

Gracias por su ayuda!

Saludos cordiales,