Los parches de septiembre rompen RDS y destapan el problema del vault de iLO
Un sysadmin se quedó sin llegar a sus hosts porque las credenciales de iLO vivían en la wiki alojada en esos mismos hosts. La salida: un Passwork autoalojado con caché offline.
Los parches acumulativos de septiembre rompieron RDS en los servidores de sesiones de una empresa, tanto en Windows Server 2019 como en 2022. Todo iba bien durante unas horas tras aplicar la actualización, y luego el primer cierre de sesión masivo dejaba el stack bloqueado, sin más salida que un reinicio forzado. El administrador que lo cuenta añade un detalle que escuece: Microsoft avisó primero a los suscriptores de M365 y lo hizo después de haber arreglado el problema.
Con RDS caído no había escritorio remoto, así que la única vía de entrada a los hosts era iLO. Y ahí estaba la trampa: las credenciales de iLO vivían en una página de runbook de la wiki interna. Esa wiki corría en una máquina virtual. Sobre un host. Al que no se podía llegar sin esas credenciales. El administrador pasó casi una semana dando vueltas sin cerrar el círculo, hasta que acabó conduciendo de madrugada para enchufar un carrito de rescate al host, como en 2009.
Del wiki al vault
De esa noche salió una decisión que llevaba tiempo pendiente: dejar de guardar cualquier acceso fuera de banda en un sistema que necesita la red para funcionar. Están moviendo esas credenciales a un Passwork autoalojado, en infraestructura separada de la que custodia, y activando el caché offline de los registros para que queden legibles en el portátil aunque no haya conexión. Cada registro se marca como offline y se cifra en el dispositivo; el caché se borra solo si el equipo no sincroniza dentro de la ventana que fije el administrador.
El cambio resuelve un problema y abre varios. El primero es el de las credenciales caducadas: si alguien rota la contraseña de iLO y el portátil no ha sincronizado, el técnico llega con una credencial muerta justo cuando necesitaba una viva. El segundo ya lo conocían del wiki: nada impide que alguien abra una credencial cacheada y la pegue en una aplicación de notas para tenerla a mano. El tercero son los teléfonos, porque parte del equipo que necesita el acceso fuera de horario lo cachearía en móviles que no se pueden borrar en remoto como un portátil.
Queda por resolver a quién se le da acceso offline. A todo el que pueda necesitarlo a las dos de la mañana, o a un par de personas y asumir que la cobertura depende de quién esté disponible.