Directorios y orígenes de usuarios en Monosign
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 2 → 3
Actualización3 lecciones actualizadas
Actualización de contenido. Se notificó a los estudiantes inscritos.
Dos componentes de Monosign hablan con directorios y trabajan en sentidos opuestos. Elegir el equivocado es el error de diseño más frecuente.
| Requisito | Componente |
| --- | --- |
| Traer usuarios y grupos de un directorio **hacia** Monosign y permitirles iniciar sesión con la contraseña del directorio | Un **origen de usuarios** (Directory → `Sources`) |
| Permitir que un sistema que solo habla LDAP se autentique **contra** identidades de Monosign | El **gateway LDAP** |
Un origen de usuarios importa. El gateway LDAP sirve. El gateway nunca lee Active Directory en nombre de una aplicación, y un origen nunca responde a binds LDAP.
::diagram dir-source-vs-gateway
::shot dir-sources-list
### Crear un origen
`Add New` pide el `User Provider` (`Active Directory or LDAP` u otro proveedor) y un `Title`. Tras guardar, el proveedor se muestra como texto de solo lectura. Un origen creado con el proveedor equivocado no se puede corregir: se crea un origen nuevo y se elimina el antiguo. Planifique ese cambio en una ventana acordada con los usuarios afectados, porque no pueden iniciar sesión a través del origen antiguo una vez eliminado, y el nuevo debe terminar su primera sincronización antes de que puedan usarlo.
### Qué hace `Remove`
Eliminar un origen es una eliminación lógica. El origen se conserva con el estado `Removed` y su historial, todos sus usuarios pasan a `Removed` y sus grupos se eliminan. Los usuarios del origen pierden su vía de inicio de sesión, y la página no ofrece forma de deshacerlo.
### Guardar la configuración
La página de configuración del proveedor se guarda como un todo, de modo que cada guardado sustituye toda la configuración almacenada.
- Los campos cifrados, como la contraseña de bind, se muestran vacíos al abrir la página. Dejar uno vacío **conserva** el secreto almacenado; escribir cualquier cosa lo sustituye.
- Cualquier otro campo que esté vacío al guardar se **borra**. Si un campo opcional, como un filtro, parece vacío pero antes tenía un valor, vuelva a introducirlo antes de guardar.
### Programación
`Enable Auto Sync` activa la sincronización programada. `Full Sync Cron` es por defecto a medianoche y `Sync Cron` cada minuto. Desactivar `Full Sync Completed` obliga a que la siguiente ejecución sea una sincronización completa. Desde las páginas no se puede iniciar, detener ni cancelar una ejecución.
> Consejo: Ejecute `Test` en la página de configuración después de cada cambio. Recorre los pasos de conexión uno a uno, de modo que un host o una credencial incorrectos aparecen antes de la siguiente sincronización programada.
Un único conector, `Active Directory / LDAP User Provider`, atiende a Microsoft Active Directory y a los demás directorios LDAP compatibles. Un origen de este tipo hace cuatro cosas:
- **Sincroniza** usuarios, grupos y perfiles. Los grupos que son miembros de otros grupos conservan esa relación en Monosign.
- **Autentica** a los usuarios contra el directorio con la contraseña que escriben.
- **Cambia contraseñas** en el directorio cuando el origen lo permite (`Allow Password Change`).
- Ejecuta en el directorio las solicitudes de **desbloqueo de cuenta**.
Por eso, un requisito como "importar desde AD y que las personas cambien su contraseña de AD y desbloqueen su cuenta a través de Monosign" se resuelve con un origen de usuarios y nada más.
### Configuración de conexión
- **`Domain IP or Host`**: uno o varios hosts, separados por comas o punto y coma. `Find` descubre el resto de la configuración a partir del host.
- **`Use Secure Connection`**: activa LDAPS y cambia el puerto de 389 a 636.
- **`Domain UserName` y `Domain Password`**: la cuenta de bind habitual. `Use Privileged User` añade una segunda cuenta para operaciones que requieren más derechos, como los restablecimientos de contraseña.
::shot dir-source-settings
### Indique controladores de dominio, no el dominio
Un nombre de dominio en `Domain IP or Host` no es un servidor. Todos los controladores de dominio se registran con ese nombre, así que cada conexión puede llegar a un controlador distinto. Un solo controlador en mal estado hace fallar una parte de los inicios de sesión sin patrón visible, y un reintento funciona. Una única entrada además desactiva la conmutación entre hosts, que necesita al menos dos entradas, en la práctica tres. Enumere controladores de dominio concretos.
::diagram dir-domain-controllers
### Certificados
Cuando los binds seguros fallan con errores TLS, por ejemplo después de que los controladores de dominio renovaran sus certificados, la solución en producción es instalar la CA emisora o actualizar el `SSL Certificate Thumbprint` fijado. `Skip SSL Certificate Validation` en `Yes` silencia los errores de certificado en todos los inicios de sesión del origen. Úselo solo para un diagnóstico breve.
### Tamaño de la sincronización
Dos ajustes limitan cada ejecución: `Limit` (por defecto 500.000 objetos) y `Page Size` (por defecto 1.000). Un directorio mayor que `Limit` se sincroniza **parcialmente y sin ningún error**. Si una sincronización completa termina sin problemas pero aparecen menos usuarios de los que tiene el directorio, revise primero `Limit` y auméntelo.
> Nota: Monosign no escribe atributos de perfil de vuelta en el directorio. Los datos de perfil solo fluyen del directorio a Monosign.
### Dos registros de una sincronización
Cada origen ofrece dos vistas, y responden a preguntas distintas.
| Vista | Qué es | Límites |
| --- | --- | --- |
| `Sync log` | Un seguimiento en vivo de la sincronización en curso | Solo mientras la página está abierta, como máximo 2.000 líneas y 20 ejecuciones por origen |
| `Sync history (stored)` | El registro duradero | Se conserva 60 días |
El `Sync log` en vivo es local de un centro de datos. En un despliegue con dos centros de datos, una ejecución realizada por un nodo de servicio del otro sitio nunca aparece en su página, ni siquiera más tarde, aunque el estado del origen pase a `Finished`. Las sincronizaciones completas sí escriben en el registro en vivo cuando la ejecución es local. Si espera líneas y no ve ninguna, abra `Sync history (stored)` o abra Management en el centro de datos que ejecutó la sincronización.
### Cambiar la pertenencia a un grupo del directorio
Un grupo que procede de un origen de directorio pertenece al directorio. Cuando asigna un usuario a un grupo así en Monosign:
1. Monosign no escribe una pertenencia local. Usted ve `Group membership queued for provisioning to the source directory.`
2. La cola de aprovisionamiento escribe la pertenencia en el directorio, normalmente en unos 10 segundos.
3. El miembro aparece en `Assigned Objects` del grupo solo después de que la **siguiente sincronización entrante** lo importe.
::diagram dir-directory-group-write
Así, un directorio que ya muestra al miembro mientras `Assigned Objects` sigue vacío es el estado esperado entre los pasos 2 y 3. Tenga en cuenta tres cosas:
- `queued` significa que la solicitud quedó registrada, no que el directorio la aceptara.
- Las casillas `Provision` y `Deprovision` del origen no se consultan en esta ruta.
- Solo se escribe la pertenencia a un grupo existente. Monosign no crea el grupo en el directorio.
Una escritura fallida se reintenta. Tras el vigésimo fallo, la fila se cierra con `Maximum retry count (20) reached, no action taken!` y no se reintenta nunca, de modo que hay que repetir la asignación cuando el directorio vuelva a estar sano.
### Nombres de usuario que existen en más de un origen
Después de conectar un segundo directorio, algunos nombres de usuario pueden existir en ambos. Directory → Users → `Duplicated Users` enumera cada nombre de usuario presente en más de un origen, con una columna por origen y un recuento en `Duplication`. Solo se compara el nombre de usuario exacto, no el correo ni los valores de perfil.
La página es un informe de solo lectura. No tiene acciones para fusionar, eliminar ni abrir, así que cada duplicado se resuelve en las páginas de usuario. Carga todo el resultado de una vez, lo que puede tardar en directorios muy grandes.
> Consejo: Revise `Duplicated Users` justo después de la primera sincronización de un origen nuevo, antes de que los usuarios empiecen a iniciar sesión.
::shot dir-duplicated-users