Restringir inicio de sesión por equipo en Active Directory: guía completa paso a paso

Controlar desde Active Directory qué usuarios pueden iniciar sesión en cada ordenador corporativo es una medida de seguridad esencial: evita accesos laterales, limita la propagación de malware y protege información sensible al reducir la superficie de ataque.

Contexto y desafío

En muchos entornos Windows los empleados comparten credenciales de dominio capaces de autenticarse en cualquier equipo. Esto supone un riesgo elevado—basta que una cuenta se vea comprometida para abrir puertas en toda la red. El reto consiste en restringir los inicios de sesión (interactivos o remotos) a los dispositivos que realmente pertenecen a cada persona, sin bloquear a los administradores ni entorpecer el soporte.

Resumen de la solución

La estrategia combina dos enfoques complementarios:

• Restricción a nivel de cuenta mediante la casilla Log On To…, que actúa como lista blanca por nombre de equipo.
• Política de grupo para definir quién puede (o no) iniciar sesión localmente y por Escritorio Remoto en cada estación.

El cuadro siguiente sintetiza el procedimiento a alto nivel; después lo detallamos paso a paso.

Paso	Qué hacer	Dónde se configura	Comentarios clave
Limitar a nivel de cuenta	Usar la opción Log On To… de la cuenta de AD	Active Directory Users and Computers → pestaña Account → Log On To…	Marcar Only the following computers y agregar los nombres NetBIOS o FQDN de los equipos permitidos. Actualizar si la persona cambia de PC.
Controlar por directiva	Crear o editar un GPO que establezca los derechos de inicio de sesión	GPMC → Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment	Trabajar con Allow log on locally, Deny log on locally, Allow log on through Remote Desktop Services y Deny log on through Remote Desktop Services. Asignar grupos específicos por equipo.
Vincular la directiva	Enlazar el GPO a la OU que contiene los equipos	GPMC → OU de equipos → Link GPO	Usar Security Filtering o WMI Filtering para granularidad adicional si conviene.
Refrescar y verificar	Forzar la aplicación y revisar resultados	En cada PC: gpupdate /force y luego gpresult /R	Comprobar que el GPO aparece en “Applied Group Policy Objects” y que los derechos de usuario son los esperados.
Mantenimiento	Automatizar los grupos de seguridad por equipo	Scripts, LAPS o soluciones de gestión de identidades	Crear un grupo <PCNAME>-AllowedUsers por máquina y añadirlo en los permisos de inicio de sesión correspondientes.

Requisitos previos

• Forest y dominio en estado de salud correcto.
• Delegación adecuada sobre la OU que contiene los objetos computadora.
• Consola Group Policy Management Console instalada en la estación de administración.
• Al menos un grupo de seguridad global o universal para cada ordenador o para cada rol de acceso, según la escala deseada.

Detalle paso a paso

Limitar la cuenta con “Log On To…”

En el complemento Active Directory Users and Computers:

1. Buscar la cuenta de usuario y abrir sus propiedades.
2. Ir a la pestaña Account y pulsar Log On To….
3. Seleccionar Only the following computers.
4. Agregar el nombre NetBIOS o FQDN del equipo autorizado; repetir para varios dispositivos si procede.
5. Aceptar los cambios. El control es inmediato para nuevas sesiones; las ya iniciadas no se interrumpen.

Ventajas: sencilla y muy específica.
Limitaciones: gestión manual; no impide conexiones RDP si el nombre del equipo cambia (alias DNS, etc.).

Crear el GPO de restricción

Usar la Group Policy Management Console (GPMC):

1. Crear un nuevo GPO, por ejemplo “Restricción Logon PC‑Usuarios”.
2. Editar el GPO y navegar a Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
3. Configuraciones clave:
   • Allow log on locally: incluir el grupo <PCNAME>-AllowedUsers.
   • Deny log on locally: añadir, por ejemplo, Domain Users si deseas un enfoque de denegación por defecto.
   • Allow log on through Remote Desktop Services: igual que el anterior, pero para RDS.
   • Deny log on through Remote Desktop Services: bloquear grupos genéricos si la estación no debe usarse por RDP.
4. Guardar y cerrar el editor de directivas.

Recuerda que Deny siempre prevalece sobre Allow; por eso conviene definir ambos para evitar “agujeros”.

Vincular y filtrar la directiva

El GPO debe aplicarse a los objetos computadora, nunca a los de usuario:

1. Arrastrar o vincular el GPO a la OU que agrupe los equipos.
2. En el panel de la derecha, usar Security Filtering para que solo los objetos PC sean afectados (quitar Authenticated Users si es necesario).
3. Opcional: aplicar un filtro WMI que valide la organización del equipo (por ejemplo, equipos con cierto prefijo en el nombre).

Refrescar la directiva y verificar resultados

En cada estación afectada o mediante una tarea remota:

gpupdate /force
gpresult /R

Comprueba que:

• El GPO aparece en “Applied Group Policy Objects”.
• En la sección Computer Settings → Security Settings → Local Policies → User Rights Assignment figuran los grupos que acabas de definir.
• El usuario fuera de la lista no puede iniciar sesión (código de error 0xC000015B o 0xC000006E según el caso).

Buenas prácticas adicionales

• Probar siempre en un entorno de laboratorio antes de viajar a producción.
• Mantener una cuenta local o un grupo de Domain Admins exento, para recuperación de desastres.
• Documentar el procedimiento de desbloqueo en caso de bloqueo accidental.
• Habilitar el registro de eventos 4624 (éxito) y 4625 (fallo) para auditoría forense.
• Aplicar un naming convention consistente (PC‑NombreEmpleado, LAPTOP‑1234, etc.) que simplifique los filtros y los informes.

Automatización y escalabilidad

PowerShell como aliado

Para entornos con cientos de usuarios, automatiza la creación y asignación de grupos:

# Ejemplo rápido (ejecutar con permisos adecuados)
$pc = "PC‑ALONSO"
$usuario = "DOMINIO\lalonso"
$grupo = "$pc-AllowedUsers"
if (-not (Get-ADGroup -Filter {Name -eq $grupo})) {
    New-ADGroup -Name $grupo -GroupScope Global -Path "OU=LogonGroups,DC=dominio,DC=local"
}
Add-ADGroupMember -Identity $grupo -Members $usuario

Con un CSV puedes iterar sobre decenas de asignaciones en segundos.

Group Policy Preferences

Si prefieres evitar scripts, Group Policy Preferences → Local Users and Groups permite añadir dinámicamente miembros a Administrators o a cualquier grupo local, incluida la política de inicio de sesión.

Escenarios híbridos y Azure AD

Cuando los dispositivos están Azure AD joined o gestionados a través de Intune:

• Endpoint Security → Account Protection → Local user group membership controla los grupos locales (Administrators, Remote Desktop Users, etc.) con la misma lógica de lista blanca.
• Azure AD Conditional Access puede exigir que la estación sea de tipo “corporate” o que cuente con un “compliant device” antes de conceder sesión interactiva o VPN.
• Los equipos Hybrid Azure AD joined aceptan ambas aproximaciones; la clave es no duplicar reglas contradictorias.

Auditoría y monitoreo

Centraliza los eventos de seguridad en un SIEM como Sentinel, Splunk o Elastic:

• Filtra EventID=4625 con Status=0xC000006E (nombre de usuario correcto, equipo no autorizado).
• Genera alertas cuando un mismo usuario provoca múltiples errores en máquinas no asignadas.
• Elabora paneles de cumplimiento: porcentaje de estaciones con GPO aplicada, usuarios fuera de política, tendencias mensuales, etc.

Preguntas frecuentes

¿Qué pasa si renombro un PC? Debes actualizar tanto la lista Log On To… como los grupos de seguridad vinculados; de lo contrario, el usuario perderá acceso. ¿Funciona con VDI o escritorios virtuales? Sí, pero lo habitual es asignar grupos por colección de hosts, no por VM individual. ¿Puede un atacante saltarse la restricción usando IP en lugar de nombre? No; la comprobación se basa en el Security Identifier de la cuenta computadora, no en la resolución DNS. ¿Cómo bloqueo inicios de sesión de servicio (non‑interactive)? Aplica la misma técnica usando los derechos Log on as a service y Deny log on as a service.

Conclusión

Limitar los inicios de sesión de dominio a los equipos asignados es una defensa sencilla y efectiva contra accesos no autorizados. Combinando la opción Log On To…, GPOs bien diseñadas y una gestión de grupos automatizada, protegerás tu red sin frenar la productividad. A medio plazo, integrar estas reglas con Azure AD y sistemas de auditoría aporta una visión completa del riesgo y un gobierno continuo.