🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Defensa y Bastionado de Active Directory
Módulo 12 de 13

Módulo 12: Proteger el entorno híbrido — Entra ID Connect y ataques on-prem a cloud

Módulo 12: Proteger el entorno híbrido — Entra ID Connect y ataques on-prem a cloud

Aviso ético: este módulo describe la arquitectura de autenticación híbrida entre Active Directory (AD) on-premises y Microsoft Entra ID, incluidas sus rutas de ataque conocidas (pivote on-prem → cloud, Golden SAML, abuso de sincronización). Toda la información se ofrece con fines exclusivamente educativos y de formación profesional defensiva. Los comandos de Microsoft Graph PowerShell, la creación de políticas de Conditional Access y cualquier prueba de concepto deben ejecutarse únicamente en un tenant de Microsoft Entra ID de pruebas (por ejemplo, un tenant del programa Microsoft 365 Developer) y, si se combina con AD on-prem, en un laboratorio aislado sin conectividad a producción. Comprometer o alterar sin autorización la sincronización de un tenant ajeno constituye un delito (arts. 197 bis y 264 del Código Penal español). Cambiar Conditional Access o Entra Connect en producción sin plan de rollback puede bloquear el acceso de administración de toda la organización: actúa siempre con ventana de mantenimiento, cuenta de emergencia (break-glass) verificada y aprobación del propietario del sistema.

Qué aprenderás

  • Por qué, en 2026, proteger AD y proteger Entra ID ya no son proyectos separados: la identidad híbrida es un continuo único que hay que asegurar de extremo a extremo.
  • Cómo funciona Microsoft Entra Connect (antes Azure AD Connect) y Cloud Sync, la cuenta de servicio MSOL_, y por qué su servidor es Tier 0.
  • Los tres métodos de autenticación híbrida —Password Hash Sync (PHS), Pass-Through Authentication (PTA) y federación con ADFS— y la superficie de ataque de cada uno.
  • Qué es Seamless SSO, la cuenta AZUREADSSOACC, y por qué su clave Kerberos es tan sensible como el krbtgt a otra escala.
  • Cómo se materializa el pivote de on-premises a la nube y qué es un ataque Golden SAML.
  • Las defensas de referencia: Entra Connect como Tier 0/PAW, rotación de AZUREADSSOACC, Conditional Access, Entra ID Protection, Privileged Identity Management (PIM) y monitorización de los logs de Entra.
  • Un laboratorio guiado para revisar la sincronización y crear una política de Conditional Access con MFA para administradores.

1. El continuo de identidad híbrida

En los módulos anteriores has protegido Active Directory como un sistema cerrado: modelo de niveles, delegación de Kerberos, protocolos legacy. Esa perspectiva es correcta pero incompleta: la gran mayoría de tenants de Microsoft Entra ID activos hoy sincronizan al menos una parte de sus identidades desde un AD on-premises. La pregunta ya no es «¿tenemos AD o tenemos la nube?»; es «¿cómo protegemos el puente que las une?».

Ese puente se llama sincronización de identidad híbrida, y su pieza central casi siempre es Microsoft Entra Connect (nombre actual de lo que fue Azure AD Connect, y antes DirSync/AAD Sync). Replica objetos —usuarios, grupos, atributos, en ocasiones hashes de contraseña— desde el AD local hacia Entra ID de forma continua, normalmente cada 30 minutos. Un atacante que compromete ese servidor no compromete «un servidor más»: compromete el mecanismo que decide qué identidades existen y qué contraseñas son válidas en todo el tenant cloud.

En el Enterprise Access Model (EAM) visto en el módulo de tiering, el «Control Plane» —sucesor funcional de Tier 0— ya incluye explícitamente Entra Connect, los roles administrativos de Entra ID y Conditional Access. Este módulo desarrolla qué significa eso en la práctica.

2. Entra Connect: sincronización, hashes y la cuenta MSOL_

Entra Connect se instala típicamente en un servidor miembro (nunca en un DC, aunque sea técnicamente posible) con conectividad LDAP/LDAPS hacia el AD local y HTTPS hacia los endpoints de Entra ID. Su ciclo tiene tres fases: importación (lee cambios de AD por USN — Update Sequence Number), sincronización (aplica reglas de transformación en el «metaverse», la base intermedia que unifica atributos) y exportación (envía los cambios a Entra ID vía API).

Durante la instalación se crea automáticamente una cuenta de servicio con prefijo MSOL_ (por ejemplo MSOL_a1b2c3d4e5f6) que ejecuta el servicio Windows de sincronización. Esa cuenta recibe permisos delegados extraordinariamente potentes: Replicating Directory Changes y Replicating Directory Changes All sobre el dominio —los mismos derechos que abusa un ataque DCSync—, necesarios si Password Hash Sync está habilitado, más permisos de escritura sobre atributos en el ámbito sincronizado. Consecuencia defensiva directa: quien controla el servidor de Entra Connect tiene, de facto, los mismos derechos de replicación que un controlador de dominio.

Microsoft ofrece también Entra Cloud Sync, una arquitectura con un agente ligero (Provisioning Agent) que puede desplegarse en varios servidores en alta disponibilidad activa/activa sin clúster, delegando la orquestación a la nube en vez de mantener un metaverse completo local. Reduce superficie local, pero no elimina que el servidor con el agente siga siendo un punto de confianza elevada: quien lo controla sigue influyendo en qué llega al tenant.

3. Métodos de autenticación híbrida: PHS, PTA, ADFS y Seamless SSO

Sincronizar el objeto usuario es solo media pregunta. La otra mitad: cuando el usuario escribe su contraseña, ¿dónde se valida? Entra Connect ofrece tres modelos, mutuamente excluyentes como método primario (PHS se recomienda siempre como respaldo, incluso combinado con PTA o ADFS).

Método Cómo funciona Riesgo principal Cómo se protege
Password Hash Sync (PHS) Cada 2 minutos, Entra Connect sincroniza un hash del hash: toma el NTLM (MD4) de AD y le aplica una segunda vuelta de PBKDF2 con salt por usuario antes de enviarlo a Entra ID. La validación de login ocurre enteramente en la nube. Si el hash NTLM original en AD está comprometido (DCSync, NTDS.dit robado), el atacante puede iniciar sesión en Entra ID directamente. Si además hay Seamless SSO, comprometer AZUREADSSOACC abre otra vía. Reduce superficie frente a PTA/ADFS al no depender de infraestructura on-prem activa para autenticar; el foco real es proteger el AD (hashes) y exigir MFA/Conditional Access en la nube.
Pass-Through Authentication (PTA) La contraseña nunca se sincroniza. Un agente PTA on-premises recoge la petición encolada por Entra ID mediante una conexión saliente persistente, valida contra el AD local y devuelve el resultado. El agente corre con privilegios en el servidor. Un atacante que lo compromete puede registrar contraseñas en claro de cualquier usuario que se autentique, o —en escenarios más graves— manipular las respuestas para autenticar como cualquier usuario sin conocer su contraseña. Tratar cada servidor con agente PTA como Tier 0, desplegar ≥3 agentes en servidores independientes para resiliencia sin degradar aislamiento, y monitorizar el registro/desregistro de agentes en el portal.
Federación con ADFS Entra ID no valida contraseñas ni conoce hashes. El dominio se marca «federado»; ADFS valida contra AD (Kerberos/NTLM local) y devuelve un token SAML/WS-Fed firmado con un certificado propio. Si se exfiltra el certificado de firma de tokens de ADFS, el atacante puede forjar tokens válidos para cualquier usuario, con cualquier rol, sin contraseña ni MFA: es el ataque Golden SAML (sección 5). ADFS como Tier 0 estricto, rotación periódica e inmediata (ante sospecha) del certificado de firma, y —la mitigación estructural más recomendada— migrar a PHS/PTA con Seamless SSO salvo requisito de negocio real que exija federación.
Seamless SSO (complemento de PHS o PTA) Permite iniciar sesión en Entra ID sin volver a escribir la contraseña si el equipo ya está autenticado por Kerberos en el dominio. Crea en AD una cuenta de equipo especial, AZUREADSSOACC, cuya clave Kerberos comparte con Entra ID. Quien posee esa clave Kerberos puede forjar tickets que Entra ID acepta como autenticación silenciosa de cualquier usuario, sin conocer su contraseña: comparable a un Golden Ticket acotado a este flujo. Rotar la clave Kerberos cada ~30 días con el script oficial (sección 6.4), auditar permisos sobre ese objeto de equipo, y limitar Seamless SSO a redes internas de confianza.

Para comprobar qué método usa realmente un tenant:

Connect-MgGraph -Scopes "Domain.Read.All"

# Tipo de autenticacion de cada dominio verificado
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified, IsDefault

# Si AuthenticationType = "Federated", inspeccionar el detalle
Get-MgDomainFederationConfiguration -DomainId "midominio.com" |
    Select-Object IssuerUri, PassiveSignInUri, SigningCertificate

4. Por qué el servidor de Entra Connect es Tier 0

Un activo es Tier 0 si su compromiso permite, directa o indirectamente, controlar la identidad de toda la organización. Para el servidor de Entra Connect (y, por extensión, cualquier servidor con agentes PTA o el propio ADFS), la respuesta es sí por varias vías simultáneas:

  1. Acceso a hashes de contraseña (si PHS está activo): el proceso de sincronización lee los hashes NTLM con los mismos permisos de replicación que un DC.
  2. Capacidad de manipular qué se sincroniza: quien controla el servidor controla las reglas de sincronización y puede, en teoría, reasociar el immutableID de una cuenta cloud administrativa con una identidad on-premises que ya controla —técnica conocida como secuestro vía soft-match/hard-match.
  3. Ejecución en contexto de MSOL_: esa cuenta tiene permisos equivalentes a DCSync sobre el AD on-premises, así que comprometer Entra Connect también es una vía de escalada hacia AD: el pivote funciona en ambas direcciones.
  4. Punto de confianza para PTA/Seamless SSO si están habilitados, con las implicaciones ya descritas en la tabla anterior.

Tratarlo como Tier 0 significa aplicar literalmente las reglas del módulo de tiering: administración exclusiva desde PAW de Tier 0, nunca desde el portátil diario de un administrador; GPO de negación de logon (Deny log on locally / through RDS / as a batch job / as a service) vinculada a la OU del servidor; ningún servicio adicional coinstalado que amplíe la superficie; sin RDP directo desde Internet ni desde VLANs de usuario, solo vía jump server de Tier 0; y copia de seguridad regular de las reglas de sincronización, no solo del sistema operativo.

El error más repetido en auditorías de campo es el inverso: el servidor de Entra Connect administrado por el equipo de «servidores generales» (Tier 1), con RDP abierto desde la VLAN de administración estándar y sin GPO de aislamiento específica —tratado como activo de importancia media cuando es, funcionalmente, un segundo controlador de dominio con una puerta adicional hacia la nube. Si se usan varios agentes PTA para alta disponibilidad, cada uno recibe la misma clasificación, sin excepción «por ser secundario».

5. Ataques híbridos: el pivote on-prem → cloud y Golden SAML

La idea central de este módulo se resume así: en un entorno híbrido, la superficie de ataque contra Entra ID no termina en Entra ID. Un atacante puede alcanzar el control total del tenant cloud comprometiendo la infraestructura on-premises que decide qué es verdad en la nube, sin explotar nada en Microsoft 365 ni robar contraseñas en el sentido tradicional. Por eso el EAM integra Entra Connect y ADFS en el Control Plane: son puntos únicos de confianza (trust anchors) desde los que se puede suplantar cualquier identidad.

El flujo típico documentado en post-mortems reales (el más citado en la industria es la cadena de ataque de SolarWinds en 2020, que usó exactamente esta técnica tras obtener persistencia on-premises) sigue este patrón: compromiso inicial de un endpoint; movimiento lateral hasta acceso administrativo local en ADFS o Entra Connect (facilitado por la falta de segregación Tier 0 de la sección 4); exfiltración del certificado de firma de ADFS o de la clave de AZUREADSSOACC; generación de tokens/tickets forjados válidos para cualquier usuario, incluidos administradores globales, sin MFA; y acceso persistente y sigiloso durante meses, porque los tokens forjados no dejan los patrones de log de un ataque de fuerza bruta o phishing.

5.1. Golden SAML

Golden SAML (término acuñado por investigadores de CyberArk en 2017) es la forja de tokens SAML mediante un certificado de firma robado. SAML es el protocolo con el que ADFS le «asegura» a Entra ID que un usuario se autenticó: el token contiene el UPN, sus atributos y una firma que Entra ID valida contra el certificado de confianza configurado para ese dominio federado.

El ataque explota una asimetría: Entra ID no vuelve a comprobar la contraseña cuando recibe un token SAML válido, confía en que ADFS ya lo hizo. Si el atacante tiene la clave privada del certificado de firma (reside en el servidor ADFS, protegida por DPAPI y, en la práctica de campo, accesible con privilegios de administrador local), puede construir manualmente un token que afirme «admin@empresa.com se autenticó con éxito, incluida su pertenencia a Global Administrator» sin que ese login haya ocurrido jamás. Entra ID, al validar la firma correctamente, lo acepta.

Lo que hace a Golden SAML especialmente peligroso: bypass total de MFA (el token puede declarar que ocurrió MFA, y Entra ID no tiene forma de refutarlo); persistencia post-remediación (resetear contraseñas no sirve de nada si no se rota el certificado de ADFS); y sigilo (no genera intentos fallidos ni aparece en los logs de ADFS local, porque ADFS nunca procesó esa autenticación).

5.2. Abuso de PTA

Un atacante con persistencia en el servidor del agente PTA puede desplegar un agente modificado que, en vez de validar honestamente contra AD, exfiltra cada contraseña en claro que procesa, o directamente responde siempre «autenticación correcta» a Entra ID sin comprobar nada. Esta segunda variante es funcionalmente equivalente a Golden SAML en impacto, aunque distinta en mecanismo.

6. Defensa: Tier 0, PAW y protección de secretos híbridos

6.1. Inventariar los puntos de confianza híbrida

# En el servidor de Entra Connect
Import-Module 'C:Program FilesMicrosoft Azure AD SyncBinADSyncADSync.psd1' -ErrorAction SilentlyContinue

Get-ADSyncScheduler | Select-Object SyncCycleEnabled, CurrentlyEffectiveSyncCycleInterval
Get-ADSyncConnector | Select-Object Name, Type, Identifier
Get-ADSyncAADCompanyFeature | Select-Object PasswordHashSync

# Desde Graph, vista desde el lado cloud
Connect-MgGraph -Scopes "Directory.Read.All","OnPremDirectorySynchronization.Read.All"
Get-MgOrganization -Property OnPremisesSyncEnabled, OnPremisesLastSyncDateTime |
    Select-Object DisplayName, OnPremisesSyncEnabled, OnPremisesLastSyncDateTime

Cualquier discrepancia entre «cuántos agentes creemos tener» y lo que Entra ID reporta como activo es sospechosa por definición: puede ser un agente huérfano mal desmantelado o uno no autorizado.

6.2. Restringir permisos de MSOL_ al escenario real

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:$domainDN"
$acl.Access |
    Where-Object { $_.IdentityReference -match "MSOL_" } |
    Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType -AutoSize

6.3. Rotar el certificado de firma de tokens de ADFS

Equivale a la rotación del krbtgt en AD puro: no evita el compromiso inicial, pero invalida cualquier Golden SAML previamente forjado sin que el defensor lo supiera.

Get-AdfsProperties | Select-Object AutoCertificateRollover, CertificateDuration

# Forzar la generacion de un nuevo certificado tras sospecha de compromiso
Update-AdfsCertificate -CertificateType Token-Signing -Urgent

6.4. Rotar la clave Kerberos de AZUREADSSOACC

Microsoft publica un script oficial (módulo AzureADSSO) que rota la clave sin interrumpir el servicio, manteniendo temporalmente dos claves activas:

Import-Module AzureADSSO
$creds = Get-Credential  # administrador global de Entra ID
New-AzureADSSOAuthenticationContext -Credential $creds

Update-AzureADSSOForestCredentials -OnPremCredentials (Get-Credential) -Forest "midominio.local"

Get-AzureADSSOStatus | ConvertFrom-Json | Select-Object -ExpandProperty Domains

Se recomienda esta rotación cada ~30 días (análoga a krbtgt) y de forma inmediata tras cualquier incidente que involucre un DC, ya que la clave se almacena como objeto de equipo normal en AD y es alcanzable vía DCSync/NTDS.dit.

7. Conditional Access y MFA

Conditional Access decide en tiempo real, para cada intento de acceso, qué controles exigir según usuario, aplicación, red, conformidad del dispositivo y riesgo calculado por Entra ID Protection. Es el control con mayor impacto contra los escenarios de la sección 5: aunque un atacante tenga un token forjado, Conditional Access puede exigir una señal adicional (dispositivo conforme, red conocida) que se evalúa independientemente del claim de autenticación declarado en el propio token.

Política de referencia — MFA obligatoria para roles administrativos:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Application.Read.All"

$params = @{
    displayName = "CA001 - Requerir MFA para roles administrativos"
    state = "enabledForReportingButNotEnforced"  # pasar a "enabled" tras validar
    conditions = @{
        users = @{
            includeRoles = @(
                "62e90394-69f5-4237-9190-012177145e10",  # Global Administrator
                "e8611ab8-c189-46e8-94e1-60213ab1f814",  # Privileged Role Administrator
                "fe930be7-5e62-47db-91af-98c3a49a38b1"   # User Administrator
            )
        }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{ operator = "OR"; builtInControls = @("mfa") }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Los GUID de includeRoles son Template ID fijos de los roles integrados de Entra ID: constantes globales, iguales en cualquier tenant. El de Global Administrator (62e90394-69f5-4237-9190-012177145e10) es estable y está documentado públicamente por Microsoft. Aun así, la práctica correcta antes de aplicar cualquier política en producción es no confiar en un GUID copiado de una guía sino obtenerlo directamente de tu propio tenant:

Get-MgDirectoryRoleTemplate | Where-Object DisplayName -in @("Global Administrator","Privileged Role Administrator","User Administrator") |
    Select-Object DisplayName, Id

Mantén siempre el estado inicial en enabledForReportingButNotEnforced, revisando What If y los logs de sign-in, antes de pasar a enabled.

Dos políticas complementarias, igual de prioritarias: bloquear autenticación legacy (POP/IMAP/SMTP AUTH no pueden presentar un desafío MFA por diseño de protocolo, y son la vía predilecta de password spraying) y exigir dispositivo conforme para roles administrativos:

# Bloquear autenticacion legacy
$paramsLegacy = @{
    displayName = "CA002 - Bloquear autenticacion legacy"
    state = "enabled"
    conditions = @{
        users = @{ includeUsers = @("All") }
        applications = @{ includeApplications = @("All") }
        clientAppTypes = @("exchangeActiveSync","other")
    }
    grantControls = @{ operator = "OR"; builtInControls = @("block") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $paramsLegacy

# Exigir MFA + dispositivo conforme para Global Administrator (nota: operator "AND")
$paramsDevice = @{
    displayName = "CA003 - Dispositivo conforme para roles administrativos"
    state = "enabledForReportingButNotEnforced"
    conditions = @{
        users = @{ includeRoles = @("62e90394-69f5-4237-9190-012177145e10") }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{ operator = "AND"; builtInControls = @("mfa","compliantDevice") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $paramsDevice

El operador AND exige ambos controles simultáneamente, frente al OR que se satisface con cualquiera; confundirlos es un error frecuente que anula silenciosamente el segundo control.

8. Entra ID Protection y PIM

Entra ID Protection calcula una puntuación de riesgo por sign-in y por usuario (viaje imposible, IP maliciosa conocida, credenciales filtradas, tráfico de anonimizadores), que alimenta Conditional Access mediante User risk y Sign-in risk:

Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All","AuditLog.Read.All"

Get-MgRiskyUser -Filter "riskLevel eq 'high'" |
    Select-Object UserPrincipalName, RiskLevel, RiskState, RiskLastUpdatedDateTime

Get-MgAuditLogSignIn -Filter "riskLevelDuringSignIn eq 'high'" -Top 50 |
    Select-Object UserPrincipalName, CreatedDateTime, IpAddress, RiskLevelDuringSignIn, ConditionalAccessStatus

Importante: un token forjado por Golden SAML no genera necesariamente estas señales, porque el «sign-in» puede no pasar por el flujo interactivo normal. Entra ID Protection es complementario, no sustitutivo, de la protección estructural de ADFS/Entra Connect de la sección 6.

Privileged Identity Management (PIM) aplica a Entra ID el mismo principio Just-In-Time del módulo de tiering: sin PIM, cualquier cuenta asignada de forma permanente a Global Administrator tiene ese privilegio activo 24/7, así que cualquier compromiso de su sesión concede control total de inmediato. Con PIM, la asignación es elegible (el usuario la activa cuando la necesita, con MFA y ventana limitada de 1-8 horas) en vez de activa por defecto.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

$roleId = (Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'").Id

# Asignaciones permanentes vs. elegibles (Just-In-Time)
Get-MgRoleManagementDirectoryRoleAssignmentSchedule -Filter "roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'" |
    Select-Object PrincipalId, RoleDefinitionId, Status, AssignmentType

Cualquier resultado con AssignmentType = "Assigned" (permanente) para Global Administrator debe justificarse explícitamente o migrarse a elegibilidad, salvo una cuenta de break-glass documentada y monitorizada por diseño.

9. Monitorización: logs de auditoría e inicio de sesión

Todo lo anterior es preventivo. La detección requiere consumir sistemáticamente el Audit Log (cambios de configuración: nuevas políticas de CA, roles, agentes registrados) y el Sign-in Log (quién se autenticó, desde dónde, con qué resultado), idealmente exportados a un SIEM (Microsoft Sentinel, Log Analytics) en vez de revisados manualmente.

Connect-MgGraph -Scopes "AuditLog.Read.All"

# Cambios de configuracion de sincronizacion y de Conditional Access
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Set directory sync configuration'" -Top 25 |
    Select-Object ActivityDisplayName, InitiatedBy, ActivityDateTime, Result

Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Update conditional access policy'" -Top 25 |
    Select-Object ActivityDisplayName, InitiatedBy, ActivityDateTime, Result

# Nuevos agentes PTA / Cloud Sync registrados
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Register PTA Agent'" -Top 25 |
    Select-Object ActivityDisplayName, InitiatedBy, ActivityDateTime, Result

Un patrón de alta prioridad, específicamente relevante para Golden SAML/PTA malicioso: sign-ins exitosos de cuentas administrativas donde AuthenticationRequirement marca singleFactorAuthentication pese a existir una política de CA que debería exigir MFA, o donde ConditionalAccessStatus es notApplied para una aplicación que debería estar en el ámbito de una política — cualquiera de las dos puede indicar un token sorteando la evaluación de Conditional Access.

10. Laboratorio: revisar la sincronización y crear una política de MFA

Requisitos: un tenant de Microsoft Entra ID de pruebas (Microsoft 365 Developer), con Install-Module Microsoft.Graph -Scope CurrentUser. Un laboratorio con AD + Entra Connect es opcional para la parte 1.

Paso 1 — Revisar el estado de sincronización

Connect-MgGraph -Scopes "Directory.Read.All","Domain.Read.All","Policy.ReadWrite.ConditionalAccess"

Get-MgOrganization -Property DisplayName, OnPremisesSyncEnabled, OnPremisesLastSyncDateTime | Format-List
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified

Paso 2 — Inventariar quién tiene Global Administrator

$roleId = (Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'").Id
if (-not $roleId) {
    $tid = (Get-MgDirectoryRoleTemplate | Where-Object DisplayName -eq "Global Administrator").Id
    New-MgDirectoryRole -RoleTemplateId $tid
    $roleId = (Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'").Id
}
Get-MgDirectoryRoleMember -DirectoryRoleId $roleId |
    ForEach-Object { Get-MgUser -UserId $_.Id -Property DisplayName, UserPrincipalName } |
    Select-Object DisplayName, UserPrincipalName

Paso 3 — Crear la política de Conditional Access en modo informe

$params = @{
    displayName = "LAB - CA001 Requerir MFA para Global Administrator"
    state = "enabledForReportingButNotEnforced"
    conditions = @{
        users = @{ includeRoles = @("62e90394-69f5-4237-9190-012177145e10") }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{ operator = "OR"; builtInControls = @("mfa") }
}
$policy = New-MgIdentityConditionalAccessPolicy -BodyParameter $params
$policy | Select-Object Id, DisplayName, State

Paso 4 — Simular el impacto y activar

Desde el portal (Protection > Conditional Access > Policies > What If), simula un inicio de sesión del administrador de prueba y confirma que LAB - CA001 aparece entre las políticas aplicables. Documenta el resultado, revisa el impacto real tras unas horas en modo informe y actívala:

Get-MgAuditLogSignIn -Top 20 |
    Select-Object UserPrincipalName, CreatedDateTime,
        @{N="Politicas";E={($_.AppliedConditionalAccessPolicies | Where-Object DisplayName -match "LAB").DisplayName}}

Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -BodyParameter @{ state = "enabled" }

Paso 5 — Verificación de contención

Inicia sesión con la cuenta de prueba desde un navegador sin MFA previo. El resultado esperado es un desafío explícito de segundo factor. Confirma en Get-MgAuditLogSignIn que el evento marca success con LAB - CA001 en AppliedConditionalAccessPolicies.

11. Errores comunes

  • No proteger el servidor de Entra Connect como Tier 0. El hallazgo más repetido: el servidor sincroniza correctamente, «funciona», y por eso nadie lo audita con el rigor de un DC pese a tener permisos equivalentes a DCSync.
  • Legacy auth abierto «porque una aplicación antigua lo necesita». La solución no es dejarlo abierto para todo el tenant, sino una excepción de Conditional Access acotada a esa aplicación concreta, monitorizada, mientras se planifica su migración.
  • Roles permanentes en vez de PIM. Multiplica la ventana de exposición de sesiones limitadas al día a 24/7/365 sin beneficio operativo que lo compense.
  • Confiar en MFA sin proteger ADFS/Entra Connect. MFA protege el factor de autenticación del usuario; no protege contra un token forjado que nunca pasó por un desafío real. Son capas distintas y ambas necesarias.
  • No rotar nunca la clave de AZUREADSSOACC ni el certificado de ADFS. Sin rotación periódica documentada, cualquier compromiso histórico no detectado sigue siendo válido indefinidamente.
  • Ignorar los agentes PTA/Cloud Sync como superficie independiente. La atención se centra en «el Entra Connect principal», olvidando que cada agente adicional tiene el mismo nivel de confianza y el mismo requisito Tier 0.

12. Ejercicio

En tu tenant de Microsoft Entra ID de pruebas (no en producción):

  1. Documenta en una tabla propia qué método de autenticación híbrida usarías para tres escenarios ficticios (pyme sin infraestructura redundante; empresa mediana con alta disponibilidad exigida; gran corporación con requisito regulatorio de smartcard on-premises), justificando la elección y el riesgo residual.
  2. Con Get-MgDirectoryRoleMember, enumera quién tiene Global Administrator en tu tenant de pruebas y clasifica cada asignación como permanente o elegible vía PIM.
  3. Crea la política de Conditional Access del laboratorio, valídala con «What If» y actívala. Documenta con capturas el desafío de MFA resultante.
  4. Redacta, en no más de una página, un procedimiento de respuesta a incidente para «sospecha de compromiso del servidor de Entra Connect»: aislamiento de red, rotación de AZUREADSSOACC, rotación del certificado ADFS si aplica, revisión de reglas de sincronización y de asignaciones de rol recientes.
  5. Explica, con tus propias palabras, por qué el riesgo de sign-in (riskLevelDuringSignIn) por sí solo no habría detectado un Golden SAML si el atacante tuviera el certificado de firma de ADFS.

Preguntas frecuentes

¿Es más seguro ADFS que Password Hash Sync?

No, generalmente es al revés. ADFS mantiene la validación 100% on-premises, pero introduce un punto único de fallo crítico: el certificado de firma de tokens. Si se compromete, el impacto es total e instantáneo (Golden SAML) sin que el atacante necesite ninguna contraseña. PHS distribuye la validación a la nube y elimina esa dependencia de un componente on-premises único. Microsoft recomienda PHS (con Seamless SSO) como opción por defecto para la mayoría de escenarios, reservando ADFS para requisitos de negocio muy específicos.

¿Desactivar la sincronización híbrida elimina el riesgo?

Elimina el riesgo de este módulo, pero a costa de perder la gestión centralizada de identidades, lo que en la práctica suele aumentar otros riesgos (cuentas duplicadas, contraseñas no sincronizadas, bajas de empleados ejecutadas dos veces). La recomendación no es eliminar la sincronización, sino protegerla con el rigor de un activo Tier 0.

¿Con Security Defaults ya no necesito Conditional Access?

Security Defaults es un conjunto gratuito de protecciones básicas (MFA general, bloqueo de legacy auth) para organizaciones sin licencia P1/P2. Es mejor que nada, pero es una política única no personalizable: no distingue por rol ni aplicación, y no integra señales de riesgo. Con licencia P1/P2, Conditional Access sustituye a Security Defaults (no se combinan) porque ofrece control granular real.

¿AZUREADSSOACC aparece en Domain Admins o algún grupo privilegiado?

No, y ahí está parte del riesgo: al ser una cuenta de equipo ordinaria, pasa desapercibida en auditorías centradas solo en pertenencia a grupos administrativos. Su sensibilidad viene de su clave Kerberos y de la confianza que Entra ID deposita en tickets emitidos para ella, no de su pertenencia a ningún grupo.

¿PIM en Entra ID es lo mismo que PAM en AD on-premises?

Son conceptualmente equivalentes (activación Just-In-Time) pero productos técnicamente distintos. PIM gestiona roles de Entra ID (y, en su edición para grupos, pertenencia a grupos de Entra ID/Microsoft 365). La gestión Just-In-Time de grupos de AD on-premises como Domain Admins se aborda con herramientas como Microsoft Identity Manager PAM o soluciones de terceros. Una organización madura en híbrido necesita ambas capas, aunque el principio —nada de privilegio permanente— sea idéntico.

«Microsoft Entra Connect Sync has extensive access to your on-premises Active Directory and, depending on your configuration, potentially your Microsoft Entra organization too, making it a high-value target for attackers. […] Treat the Microsoft Entra Connect server with the same level of security as a domain controller, both in terms of the security of the host and the practices used when administering it.»

— Microsoft, «Microsoft Entra Connect: Accounts and permissions» / «Protect against on-premises to cloud attacks with Microsoft Entra», Microsoft Learn (learn.microsoft.com/entra/identity/hybrid/connect/reference-connect-accounts-permissions, learn.microsoft.com/entra/architecture/protect-m365-from-on-premises-attacks).