Documenta las decisiones y el estado del issue #5

Autorizacion-por-rol.md

@@ -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.
+