GPO en Azure Active Directory: Evitá Estos Errores Comunes
Las GPO en Azure Active Directory no existen de forma nativa: Azure AD (ahora Microsoft Entra ID) no soporta Group Policy Objects tradicionales. Para aplicar directivas de grupo en la nube de Microsoft, necesitás usar Microsoft Entra Domain Services o mantener un entorno híbrido con un controlador de dominio on-premise. Intune es la alternativa directa para dispositivos cloud-only.
En 30 segundos
- Azure AD / Microsoft Entra ID no soporta GPO tradicionales. Si necesitás directivas de grupo en la nube, tu camino es Microsoft Entra Domain Services (antes Azure AD DS) o un entorno híbrido con DC on-premise.
- Microsoft Entra Domain Services crea GPO integrados para las OUs AADDC Users y AADDC Computers, y permite crear GPO personalizados vinculados a OUs propias.
- Para dispositivos Azure AD Join puro (sin dominio on-prem), la gestión de políticas se hace con Intune/Endpoint Manager, no con GPO.
- GPO, Azure Policy e Intune cumplen funciones distintas: GPO controla dispositivos y usuarios en dominio, Azure Policy gobierna recursos de Azure (suscripciones, resource groups), e Intune gestiona endpoints cloud-only.
- No existe migración directa de GPO a Intune, pero Group Policy Analytics en Intune permite evaluar la compatibilidad de tus GPO existentes.
Group Policy Objects (GPO) son el mecanismo clásico de Windows Server para aplicar configuraciones de seguridad, restricciones y preferencias a usuarios y equipos dentro de un dominio Active Directory. Funcionan con una lógica jerárquica: las políticas se aplican en orden desde el sitio, pasando por el dominio, hasta la Unidad Organizativa (OU) más específica. El problema aparece cuando querés llevar esa lógica a la nube. Azure AD fue diseñado como un servicio de identidad moderno, sin la infraestructura de dominio tradicional que las GPO necesitan para funcionar.
Eso genera confusión real. Muchos administradores asumen que al migrar a Azure van a poder seguir usando sus GPO como siempre. No es así, y entender las alternativas disponibles te ahorra horas de frustración.
Qué son las GPO y cómo funcionan en entornos Azure
Una GPO es un objeto que contiene configuraciones de sistema operativo, aplicaciones y seguridad. Se vincula a una OU, dominio o sitio dentro de Active Directory Domain Services (AD DS), y se aplica automáticamente a los usuarios y equipos que están dentro de ese contenedor. El procesamiento sigue el orden LSDOU: Local → Sitio → Dominio → OU. Si hay conflictos, la política más cercana al objeto (la OU más específica) gana.
Ahora bien, Azure AD (rebautizado como Microsoft Entra ID en 2023) no es un dominio AD DS. Es un servicio de identidad en la nube que maneja autenticación, SSO y acceso condicional, pero no tiene la estructura de dominio necesaria para procesar GPO. No hay OUs nativas, no hay SYSVOL, no hay replicación de políticas.
Para usar GPO en un entorno Azure tenés dos caminos concretos. El primero es Microsoft Entra Domain Services (antes Azure AD Domain Services), un servicio administrado que te da un dominio AD DS en la nube con soporte para GPO. El segundo es un entorno híbrido donde mantenés un controlador de dominio on-premise sincronizado con Azure AD vía Azure AD Connect. Fuera de estos dos escenarios, las GPO tradicionales no aplican.
GPO en Microsoft Entra Domain Services: configuración y gestión
Microsoft Entra Domain Services te provisiona un dominio administrado con dos OUs predeterminadas: AADDC Users y AADDC Computers. Cada una tiene una GPO integrada que podés editar pero no eliminar. Estas GPO integradas controlan configuraciones básicas como políticas de contraseña, bloqueo de cuenta y auditoría.
Para administrar estas GPO necesitás una VM de gestión unida al dominio administrado, con las herramientas RSAT instaladas (Remote Server Administration Tools), específicamente la Group Policy Management Console (GPMC). Según la documentación oficial de Microsoft, tu cuenta debe pertenecer al grupo AAD DC Administrators para tener permisos de edición.
El tema es que no podés crear GPO y vincularlos directamente a las OUs predeterminadas AADDC Users o AADDC Computers. Si necesitás políticas personalizadas, tenés que crear OUs propias dentro del dominio administrado y vincular ahí tus GPO. Ejemplo concreto: si querés aplicar una política de bloqueo de pantalla a los equipos del departamento de finanzas, creás una OU llamada “Finanzas-Equipos”, movés los objetos de equipo correspondientes ahí, y vinculás tu GPO personalizada a esa OU. Si te interesa, podés leer más sobre las diferencias entre Microsoft y GitHub.
Una limitación importante: no podés crear OUs dentro de las OUs predeterminadas. Tu jerarquía de OUs personalizada va directamente bajo la raíz del dominio administrado.
GPO en entornos híbridos: Azure AD Join vs Hybrid Join
Acá es donde la mayoría de los equipos de IT se confunden. Hay dos formas de unir un dispositivo a Azure AD, y cada una tiene implicancias directas sobre si las GPO funcionan o no.
Hybrid Azure AD Join
El dispositivo está unido tanto al dominio on-premise como a Azure AD. En este escenario, las GPO del controlador de dominio on-premise se siguen aplicando normalmente, porque el equipo mantiene conectividad con el DC y procesa las políticas al iniciar sesión. Es el modelo más común en migraciones graduales. El requisito crítico es que el dispositivo tenga línea de visión al controlador de dominio, ya sea por red corporativa o VPN. Si el equipo no puede contactar al DC, las GPO no se actualizan (aunque se aplican las que ya están cacheadas).
Un problema frecuente en este escenario es el Service Connection Point (SCP). Si el SCP no está bien configurado en AD DS, los dispositivos no descubren automáticamente el tenant de Azure AD y el hybrid join falla silenciosamente. Según la guía de identidad híbrida de Microsoft, verificar el SCP es el primer paso de troubleshooting cuando los dispositivos no aparecen como hybrid joined.
Azure AD Join puro
El dispositivo está unido solo a Azure AD, sin relación con un dominio on-premise. Acá las GPO directamente no funcionan. No hay DC, no hay SYSVOL, no hay infraestructura para procesarlas. La gestión de configuración se hace exclusivamente a través de Microsoft Intune (Endpoint Manager), usando perfiles de configuración, políticas de compliance y security baselines.
Para organizaciones que están migrando a cloud-only, este es el modelo target. Pero la transición no es trivial porque no hay un mapeo 1:1 entre configuraciones de GPO y políticas de Intune.
Mejores prácticas para estructurar GPO en Azure
Ya sea que estés usando Entra Domain Services o un entorno híbrido, la estructura de tus GPO marca la diferencia entre un entorno manejable y un caos de políticas que nadie entiende. Varonis publicó una guía de mejores prácticas que coincide bastante con lo que veo en la práctica.
Convención de nombres: cada GPO debe tener un nombre que diga qué hace y a quién aplica. Algo como “SEC-Finanzas-BloquearUSB” es infinitamente mejor que “GPO-Nueva-3”. Parece obvio, pero en entornos con más de 50 GPO la falta de nomenclatura se vuelve insostenible.
No vincules GPO a la raíz del dominio salvo para la Default Domain Policy (contraseñas, bloqueo de cuenta, Kerberos). Todo lo demás va a OUs específicas. Si vinculás una GPO restrictiva a la raíz, afecta a todo el dominio y después rastrear por qué un equipo de desarrollo no puede instalar software es una pesadilla. Si te interesa, podés leer más sobre nuestra guía de seguridad en GitHub.
Separá políticas de usuario y equipo. Una GPO que mezcla configuraciones de Computer Configuration y User Configuration es más difícil de debuggear. Mejor tener dos GPO separadas: una para equipo y otra para usuario, vinculadas a OUs distintas si es posible.
Documentá cada GPO. Usá el campo de comentarios de la GPO (disponible desde Server 2012) para anotar qué hace, quién la creó, cuándo y por qué. Cuando otro administrador tenga que modificarla dentro de 6 meses, va a agradecer esa información.
Backup después de cada cambio. GPMC permite exportar GPOs. Hacelo antes y después de cada modificación. Una GPO rota puede dejar a cientos de usuarios sin acceso en minutos.
GPO vs Azure Policy vs Intune: cuándo usar cada uno
Esta es la pregunta que más veo en foros y comunidades técnicas. Los tres son mecanismos de políticas, pero operan en capas completamente distintas. Microsoft lo explica en un post de Tech Community, pero la confusión persiste porque los nombres son parecidos.
| Característica | GPO (Group Policy) | Azure Policy | Intune / Endpoint Manager |
|---|---|---|---|
| Alcance | Usuarios y equipos en dominio AD DS | Recursos de Azure (VMs, storage, redes) | Dispositivos enrollados (Windows, iOS, Android, macOS) |
| Dónde aplica | On-premise / Entra Domain Services | Suscripciones y resource groups de Azure | Dispositivos cloud-only o hybrid |
| Qué controla | Configuración de SO, seguridad, aplicaciones | Compliance de recursos cloud (ej: “todas las VMs deben tener cifrado”) | Configuración de dispositivos, apps, compliance |
| Requiere dominio AD | Sí | No | No |
| Ejemplo típico | Forzar complejidad de contraseña en equipos del dominio | Impedir crear VMs sin tags de centro de costo | Configurar VPN corporativa en laptops registradas |
| Escenario ideal | Entornos on-prem o Entra DS | Gobernanza de infraestructura Azure | Gestión de endpoints modernos |
En un entorno híbrido, los tres conviven. Las GPO manejan los equipos unidos al dominio on-premise, Azure Policy gobierna la infraestructura cloud, e Intune gestiona los dispositivos modernos. No se reemplazan entre sí, se complementan.
Lo que me parece que Microsoft no comunica bien es la transición. Muchos equipos de IT entienden que Intune “reemplaza” a GPO, y técnicamente es la dirección estratégica, pero en la práctica la paridad de funcionalidades todavía no es completa. Hay configuraciones granulares de GPO que Intune no cubre.
Errores comunes al implementar GPO en Azure
Asumir que las GPO on-prem se sincronizan a Azure AD. Este es el error más frecuente y el más costoso. Azure AD Connect sincroniza identidades (usuarios, grupos), pero NO sincroniza GPO. Si tenés 200 GPO en tu dominio on-prem y migrás usuarios a Azure AD, esas GPO no viajan. Cada política que necesites en la nube la tenés que recrear en Entra Domain Services o traducir a Intune. Active Directory Pro documenta este y otros errores clásicos.
Configurar múltiples GPO con políticas de contraseña. En un dominio AD DS, la Default Domain Policy es la única GPO que efectivamente aplica la política de contraseñas para todo el dominio. Si creás otra GPO con una política de contraseñas distinta y la vinculás a una OU, esa política se ignora para las cuentas de dominio (aplica solo a cuentas locales de los equipos dentro de esa OU). Para políticas de contraseña diferenciadas necesitás Fine-Grained Password Policies (PSOs), no GPOs adicionales.
Estructura de OUs plana. Meter todos los objetos en 2-3 OUs sin jerarquía es un atajo que te cobra intereses altos. Cuando necesitás aplicar una política solo a un subgrupo, no tenés dónde vincularla sin afectar al resto. Ejemplo real: una empresa con una sola OU “Empleados” que necesita aplicar restricciones de USB solo a finanzas tiene que recurrir a filtros WMI o security filtering, que son más frágiles y difíciles de auditar que una OU dedicada. Si te interesa, podés leer más sobre vulnerabilidades conocidas en paquetes npm.
No auditar qué políticas se aplican realmente. gpresult /h reporte.html es tu mejor amigo. Muchos administradores configuran GPO y asumen que se aplican, sin verificar. Entre herencia, bloqueo de herencia, filtros de seguridad y orden de procesamiento, lo que vos creés que se aplica y lo que el equipo recibe pueden ser cosas muy distintas.
Falta de backups de GPO. Una GPO modificada incorrectamente puede bloquear el acceso a cientos de usuarios. Sin backup, la única opción es recrearla desde cero mientras los tickets de soporte se acumulan.
Guía paso a paso: crear y aplicar una GPO personalizada en Entra DS
Si estás usando Microsoft Entra Domain Services y querés crear tu primera GPO personalizada, estos son los pasos concretos.
1. Crear una VM de administración. Necesitás una VM Windows Server unida al dominio administrado. Desde el portal de Azure, creá una VM y unila al dominio de Entra DS durante el setup. Asegurate de que tu usuario pertenezca al grupo AAD DC Administrators.
2. Instalar RSAT y GPMC. Dentro de la VM, abrí Server Manager → Add Roles and Features → Features → Remote Server Administration Tools → Group Policy Management. También instalá los snap-ins de Active Directory Users and Computers.
3. Crear una OU personalizada. Abrí Active Directory Users and Computers, conectate al dominio administrado, hacé clic derecho en la raíz del dominio → New → Organizational Unit. Dale un nombre descriptivo: “IT-Workstations”, por ejemplo.
4. Mover objetos a la OU. Arrastrá los equipos o usuarios relevantes desde AADDC Computers o AADDC Users a tu nueva OU. Solo los objetos dentro de OUs personalizadas pueden recibir GPO personalizadas. Si te interesa, podés leer más sobre el reciente ataque a GitHub Actions.
5. Crear y vincular la GPO. Abrí GPMC, navegá hasta tu OU personalizada, clic derecho → “Create a GPO in this domain, and Link it here”. Dale un nombre descriptivo siguiendo tu convención.
6. Configurar las políticas. Clic derecho en la nueva GPO → Edit. Navegá por Computer Configuration o User Configuration y configurá las políticas que necesitás. Por ejemplo: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy para establecer complejidad mínima de contraseña.
7. Verificar la aplicación. En un equipo dentro de la OU, ejecutá gpupdate /force y después gpresult /h resultado.html. Abrí el HTML y verificá que tu GPO aparezca en la sección “Applied GPOs”.
Migración de GPO on-premise a la nube: alternativas y estrategias
No existe un botón de “migrar GPO a Intune”. Las GPO y los perfiles de configuración de Intune usan modelos completamente distintos: GPO se basa en archivos ADMX y procesamiento en el equipo, Intune usa MDM/CSP y comunicación cloud-device. La buena noticia es que Microsoft ofrece una herramienta de transición.
Group Policy Analytics en Intune te permite importar un backup de GPO (.xml exportado desde GPMC) y analizar qué porcentaje de las configuraciones tiene equivalente en Intune. En la práctica, la cobertura varía: configuraciones comunes como políticas de contraseña, BitLocker o restricciones de aplicaciones suelen tener paridad. Configuraciones muy específicas o basadas en scripts pueden no tener equivalente directo.
La estrategia que funciona es progresiva. Primero, exportá todas tus GPO y correlas por Group Policy Analytics. Clasificá los resultados en tres grupos: las que tienen equivalente directo en Intune, las que necesitan workaround (scripts de PowerShell via Intune, por ejemplo), y las que no tienen alternativa cloud. Para el tercer grupo, evaluá si realmente necesitás esa configuración o si era una política legacy que nadie recuerda por qué existe.
Herramientas de terceros como PolicyPak ofrecen puentes entre GPO e Intune, permitiendo aplicar configuraciones tipo-GPO a dispositivos managed por Intune. Es una opción válida para entornos con cientos de GPO donde la migración manual no es viable a corto plazo.
Qué significa para empresas y equipos en Latinoamérica
Muchas empresas latinoamericanas están en plena migración a Azure AD, especialmente pymes que pasaron de un servidor físico con Active Directory a Microsoft 365 Business. El escenario más común es el entorno híbrido: un DC viejo en la oficina, Azure AD Connect sincronizando usuarios, y dispositivos que se van sumando a Azure AD a medida que se renuevan. Si te interesa, podés leer más sobre repos infectados con malware en GitHub.
El riesgo concreto es que durante esa transición, las GPO dejen de aplicarse a los equipos nuevos (que son Azure AD Join puro) sin que nadie lo note. Políticas de seguridad como bloqueo de pantalla, restricción de USB o cifrado de disco dejan de aplicarse silenciosamente. Si tu organización está en este proceso, auditá qué equipos siguen recibiendo GPO y cuáles necesitan políticas de Intune.
Para la infraestructura que soporta estos entornos híbridos, contar con un proveedor de hosting con presencia regional marca la diferencia en latencia y soporte. Donweb ofrece servidores y VPS con data centers en la región, algo relevante si necesitás correr un controlador de dominio réplica en la nube cerca de tus usuarios.
Preguntas Frecuentes
¿Se pueden usar GPO en Azure Active Directory?
No directamente. Azure AD (Microsoft Entra ID) no soporta GPO tradicionales porque no tiene infraestructura de dominio AD DS. Para usar GPO en la nube de Microsoft necesitás habilitar Microsoft Entra Domain Services, que te da un dominio administrado con soporte para Group Policy. La alternativa para dispositivos cloud-only es Intune.
¿Qué diferencia hay entre Group Policy y Azure Policy?
Group Policy controla la configuración de usuarios y equipos dentro de un dominio Active Directory (sistema operativo, aplicaciones, seguridad). Azure Policy gobierna recursos de infraestructura Azure como máquinas virtuales, cuentas de almacenamiento o redes virtuales, asegurando que cumplan estándares de compliance. Operan en capas distintas y no se reemplazan entre sí.
¿Cómo aplico GPO en un entorno híbrido con Azure AD?
En un entorno Hybrid Azure AD Join, los dispositivos siguen recibiendo GPO del controlador de dominio on-premise normalmente, siempre que tengan conectividad de red con el DC. Las GPO se procesan al inicio de sesión como en un entorno AD DS tradicional. Para dispositivos Azure AD Join puro, necesitás usar Intune en lugar de GPO.
¿Existe una forma de migrar GPO a Intune automáticamente?
No existe migración automática. Microsoft ofrece Group Policy Analytics en Intune, una herramienta que importa backups de GPO y analiza qué configuraciones tienen equivalente en Intune. El proceso requiere exportar las GPO, evaluar la compatibilidad y recrear manualmente cada política como perfil de configuración de Intune.
Conclusión
El punto central es claro: si estás migrando a Azure, no podés asumir que tus GPO van a seguir funcionando como antes. Azure AD no es AD DS, y esa diferencia tiene consecuencias directas en cómo gestionás la configuración y seguridad de tus dispositivos.
Para entornos que necesitan GPO en la nube, Microsoft Entra Domain Services es la opción soportada. Para el camino cloud-only, Intune es la plataforma target, aunque la paridad con GPO todavía no es total. Y para la transición, el entorno híbrido funciona pero requiere atención a los detalles: SCP bien configurado, conectividad al DC, y auditoría constante de qué políticas se aplican en cada equipo.
Lo que conviene hacer ahora: inventariá tus GPO actuales, correlas por Group Policy Analytics, y empezá a planificar la migración de las más críticas a Intune. No esperes a que el último DC on-prem se apague para descubrir que 50 políticas de seguridad dejaron de aplicarse.
¿Qué es AADDC y para qué sirve?
AADDC es el dominio administrado creado por Microsoft Entra Domain Services en Azure. Te proporciona una infraestructura AD DS completamente funcional en la nube, con soporte para GPO en las OUs predeterminadas (AADDC Users y AADDC Computers). Es la solución si necesitás Group Policy en Azure sin mantener un DC on-premise.
¿Azure AD Join soporta GPO?
No. Azure AD Join puro no funciona con GPO tradicionales porque no tiene un dominio AD DS. Si querés gestionar dispositivos Azure AD Join, tenés que usar Microsoft Intune (Endpoint Manager) para configurar políticas, compliance y seguridad. Intune reemplaza a GPO en entornos cloud-only.
¿Cómo migro mis GPO de on-premise a Azure?
No hay migración automática de GPO. Primero evaluá qué GPO son críticas usando Group Policy Analytics en Intune. Luego, elegí tu camino: Azure AD DS si necesitás dominio administrado, entorno híbrido si querés mantener DC on-premise, o Intune si migrás a cloud-only. Cada opción requiere reconfiguración manual de políticas.
