Qué se sincroniza y qué no

El servicio que sincroniza lleva a la nube las cuentas, sus atributos y, si se activa, un derivado del hash de contraseña. Pero no lleva todo: el estado de una cuenta bloqueada por intentos fallidos y el de una contraseña caducada no se reflejan en la nube con el modelo de hash, según la documentación oficial. Por eso un bloqueo local no frena el acceso a los servicios en la nube.

Pide SELECT * FROM estados_de_cuenta y úsalo para decidir qué esperar de un bloqueo en el dominio.

La política de alcance de Valmar tiene cuatro reglas. La primera dice que las cuentas con rol administrativo del dominio no se sincronizan: los administradores de la nube deben ser cuentas propias de la nube, de modo que quien comprometa el directorio local no obtenga también el control de la nube. Es una recomendación de diseño común, y aquí es regla de la casa.

Lee SELECT * FROM politica_de_alcance y luego SELECT * FROM unidades_organizativas.

Una cuenta compartida de una sala de control no identifica a nadie: si algo pasa, nadie responde por ella. Subirla a la nube multiplica ese problema. Y una cuenta de alguien ya retirado no tiene motivo para existir en ningún lado, mucho menos en dos.

Revisa la unidad de las cuentas que operan las salas de control de planta.

Una política se mide por cuántos objetos la incumplen, no por cuántas reglas tiene. Cruza cada unidad con las cuatro reglas: una unidad incumple si hoy se sincroniza y alguna regla dice que no debería. Suma los objetos de las unidades que incumplen. Las cuentas de servicio no tienen regla propia y no cuentan.