AZ-104
Deep Dive
El directorio central de identidades en Azure. El AZ-104 evalúa la administración práctica: crear usuarios, grupos, dominios, sincronizar con AD on-premises y gestionar licencias.
Contenido
Microsoft Entra ID es el servicio de identidad y acceso basado en la nube de Microsoft (anteriormente denominado Azure Active Directory; el examen AZ-104 usa exclusivamente el nombre Microsoft Entra ID). Es el directorio central que autentica y autoriza acceso a Azure, Microsoft 365, aplicaciones SaaS y apps propias.
No confundir con AD DS (Active Directory Domain Services) — son productos distintos con protocolos distintos.
| Dimensión | AD DS (on-premises) | Microsoft Entra ID |
|---|---|---|
| Protocolo | LDAP, Kerberos, NTLM | OAuth 2.0, OIDC, SAML 2.0, WS-Fed |
| Estructura | OUs, GPOs, árboles de dominio | Flat: usuarios, grupos, apps, dispositivos |
| Dispositivos | Domain join (Windows) | Azure AD Join, Hybrid Join, Register |
| MFA nativo | No (requiere NPS Extension) | Sí, integrado |
| Conditional Access | No | Sí |
| Acceso externo | Trusts entre dominios | B2B / B2C nativos |
| Escalado | Manual (agregar DCs) | Automático, global, 99.99% SLA |
| Administración | ADUC, PowerShell (RSAT) | Azure Portal, MS Graph, Entra admin center |
Tenant (directorio)
Instancia dedicada de Entra ID para tu organización. Se crea al registrarte en Microsoft. Tiene un ID único (GUID) y un dominio inicial *.onmicrosoft.com.
Una org puede tener múltiples tenants (ej: uno prod, uno dev). Un tenant puede tener múltiples suscripciones.
Suscripción Azure
Unidad de facturación y límite de recursos de Azure. Cada suscripción confía en exactamente UN tenant de Entra ID para autenticación.
Puedes mover una suscripción a otro tenant. El tenant es padre de la suscripción, no al revés.
Management Group
Contenedor que agrupa múltiples suscripciones. Permite aplicar políticas y RBAC a todas con una sola asignación. Heredan del tenant root.
Máximo 6 niveles de profundidad. Root Management Group existe en cada tenant automáticamente.
Tipos de usuario en Entra ID
Member (miembro)
Empleados de la organizaciónUsuario creado directamente en el tenant. Cuenta con dominio propio (ej: user@contoso.com). Permisos por defecto más amplios que los guest.
Guest (invitado)
Partners, consultores, auditoresUsuario externo invitado via B2B. Su cuenta existe en otro tenant o proveedor (Google, email). El UPN incluye #EXT# ej: user_extdomain.com#EXT#@contoso.onmicrosoft.com.
Service Principal
Aplicaciones que necesitan acceder a APIs de AzureIdentidad para una aplicación registrada en Entra ID. Similar a una "cuenta de servicio" para apps. Tiene Client ID + Client Secret o certificado.
Creación y gestión de usuarios — admin tasks
Azure Portal
Entra ID → Users → New user → Create user / Invite external user
Uno a uno. Para bulk: no recomendado.
Bulk operations (CSV)
Users → Bulk operations → Bulk create / Bulk invite / Bulk delete → descargar template CSV, rellenar, subir
Hasta 50.000 usuarios por archivo. Procesamiento asíncrono.
Microsoft Graph API
POST /users con body JSON. Requiere permiso User.ReadWrite.All en la app.
Sin límite práctico. Ideal para automatización.
PowerShell (Az module)
New-AzADUser o (via Graph SDK) New-MgUser -DisplayName ... -MailNickname ...
Scriptable. Se puede combinar con CSV y bucles.
Propiedades clave de usuario
Security Group
Controlar acceso a recursos (RBAC, apps). NO puede tener dirección de email.
Miembros permitidos
Usuarios, otros grupos, service principals, devices
Microsoft 365 Group
Colaboración: tiene buzón compartido, SharePoint, Teams. Visible en Exchange.
Miembros permitidos
Solo usuarios (no service principals ni devices)
Tipos de membresía
Assigned (manual)
El admin agrega/quita miembros manualmente. Control total, pero no escala bien.
Cuándo: Grupos pequeños, membresía estable, acceso excepcional.
Dynamic User
Membresía automática basada en atributos del usuario (department, jobTitle, country, etc.). Usa reglas con sintaxis como: (user.department -eq "Finance").
Cuándo: Licencias automáticas, acceso basado en departamento/rol HR.
Dynamic Device
Como Dynamic User pero para dispositivos. Reglas sobre atributos del device (OS, compliance, etc.).
Cuándo: Intune policies automáticas según tipo de dispositivo.
El tier de Entra ID determina qué funciones están disponibles. Crítico para el examen saber qué requiere P1 vs P2.
| Funcionalidad | Free | P1 | P2 |
|---|---|---|---|
| Usuarios y grupos básicos | ✓ | ✓ | ✓ |
| SSO a apps SaaS | ✓ | ✓ | ✓ |
| MFA por usuario (legacy) | ✓ | ✓ | ✓ |
| Conditional Access policies | ✗ | ✓ | ✓ |
| Dynamic Groups | ✗ | ✓ | ✓ |
| SSPR (self-service password reset) | ✗ | ✓ | ✓ |
| Entra Connect (hybrid) | ✗ | ✓ | ✓ |
| App Proxy (on-prem apps vía cloud) | ✗ | ✓ | ✓ |
| Sign-in logs (retención 30 días) | ✗ | ✓ | ✓ |
| Identity Protection (risk policies) | ✗ | ✗ | ✓ |
| Privileged Identity Management (PIM) | ✗ | ✗ | ✓ |
| Access Reviews | ✗ | ✗ | ✓ |
| Entitlement Management | ✗ | ✗ | ✓ |
Asignación de licencias — buenas prácticas
Agregar dominio personalizado
UPN Suffix y alternates
El UPN (User Principal Name) es el identificador de login. El suffix es el dominio después del @.
Trampa: No puedes eliminar el dominio *.onmicrosoft.com inicial. Y no puedes cambiar el dominio de un tenant ya creado.
Entra Connect sincroniza identidades desde Active Directory Domain Services on-premises hacia Entra ID. Es el puente del escenario híbrido.
Modos de sincronización
Password Hash Sync (PHS)
Sincroniza hash de contraseñas de AD DS a Entra ID. El usuario autentica directamente contra Entra ID. Modo más sencillo y con mejor resiliencia (funciona sin conectividad on-prem).
✓ Recomendado para la mayoría
Pass-through Authentication (PTA)
Entra ID reenvía la autenticación al AD DS on-premises en tiempo real via agentes ligeros. La contraseña nunca sale del dominio. Requiere conectividad continua.
✓ Si por compliance el hash no puede salir
Federation (AD FS)
Toda autenticación redirige al AD FS on-premises. Máximo control y opciones. Mayor complejidad: requiere infraestructura AD FS en alta disponibilidad.
⚠ Solo si hay requisitos muy específicos
Objeto sincronizado vs cloud-only
Writeback — dirección inversa
Password Writeback: SSPR escribe la nueva contraseña de vuelta al AD DS on-prem. Requiere P1.
Group Writeback: Grupos de M365 se sincronizan de vuelta a AD DS como grupos de distribución.
Device Writeback: Dispositivos registrados en Entra ID se escriben de vuelta a AD DS.
Las Administrative Units (AUs) permiten restringir el alcance de roles de Entra ID a un subconjunto de usuarios, grupos o dispositivos. Un User Administrator global puede gestionar TODOS los usuarios; con AUs puedes crear un "User Administrator solo para el departamento de RRHH".
Cómo configurar
Roles scopeables a AU
Limitaciones importantes
Caso real: empresa con 4 regiones
Creas 4 AUs (EMEA, AMERICAS, APAC, LATAM). Cada AU tiene un helpdesk local con rol "Helpdesk Administrator" scopeado solo a su AU. El helpdesk de LATAM solo puede resetear contraseñas de los 200 usuarios de su AU, no puede ver ni tocar los 2.000 usuarios globales.
B2B Collaboration permite invitar a usuarios externos (partners, auditores, clientes) para que accedan a recursos de tu tenant usando sus propias credenciales (Entra ID, Google, email OTP).
Flujo de invitación B2B
Cross-tenant access settings
Inbound (quién puede acceder a TU tenant):
• B2B collaboration: qué usuarios/grupos de otros tenants pueden ser invitados
• B2B direct connect: acceso sin invitación a recursos compartidos (ej: Teams Connect)
• Trust settings: confiar en MFA, dispositivos compliant del tenant externo
Outbound (qué pueden hacer TUS usuarios en otros tenants):
• Controlar si tus usuarios pueden ser invitados en tenants externos
Restricciones de guests por defecto
Los guests tienen permisos de directorio restringidos por defecto:
• No pueden enumerar todos los usuarios del directorio
• No pueden ver grupos a los que no pertenecen
• No pueden registrar apps (a menos que se permita explícitamente)
• Configurable en Entra ID → External Identities → External collaboration settings
| Proveedor de identidad | Descripción | Flujo de autenticación |
|---|---|---|
| Entra ID (otro tenant) | El usuario tiene cuenta en otro tenant de Azure | Redirección al tenant origen → autenticación → token SAML/OIDC → acceso |
| Cuenta Microsoft (MSA) | Outlook, Hotmail, Live | Redirección a login.live.com → autenticación → token → acceso |
| Gmail, Google Workspace | Federated con Google Identity → OAuth → token → acceso | |
| Email OTP | Cualquier email sin Entra ID ni Google | Azure envía código de 6 dígitos al email → usuario ingresa → acceso temporal |
| SAML/WS-Fed (custom) | IdP corporativo propio con SAML | Redirección al IdP federado configurado → SAML assertion → acceso |
El tipo de join determina cómo el dispositivo se identifica ante Entra ID, qué políticas recibe y qué puede hacer el usuario desde ese dispositivo.
| Dimensión | Entra ID Registered | Entra ID Joined | Hybrid Entra Joined |
|---|---|---|---|
| Escenario | BYOD — dispositivo personal | Cloud-only — dispositivos corporativos nuevos | Dispositivos ya unidos a AD DS on-prem |
| OS soportados | Windows 10+, iOS, Android, macOS | Windows 10+ y 11 | Windows 10/11 (y Server 2016+) |
| Requiere | Solo registrar — el usuario añade su cuenta corporativa | Windows Out-of-box Experience (OOBE) o autopilot | Entra Connect + dominio AD DS activo |
| Login con | Cuenta personal del dispositivo + cuenta corporativa registrada | Cuenta de Entra ID como principal del dispositivo | Cuenta de dominio AD DS (accede a recursos cloud via token) |
| Políticas de Intune | Parcial (MDM enrollment opcional) | Completo (Intune MDM + MAM) | Completo si está enrolado en Intune |
| SSO a recursos cloud | Con app Authenticator o SSPR registrado | Nativo vía PRT (Primary Refresh Token) | Nativo vía PRT (requiere line of sight a DC o Entra Connect) |
| Acceso a recursos on-prem | Con VPN corporativa | Solo cloud (sin domain join on-prem) | Sí — tiene kerberos ticket del AD DS |
| Caso típico | Empleado usa su iPhone o Mac personal para email corp. | Empresa nativa cloud sin AD DS on-prem | Empresa con legacy apps on-prem + quiere acceso a cloud |
Primary Refresh Token (PRT)
El PRT es un token especial emitido por Entra ID a dispositivos Entra Joined e Hybrid Joined. Dura hasta 14 días y se renueva automáticamente. Permite SSO silencioso a todas las apps integradas con Entra ID sin re-autenticar. Es como el "TGT" de Kerberos pero para el mundo cloud. Si un CA policy requiere un dispositivo compliant, se verifica usando el PRT.
Microsoft ofrece dos herramientas para sincronizar AD DS on-premises con Entra ID. El AZ-104 evalúa cuándo usar cada una.
| Dimensión | Entra Connect (clásico) | Entra Connect Cloud Sync |
|---|---|---|
| Arquitectura | Servidor de sincronización completo (Windows Server) con motor de sync interno | Agente ligero (~150 MB) instalado en Windows Server, lógica de sync en la nube |
| Múltiples bosques | Soporta múltiples bosques pero mismo servidor | Múltiples bosques desconectados — un agente por bosque, independientes |
| Staging server (HA) | Sí — puedes tener un servidor en modo staging para failover | Múltiples agentes en el mismo bosque para HA automático |
| Password hash sync | Sí | Sí |
| Password writeback | Sí (configurado en wizard) | Sí (vía configuración en cloud portal) |
| Group writeback | Sí — M365 Groups → AD DS grupos de distribución | Sí (v2 — grupos de seguridad también) |
| Exchange hybrid | Sí — atributos Exchange full | Soporte limitado — no todos los atributos Exchange |
| Custom sync rules | Sí — muy flexible con Synchronization Rules Editor | Limitado — transformaciones básicas en portal |
| On-demand provisioning | No (sync cycle completo) | Sí — sincronizar usuario específico bajo demanda para testing |
| Mejor para | Entornos complejos: Exchange hybrid, custom sync rules, bosque único grande | Escenarios simples, múltiples bosques desconectados, nueva implementación |
¿Cuál elegir? — árbol de decisión rápido
→ ¿Tienes Exchange on-premises y necesitas hybrid? → Entra Connect clásico
→ ¿Tienes múltiples bosques AD DS desconectados? → Cloud Sync
→ ¿Necesitas reglas de sincronización complejas o transformaciones? → Entra Connect clásico
→ ¿Nueva implementación sin requerimientos específicos de Exchange? → Cloud Sync
→ ¿Necesitas migrar de Entra Connect clásico gradualmente? → Puedes coexistir, Cloud Sync para nuevos OUs/bosques
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
¿Cuál es la diferencia principal entre Microsoft Entra ID y Active Directory Domain Services (AD DS) tradicional?