Cuentas de sincronización: protección y vigilancia

Un servidor de sincronización con el modelo de hash de contraseña usa una cuenta del directorio local con permiso para replicar cambios del directorio, y otra cuenta en la nube con un rol exclusivo de sincronización. La documentación oficial describe ambas: la primera se crea con el prefijo MSOL_, la segunda lleva el nombre del servidor, y las dos tienen contraseñas largas que no caducan.

Eso las hace valiosas por dos razones: leen lo que casi nadie debería leer del directorio, y nadie las vigila porque no caducan y no las usa una persona. Por eso se tratan como parte del nivel 0, el que manda sobre el resto.

Pide SELECT * FROM cuentas_de_sincronizacion y mira permiso_clave y contrasena_caduca.

La política dice que la cuenta de conector del directorio local no pertenece a ningún grupo de administración del dominio. El motivo es sencillo: si una cuenta que se usa sola en un servidor además es administradora, quien la controle controla el dominio entero. Lee SELECT * FROM politica_de_cuentas_de_sincronizacion y compara con la columna miembro_de.

Cada servidor de sincronización, incluido el que está en espera, tiene su propia cuenta en la nube. Si el servidor se da de baja y su cuenta queda, hay una identidad con un rol de sincronización de directorios que nadie opera. Compara las cuentas de la nube con el inventario de servidores.

Una cuenta de conector entra como servicio, sola y a la hora del ciclo. Cuando aparece un inicio de sesión de tipo interactivo, hay una persona frente a una pantalla usando una cuenta que no es suya. Es la señal que más conviene vigilar. Pide SELECT * FROM inicios_de_sesion y busca la diferencia en la columna tipo_de_inicio.

La regla SC-5 dice de dónde deben salir los inicios de sesión de un conector: de la dirección del servidor de su inventario. Compara la columna origen de cada evento con el host o la IP de salida de los tres servidores. Cuenta los eventos cuyo origen no corresponde a ninguno.