alexrg/SGU-CredentialProvider
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 25 Wiki Activity

Agregar autorización de cuentas #5

New Issue
Closed
opened 2026-09-04 19:38:59 +00:00 by alexrg · 2 comments
alexrg commented 2026-09-04 19:38:59 +00:00
Owner
Copy Link
Copy Source

Que entre solo las ad- y do- a ciertos equipos. Que siempre entren las de administrador.

Que entre solo las ad- y do- a ciertos equipos. Que siempre entren las de administrador.
alexrg reopened this issue 2026-09-04 21:51:06 +00:00
alexrg commented 2026-09-07 21:45:24 +00:00
Author
Owner
Copy Link
Copy Source

Sí se puede, pero con una precisión importante: una OU no es un grupo de seguridad. No puedes seleccionar directamente “la OU Alumnos” en User Rights Assignment; debes usar grupos de seguridad cuyos miembros correspondan a esas OUs.

La estructura recomendada sería:

  • GG-SGU-Login-Administrativos
  • GG-SGU-Login-Docentes
  • GG-SGU-Deny-Alumnos
  • Un grupo o cuenta de equipo para identificar la máquina, por ejemplo GG-PC-LCI01-Policy

Procedimiento

  1. En Active Directory Users and Computers, crea los grupos de seguridad.

  2. Agrega a los grupos los usuarios correspondientes:

    • Administrativos al grupo de administrativos.
    • Docentes al grupo de docentes.
    • Alumnos al grupo de rechazo.

    La pertenencia debe mantenerse cuando se agreguen nuevos usuarios. Si quieres automatizarla según la OU, puedes hacerlo posteriormente con una tarea de PowerShell.

  3. Coloca la computadora en una OU específica, por ejemplo:

OU=Equipos restringidos,DC=lci,DC=lasalle,DC=mx
  1. En Group Policy Management, crea y enlaza un GPO a esa OU:
SGU - Restricción de inicio - LCI01
  1. En Security Filtering, agrega solamente la cuenta de equipo concreta, por ejemplo:
LCI01$

La cuenta de equipo debe tener permisos Read y Apply Group Policy.

  1. Edita el GPO en:
Computer Configuration
  Policies
    Windows Settings
      Security Settings
        Local Policies
          User Rights Assignment

Configura:

Allow log on locally

Incluye:

Administrators
GG-SGU-Login-Administrativos
GG-SGU-Login-Docentes

No incluyas el grupo de alumnos. Esta directiva determina quién puede iniciar sesión localmente en el equipo.

Deny log on locally

Incluye:

GG-SGU-Deny-Alumnos

Una directiva de denegación prevalece sobre una autorización, por lo que un alumno incluido allí será rechazado aunque pertenezca accidentalmente a un grupo permitido.

Si también quieres restringir Escritorio remoto, configura además:

Allow log on through Remote Desktop Services
Deny log on through Remote Desktop Services

Esas son directivas distintas de la autorización de inicio de sesión local.

En la máquina ejecuta:

gpupdate /force
gpresult /h C:\Temp\gpo-login.html

Después reinicia y revisa el informe:

C:\Temp\gpo-login.html

Importante

Conserva siempre una cuenta local de administración o una cuenta de soporte en Administrators. Si configuras incorrectamente Allow log on locally, puedes bloquear incluso el acceso administrativo. Microsoft recomienda comprobar los efectos de estas directivas antes de aplicarlas ampliamente.

Para tu caso, la solución más limpia sería:

OU de la computadora
        ↓
GPO específico para esa computadora
        ↓
Allow: Administrativos + Docentes
Deny: Alumnos

Los alumnos que ya tengan una sesión iniciada no serán expulsados automáticamente; la restricción se aplicará en el siguiente inicio de sesión o desbloqueo.

Sí se puede, pero con una precisión importante: una OU no es un grupo de seguridad. No puedes seleccionar directamente “la OU Alumnos” en **User Rights Assignment**; debes usar grupos de seguridad cuyos miembros correspondan a esas OUs. La estructura recomendada sería: - `GG-SGU-Login-Administrativos` - `GG-SGU-Login-Docentes` - `GG-SGU-Deny-Alumnos` - Un grupo o cuenta de equipo para identificar la máquina, por ejemplo `GG-PC-LCI01-Policy` ## Procedimiento 1. En **Active Directory Users and Computers**, crea los grupos de seguridad. 2. Agrega a los grupos los usuarios correspondientes: - Administrativos al grupo de administrativos. - Docentes al grupo de docentes. - Alumnos al grupo de rechazo. La pertenencia debe mantenerse cuando se agreguen nuevos usuarios. Si quieres automatizarla según la OU, puedes hacerlo posteriormente con una tarea de PowerShell. 3. Coloca la computadora en una OU específica, por ejemplo: ```text OU=Equipos restringidos,DC=lci,DC=lasalle,DC=mx ``` 4. En **Group Policy Management**, crea y enlaza un GPO a esa OU: ```text SGU - Restricción de inicio - LCI01 ``` 5. En **Security Filtering**, agrega solamente la cuenta de equipo concreta, por ejemplo: ```text LCI01$ ``` La cuenta de equipo debe tener permisos **Read** y **Apply Group Policy**. 6. Edita el GPO en: ```text Computer Configuration Policies Windows Settings Security Settings Local Policies User Rights Assignment ``` Configura: ### Allow log on locally Incluye: ```text Administrators GG-SGU-Login-Administrativos GG-SGU-Login-Docentes ``` No incluyas el grupo de alumnos. Esta directiva determina quién puede iniciar sesión localmente en el equipo. ### Deny log on locally Incluye: ```text GG-SGU-Deny-Alumnos ``` Una directiva de denegación prevalece sobre una autorización, por lo que un alumno incluido allí será rechazado aunque pertenezca accidentalmente a un grupo permitido. Si también quieres restringir Escritorio remoto, configura además: ```text Allow log on through Remote Desktop Services Deny log on through Remote Desktop Services ``` Esas son directivas distintas de la autorización de inicio de sesión local. En la máquina ejecuta: ```powershell gpupdate /force gpresult /h C:\Temp\gpo-login.html ``` Después reinicia y revisa el informe: ```text C:\Temp\gpo-login.html ``` ## Importante Conserva siempre una cuenta local de administración o una cuenta de soporte en `Administrators`. Si configuras incorrectamente **Allow log on locally**, puedes bloquear incluso el acceso administrativo. Microsoft recomienda comprobar los efectos de estas directivas antes de aplicarlas ampliamente. Para tu caso, la solución más limpia sería: ```text OU de la computadora ↓ GPO específico para esa computadora ↓ Allow: Administrativos + Docentes Deny: Alumnos ``` Los alumnos que ya tengan una sesión iniciada no serán expulsados automáticamente; la restricción se aplicará en el siguiente inicio de sesión o desbloqueo.
alexrg commented 2026-09-08 17:49:40 +00:00
Author
Owner
Copy Link
Copy Source

Implementado y probado en el entorno del dominio.

  • El Auth Broker clasifica las cuentas durante la sincronización/autenticación, sin cronjobs ni tareas programadas.
  • al* -> SGU-Alumnos; ad* -> SGU-Administrativos; do* -> SGU-Docentes.
  • La operación es idempotente y también corrige usuarios existentes en su siguiente autenticación satisfactoria.
  • Los tres grupos de seguridad se crean/validan durante el despliegue del servidor.
  • Prueba real: AD017045 fue agregado a SGU-Administrativos y se emitió el evento 1303 del Auth Broker.
  • Commits: 7a4f599, 1fe2006.
  • Release: v0.3.6.
Implementado y probado en el entorno del dominio. - El Auth Broker clasifica las cuentas durante la sincronización/autenticación, sin cronjobs ni tareas programadas. - `al*` -> `SGU-Alumnos`; `ad*` -> `SGU-Administrativos`; `do*` -> `SGU-Docentes`. - La operación es idempotente y también corrige usuarios existentes en su siguiente autenticación satisfactoria. - Los tres grupos de seguridad se crean/validan durante el despliegue del servidor. - Prueba real: AD017045 fue agregado a SGU-Administrativos y se emitió el evento 1303 del Auth Broker. - Commits: 7a4f599, 1fe2006. - Release: v0.3.6.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
alexrg (Alejandro Rosales)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: alexrg/SGU-CredentialProvider#5