Documenta las decisiones y el estado del issue #5

2026-09-09 17:42:43 +00:00
parent 0e19e03700
commit 5056133868
1 changed files with 101 additions and 0 deletions
@@ -0,0 +1,101 @@
 # Autorización por rol
 Esta página consolida la discusión del
 [issue #5](https://gitea.lci.ulsa.mx/alexrg/SGU-CredentialProvider/issues/5)
 y separa lo que ya forma parte del sistema de la política de acceso por equipo
 que todavía debe desplegarse y validarse.
 ## Objetivo
 Permitir que sólo las cuentas administrativas (`AD`) y docentes (`DO`) inicien
 sesión en determinados equipos del laboratorio, impedir el acceso de alumnos
 (`AL`) en esos equipos y conservar siempre una vía administrativa de
 recuperación.
 ## Estado actual
 | Capacidad | Estado |
 |---|---|
 | Clasificar `AL`, `AD` y `DO` en grupos de seguridad de AD | Implementado |
 | Crear y validar los grupos durante el despliegue del servidor | Implementado |
 | Reparar la membresía en la siguiente autenticación SGU válida | Implementado |
 | Restringir el inicio interactivo según el equipo mediante GPO | Pendiente de despliegue y piloto |
 | Restringir RDP mediante derechos independientes | Pendiente de definición |
 El Auth Broker aplica de forma síncrona e idempotente esta correspondencia:
 | Prefijo | Grupo de seguridad |
 |---|---|
 | `AL` | `SGU-Alumnos` |
 | `AD` | `SGU-Administrativos` |
 | `DO` | `SGU-Docentes` |
 Los grupos residen dentro de la OU de su rol. Si la membresía obligatoria no se
 puede comprobar, el aprovisionamiento falla antes de dejar una cuenta utilizable
 sin clasificación. Una cuenta ya existente se corrige en su siguiente
 autenticación SGU satisfactoria; no se necesita una tarea programada.
 Esta parte se incorporó en los cambios
 [`7a4f599`](https://gitea.lci.ulsa.mx/alexrg/SGU-CredentialProvider/commit/7a4f599)
 y
 [`1fe2006`](https://gitea.lci.ulsa.mx/alexrg/SGU-CredentialProvider/commit/1fe2006),
 publicados inicialmente en `v0.3.6`. La colocación de los grupos dentro de las
 OU de rol se consolidó posteriormente en
 [`8baa47f`](https://gitea.lci.ulsa.mx/alexrg/SGU-CredentialProvider/commit/8baa47f).
 > La pertenencia a un grupo clasifica la cuenta, pero por sí sola no concede ni
 > deniega el inicio de sesión en un equipo. Esa decisión corresponde a una GPO
 > o a una política local que consuma los grupos.
 ## Decisión de diseño
 Las OU organizan y delimitan la aplicación de políticas; no sustituyen a los
 grupos de seguridad en **Asignación de derechos de usuario**. La política debe
 referenciar `SGU-Alumnos`, `SGU-Administrativos` y `SGU-Docentes`, y aplicarse
 sólo a los equipos objetivo.
 Para un conjunto de equipos restringidos se propone:
 1. Colocar sus cuentas de equipo en una OU dedicada o incorporarlas a un grupo
   de seguridad de equipos.
 2. Vincular una GPO específica a esa OU y limitar **Leer** y **Aplicar directiva
   de grupo** a las cuentas de equipo objetivo.
 3. Configurar **Permitir el inicio de sesión local** con Administradores y los
   grupos institucionales autorizados.
 4. Configurar **Denegar el inicio de sesión local** con `SGU-Alumnos` cuando el
   equipo no deba aceptar alumnos.
 5. Definir por separado **Permitir/Denegar inicio de sesión a través de
   Servicios de Escritorio remoto** si el equipo ofrece RDP.
 La denegación prevalece sobre la concesión. Además, una GPO de derechos de
 usuario reemplaza la lista efectiva, por lo que debe conservar explícitamente
 las identidades administrativas y de soporte necesarias. Nunca se debe pilotar
 sin una cuenta de recuperación probada y sin mantener disponible el proveedor
 de contraseña de Microsoft.
 El usuario local estándar `alumno` creado por el bootstrap es una identidad
 local distinta de los miembros de dominio de `SGU-Alumnos`. Una denegación
 dirigida al grupo del dominio no afecta automáticamente esa cuenta local; su
 tratamiento debe decidirse de manera explícita.
 ## Piloto recomendado
 1. Aplicar la GPO a un único equipo de prueba, no a toda la OU del laboratorio.
 2. Confirmar primero el acceso de recuperación con una cuenta administrativa.
 3. Probar un usuario `AD`, uno `DO` y uno `AL`, tanto en consola como por RDP si
   corresponde.
 4. Ejecutar `gpupdate /force` y reiniciar antes de evaluar el resultado.
 5. Generar `gpresult /h C:\Temp\gpo-login.html` y revisar la política ganadora.
 6. Verificar los eventos de inicio de sesión y documentar el procedimiento de
   reversión antes de ampliar el alcance.
 Los cambios de derechos afectan inicios de sesión, desbloqueos y conexiones
 posteriores; no deben considerarse un mecanismo para expulsar sesiones activas.
 ## Pendientes
 - Identificar los equipos que aceptarán sólo `AD` y `DO`.
 - Definir si RDP tendrá exactamente la misma matriz que el inicio local.
 - Elegir el grupo o la OU de equipos usada para filtrar la GPO.
 - Ejecutar el piloto y registrar evidencia antes del despliegue general.