Quitar los derechos de admin local a los usuarios sin caos

Los derechos de administrador local son el facilitador silencioso de la mayoría de los compromisos de puestos de trabajo. Una carga de phishing que se ejecuta como usuario estándar queda contenida: no puede instalar un controlador, desactivar Defender, leer la memoria de LSASS ni plantar un servicio. La misma carga en una sesión de administrador puede hacer todo eso, y suele hacerlo en cuestión de minutos. Los propios informes de mitigación de Microsoft llevan tiempo mostrando que una gran parte de las vulnerabilidades críticas son mucho menos explotables sin derechos de administrador.

El pilar Cuentas y acceso privilegiado cubre la parte de arquitectura: el modelo por niveles de administración y las contraseñas locales únicas con LAPS. Esta guía es el proyecto práctico que se sitúa entre ambos: sacar a los usuarios del día a día del grupo Administrators local y mantenerlos fuera, sin saturar el soporte técnico.

Paso 1: inventariar quién es administrador hoy

No puedes quitar lo que no has medido. La pertenencia a los grupos locales deriva con scripts de creación de imágenes antiguos, atajos del soporte técnico ("te añado de momento"), instaladores de proveedores y los valores predeterminados de la unión a Microsoft Entra. Recógela de todos los dispositivos antes de cambiar nada.

En una sola máquina:

Get-LocalGroupMember -Group "Administrators" |
  Select-Object Name, ObjectClass, PrincipalSource

Get-LocalGroupMember genera un error cuando el grupo contiene SID huérfanos (cuentas eliminadas del dominio). En ese caso recurre a net localgroup Administrators o consulta mediante ADSI, y trata cada SID huérfano como un elemento a limpiar.

En todo el parque, ejecuta la misma consulta con tu herramienta de administración (inventario de hardware de Configuration Manager, un script de corrección de Intune o Invoke-Command contra una lista de máquinas) y centraliza la salida:

$computers = Get-ADComputer -SearchBase "OU=Workstations,DC=corp,DC=example" -Filter * |
  Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $computers -ScriptBlock {
  Get-LocalGroupMember -Group "Administrators" -ErrorAction SilentlyContinue |
    Select-Object @{n="Computer";e={$env:COMPUTERNAME}}, Name, ObjectClass
} | Export-Csv .\local-admins.csv -NoTypeInformation

Clasifica los resultados en tres categorías:

Encontrar Domain Users o Authenticated Users en el grupo Administrators local es más frecuente de lo que debería, a menudo por una sola línea de un script de inicio de hace años. Convierte a todos los usuarios en administradores en todas partes, así que corrígelo lo primero.

Paso 2: averiguar por qué los usuarios son administradores

Para cada usuario de la categoría "usuarios individuales", averigua el motivo antes de retirarle el derecho. Motivos típicos y lo que los sustituye:

• Instalar software. Publícalo en Company Portal, el Centro de software o un repositorio de winget seleccionado, desplegado en contexto de sistema.
• Impresoras y controladores. Despliega de forma centralizada las impresoras y los controladores empaquetados. No debilites las restricciones de Point and Print para compensar.
• Herramientas de desarrollo. Los desarrolladores suelen necesitar elevación para un puñado de herramientas (Hyper-V, características de WSL, certificados locales, depuradores). Resuélvelo con reglas de elevación, una VM de desarrollo dedicada o una cuenta de administración separada en un dispositivo separado.
• Aplicaciones de negocio que "necesitan admin". Normalmente la aplicación escribe en Program Files o en HKLM. Process Monitor muestra exactamente dónde; conceder permisos de modificación sobre una carpeta o clave es mucho más seguro que ser administrador de toda la máquina.
• Cambiar la configuración de red, la zona horaria o la VPN. Los usuarios estándar ya pueden cambiar la zona horaria, y la mayoría de los clientes VPN funcionan como servicio. Prueba antes de suponer.

Una encuesta de dos semanas en la que preguntes a los usuarios con derechos de administrador para qué los han usado, combinada con los registros de instalación de software, suele mostrar que la mayoría nunca los necesitó.

Paso 3: imponer la pertenencia con directiva de grupo

Quitar a los usuarios una vez no basta: necesitas que una directiva sea dueña del grupo para que no vuelva a derivar.

Opción A: Group Policy Preferences. En Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups, crea un nuevo elemento Local Group:

• Acción: Update
• Nombre del grupo: Administrators (built-in)
• Marca Delete all member users y Delete all member groups
• Añade los miembros que quieras: tu grupo de administración de Tier 2 y, si lo administras por nombre, el Administrator integrado

En cada actualización, el grupo se vacía y se reconstruye a partir de la lista. Varios elementos de GPP pueden dirigirse al mismo grupo, y el filtrado a nivel de elemento te permite añadir, por ejemplo, un grupo de administración del laboratorio solo en las máquinas del laboratorio.

Opción B: Restricted Groups. En Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups, añade Administrators y rellena Members of this group. Esto sustituye la pertenencia por completo. Es simple y fiable cuando una sola GPO es dueña del grupo, pero cuando varias GPO definen Members of this group para el mismo grupo, solo gana la última aplicada, lo que pilla a más de uno por sorpresa.

Elige un mecanismo, vincúlalo a la OU de puestos de trabajo y asegúrate de que se aplica antes de quitar a nadie manualmente. De lo contrario, la siguiente actualización de directivas de una GPO antigua puede volver a añadir a esas personas.

Paso 4: imponer la pertenencia con Intune

Para los dispositivos unidos a Microsoft Entra e híbridos administrados por Intune, usa Endpoint security > Account protection > Local user group membership. Se basa en el CSP de directiva LocalUsersAndGroups. Cada regla tiene una acción:

Para estandarizar el grupo Administrators, Add (Replace) es el equivalente de Restricted Groups. Incluye todo lo que quieras conservar, incluidos el Administrator integrado y tu grupo de soporte, porque todo lo que no figure se elimina.

Después, evita que se creen nuevos administradores en el momento de la unión:

• En el centro de administración de Microsoft Entra, en Devices > Device settings, establece Registering user is added as local administrator on the device during Microsoft Entra join en None (o Selected para un grupo reducido). Solo afecta a los dispositivos unidos después del cambio.
• En los perfiles de implementación de Windows Autopilot, establece User account type en Standard.
• Usa el rol Microsoft Entra Joined Device Local Administrator para el personal de soporte en lugar de añadir personas a cada dispositivo. Se aplica a todos los dispositivos unidos a Entra y no se puede limitar a un subconjunto, y los cambios solo surten efecto cuando se emite un nuevo Primary Refresh Token (hasta 4 horas) y el usuario cierra sesión y vuelve a iniciarla.

Para limitar el alcance por grupo de dispositivos, añade grupos de Microsoft Entra (por SID) al grupo Administrators con la directiva Local user group membership anterior. Windows evalúa como máximo 20 grupos de Entra para los derechos de administrador, y este método basado en grupos no se aplica a los dispositivos con unión híbrida a Microsoft Entra.

Paso 5: ofrecer una vía de elevación controlada

Algunos usuarios seguirán necesitando elevar archivos concretos. Microsoft Intune Endpoint Privilege Management (EPM), con licencia a través de Intune Suite, Intune Plan 2 o como complemento, e incluido en Microsoft 365 E5 desde julio de 2026, permite a un usuario estándar ejecutar con elevación un archivo aprobado sin ser administrador. Se configuran dos tipos de directiva:

• Directiva de configuración de elevación: activa EPM en el dispositivo y establece la respuesta de elevación predeterminada para los archivos que no coinciden con ninguna regla (denegar, exigir confirmación del usuario o exigir aprobación del soporte).
• Directiva de reglas de elevación: reglas por archivo basadas en nombre de archivo, hash, certificado de firma y versión, con un tipo de elevación automática, confirmada por el usuario (con justificación y autenticación de Windows opcionales) o aprobada por el soporte.

Prefiere las reglas de certificado más nombre de archivo para las herramientas firmadas de proveedores, y las reglas de hash para las utilidades internas. Evita reglas que eleven hosts de scripts, cmd.exe, powershell.exe, mmc.exe o instaladores capaces de lanzar procesos hijos arbitrarios: un shell elevado es un administrador local con otro nombre.

Sin EPM, la alternativa es un proceso de soporte técnico en el que un técnico introduce la contraseña LAPS del dispositivo en el aviso de UAC. Después, la acción posterior a la autenticación rota automáticamente la contraseña.

Paso 6: mantener una vía de emergencia

Prepárate para el día en que un dispositivo pierda la relación de confianza con el dominio o no pueda llegar a Entra ID. La cuenta de emergencia (break-glass) de un puesto de trabajo es su administrador local administrado por LAPS: única por dispositivo, recuperable por el grupo de lectores del soporte técnico y rotada tras su uso. Asegúrate de que esa cuenta esté incluida en la directiva de pertenencia que hayas aplicado en los pasos 3 y 4, y de que tenga denegado el inicio de sesión de red y RDP para que solo funcione en la consola.

Qué se rompe

• Software y extensiones del navegador autoinstalados que se instalan por máquina. Espera una avalancha de solicitudes en las dos primeras semanas; el catálogo del paso 2 absorbe la mayoría.
• Aplicaciones que escriben en ubicaciones protegidas en tiempo de ejecución. Fallan o escriben silenciosamente en el almacén virtualizado (consulta UAC y Administrator protection). Corrige los permisos de la ruta concreta.
• Tareas programadas y scripts creados por los usuarios que se ejecutaban con los privilegios más altos. Traslada los legítimos a un despliegue administrado.
• Costumbres del soporte técnico. Los técnicos acostumbrados a escribir su propia cuenta de administrador de dominio en la máquina de un usuario deben pasar a LAPS o a una cuenta de Tier 2. Ese cambio es una mejora de seguridad por sí mismo.

Verificarlo

1. Vuelve a ejecutar el inventario del paso 1 una vez aplicada la directiva. Los únicos miembros deben ser los que figuran en la directiva.
2. Audita los cambios. Habilita Audit Security Group Management en Advanced Audit Policy Configuration. El registro de seguridad anotará entonces el evento 4732 (se agregó un miembro a un grupo local con seguridad habilitada) y el 4733 (se quitó un miembro). Genera una alerta para el 4732 sobre el grupo Administrators fuera de tu proceso de cambios.
3. Revisa los informes de Intune. Para la directiva Local user group membership, el estado por dispositivo muestra conflictos y errores, normalmente por una GPO que choca con la regla de Intune en dispositivos coadministrados.
4. Confirma el token del usuario. En el dispositivo de un usuario, whoami /groups no debería mostrar BUILTIN\Administrators en absoluto para la sesión del propio usuario.

Lista de comprobación

• Inventario de la pertenencia al grupo Administrators local recogido en todo el parque
• Domain Users, Authenticated Users y SID huérfanos eliminados
• Motivos de los derechos de administrador catalogados y sustituidos (catálogo de software, impresoras, permisos de carpeta)
• Una sola directiva es dueña del grupo Administrators (GPP, Restricted Groups o Intune Replace)
• La unión a Entra y Autopilot ya no convierten a los usuarios en administradores locales
• EPM o un proceso de soporte basado en LAPS para la elevación, sin cuentas de administrador compartidas
• Cuenta LAPS incluida en la directiva como acceso de emergencia, con el inicio de sesión de red denegado
• Evento 4732 sobre el grupo Administrators local supervisado

Quitar el administrador local es uno de los proyectos menos vistosos y más eficaces de un plan de endurecimiento de Windows. En cuanto los usuarios son usuarios estándar, controles como el control de aplicaciones se vuelven imponibles, porque un usuario estándar ya no puede desactivarlos.