AZ-305
Deep Dive
El AZ-305 no pregunta "qué es Entra ID" — pregunta cuándo y cómo diseñar la solución de identidad: cuántos tenants, qué método de autenticación híbrida, cuándo usar B2B vs External ID, y qué tipo de identidad asignar a cada workload. Aquí dominamos esos criterios de decisión.
Contenido
🏛️Jerarquía de gobernanza Azure — herencia de Policies y RBAC
Policies y RBAC asignados en niveles superiores se heredan hacia abajo. Pasa el cursor sobre un nodo para ver su cadena de herencia completa.
⬇️ Herencia descendente
RBAC y Policies en Root MG aplican a TODOS los niveles. Un hijo no puede anular lo que el padre impone con un efecto Deny.
🔒 Scope de asignación
Asignar en el nivel más alto posible reduce el overhead de gestión. 1 policy en Root MG = cobertura de todo el tenant.
🏷️ Tags NO heredan auto
A diferencia de RBAC/Policy, tags en un RG NO se propagan a los recursos hijos. Se necesita Azure Policy con efecto modify.
Un tenant de Microsoft Entra ID es el límite de identidad y administración de la organización. La regla de diseño por defecto es un solo tenant por organización — múltiples tenants multiplican la complejidad de licencias, Conditional Access, B2B y administración.
Para el examen: un tenant puede tener múltiples suscripciones, pero cada suscripción confía en exactamente un tenant. Mover una suscripción de tenant rompe RBAC, managed identities y Key Vault access policies.
Cuándo un solo tenant (default)
Cuándo múltiples tenants (excepción)
🔐Árbol de decisión — Método de autenticación híbrida
PHS · PTA · ADFS + herramienta de sincronización
Pregunta 1
¿Existe un requisito de seguridad o compliance que prohíba almacenar hashes de contraseña en la nube de Microsoft?
💡 PHS almacena un hash del hash en Entra ID. Si la política lo permite (mayoría de casos) → PHS. Si dicen "la contraseña no puede salir del datacenter ni en forma de hash" → continúa.
Cuando existe Active Directory on-premises, Entra Connect (o Cloud Sync) sincroniza identidades a la nube. La decisión clave del AZ-305 es dónde se valida la contraseña. Tres opciones:
| Método | Dónde se valida | Infraestructura extra | Cuándo elegirlo |
|---|---|---|---|
| Password Hash Sync (PHS) | En la nube — Entra ID valida el hash sincronizado | Ninguna (solo Entra Connect) | Default recomendado. Más simple, funciona aunque on-prem esté caído, habilita leaked credential detection. |
| Pass-through Auth (PTA) | On-premises — agentes PTA validan contra los DCs en tiempo real | 2-3 agentes PTA en servidores on-prem | Política de seguridad prohíbe almacenar hashes en la nube, pero quieres evitar la complejidad de ADFS. Login falla si on-prem cae (mitigar con PHS como respaldo). |
| Federación (ADFS) | On-premises — granja ADFS emite tokens | Granja ADFS + WAP + certificados (alta complejidad) | Solo si necesitas: smartcards/MFA de terceros on-prem, o requisito de que la autenticación nunca toque la nube. Microsoft lo desaconseja para casos nuevos. |
Entra Connect Sync vs Cloud Sync
Entra Domain Services (cuándo)
Para aplicaciones legacy que requieren Kerberos/NTLM/LDAP y se migran a Azure sin poder reescribirse. Entra DS provee un dominio administrado (sin DCs que gestionar) sincronizado desde Entra ID.
Entra ID B2B (colaboración)
Microsoft Entra External ID (clientes)
Regla de oro para el examen
Partners/empleados de otra empresa que colaboran contigo → B2B (mismo tenant, usuarios guest). Clientes/consumidores de tu producto → External ID (antes B2C) (tenant separado, login social). Si la pregunta menciona "social identity providers" o "millones de clientes", la respuesta es External ID (Azure AD B2C solo en soluciones heredadas).
| Tipo | Quién gestiona credenciales | Cuándo usarla |
|---|---|---|
| Managed Identity (system-assigned) | Azure — sin secretos, ciclo de vida atado al recurso | Default para recursos Azure que acceden a otros servicios Azure (VM → Key Vault, App Service → SQL). Se elimina con el recurso. |
| Managed Identity (user-assigned) | Azure — sin secretos, ciclo de vida independiente | Múltiples recursos comparten la misma identidad (fleet de VMs, slots de App Service), o pre-aprovisionas permisos antes de crear recursos. |
| Service Principal | Tú — secreto o certificado que rota manualmente | Apps fuera de Azure (CI/CD externo, on-premises) o multi-tenant. Última opción si Managed Identity no es viable. |
| Workload Identity Federation | Nadie — federación OIDC sin secretos | GitHub Actions, Kubernetes externo u otro IdP que asume un service principal SIN secretos almacenados. Preferido sobre service principal + secreto. |
Principio de diseño
Jerarquía de preferencia: Managed Identity > Workload Identity Federation > Service Principal con certificado > Service Principal con secreto. Si el escenario dice "eliminar secretos almacenados" o "sin gestión de credenciales", la respuesta casi siempre es Managed Identity.
| El escenario dice... | Diseña con... |
|---|---|
| Mínima infraestructura on-prem, login resiliente aunque caiga el datacenter | Password Hash Sync |
| Las contraseñas (ni sus hashes) no pueden salir de on-premises | Pass-through Authentication (+ PHS como fallback de DR si lo permiten) |
| MFA con smartcards on-premises / control total del flujo de tokens | Federación con ADFS |
| App legacy con Kerberos/LDAP migrada a Azure, sin gestionar DCs | Entra Domain Services |
| Partners externos acceden a apps internas con sus propias credenciales | Entra B2B (guests + access reviews) |
| App de consumidores con login social a escala de millones | Microsoft Entra External ID (antes Azure AD B2C) |
| App Service necesita leer secretos de Key Vault sin credenciales | Managed Identity (system-assigned) |
| Pipeline de GitHub Actions despliega a Azure sin secretos guardados | Workload Identity Federation |
| Sincronizar varios bosques AD desconectados con agentes ligeros | Entra Cloud Sync |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa con AD on-premises migra a Azure. Requisitos: (1) los usuarios deben poder iniciar sesión en apps cloud aunque el datacenter on-premises esté caído, (2) mínima infraestructura adicional, (3) detección de credenciales filtradas. ¿Qué método de autenticación híbrida recomiendas?
Pon a prueba lo que aprendiste con preguntas originales del examen AZ-305.
Iniciar simulacro AZ-305Sin límite de simulacros con plan Pro
Inicia sesión para llevar tu progreso.