Microsoft Entra ID, Tipos de Identidad y Entornos Híbridos

radio_button_uncheckedshort_text 1. Introducción

Los primeros sistemas corporativos de identidad nacieron en un mundo en el que usuarios, equipos y servidores permanecían, en gran parte, dentro de la red de la empresa. Los directorios locales, especialmente Active Directory Domain Services , hicieron posible centralizar cuentas, equipos, grupos y políticas. La adopción de servicios en la nube, dispositivos móviles, aplicaciones SaaS y trabajo remoto cambió ese escenario: la identidad necesitaba acompañar al usuario y a la aplicación más allá del dominio físico de la organización. Microsoft Entra ID surgió de esa transición, inicialmente como Windows Azure Active Directory , luego Azure Active Directory y, desde 2023, con la marca actual.

Comprender esa evolución ayuda al lector a percibir por qué la identidad no es solo “crear usuarios”. Una plataforma moderna de IAM debe representar personas, dispositivos, aplicaciones, automatizaciones, socios y agentes de IA; autenticar cada entidad; emitir tokens ; aplicar políticas; registrar actividades; y mantener el ciclo de vida coherente. Para la sociedad, ese modelo sostiene la colaboración remota, los servicios digitales, la educación en línea, la salud conectada, el gobierno digital y las transacciones financieras con mayor control y trazabilidad.

A lo largo de este capítulo, la pregunta central será: ¿cómo representa, conecta y gobierna una organización entidades tan diferentes sin multiplicar credenciales, privilegios y puntos ciegos? La respuesta comienza en el tenant de Microsoft Entra ID , pasa por los objetos de identidad y llega a los escenarios híbridos y externos. Entender esas relaciones evita la memorización superficial y permite resolver preguntas del SC-900 mediante razonamiento.

Idea guía del capítulo

Una identidad es la representación de una entidad; una entidad de seguridad es una identidad capaz de recibir permisos; un tenant es la frontera lógica en la que esas identidades, políticas, consentimientos y registros se administran.

radio_button_uncheckedshort_text 2. Breve evolución: del directorio local a Microsoft Entra

Active Directory Domain Services , introducido con Windows 2000 Server, consolidó un modelo de directorio empresarial basado en dominios, bosques, unidades organizativas, controladores de dominio y protocolos como Kerberos y LDAP. Ese modelo sigue siendo esencial para muchas organizaciones, sobre todo en estaciones Windows, servidores locales, directivas de grupo y aplicaciones heredadas. Sin embargo, fue diseñado para un entorno en el que el dominio corporativo y la conectividad con controladores de dominio eran referencias centrales.

Cuando Microsoft 365 y Azure comenzaron a alojar aplicaciones y datos fuera de la red local, se hizo necesario un servicio de identidad nativo de la nube. Windows Azure Active Directory se lanzó como ese servicio. A pesar del nombre histórico, no era simplemente “un Active Directory alojado”: su arquitectura se construyó para autenticación basada en Internet, API , aplicaciones modernas, tokens y múltiples tenants. El nombre Azure Active Directory fue sustituido por Microsoft Entra ID para reducir esa confusión y posicionar el producto dentro de una familia más amplia de identidad y acceso.

El cambio de nombre no eliminó integraciones ni alteró automáticamente licencias y configuraciones. Reforzó una diferencia conceptual importante para el examen: AD DS es un servicio de directorio de dominio tradicional; Microsoft Entra ID es un servicio de administración de identidad y acceso basado en la nube. Pueden coexistir y formar una identidad híbrida, pero no son el mismo producto.

radio_button_uncheckedshort_text 3. La familia Microsoft Entra

Microsoft Entra es la familia de productos de Microsoft orientada a identidad, acceso, gobernanza y seguridad de las conexiones. Entra ID es su producto fundamental: autentica usuarios y cargas de trabajo, emite tokens , aplica políticas y mantiene objetos del directorio. Otros productos amplían ese núcleo para necesidades específicas, como gobernanza del ciclo de vida, colaboración externa, acceso de red, identidades de aplicaciones y agentes de IA.

Enfoque del SC-900

El examen no exige administrar en profundidad todos los productos. Exige reconocer su finalidad y, en este capítulo, comprender la función de Entra ID y los tipos de identidad que representa.

radio_button_uncheckedshort_text 4. Qué es Microsoft Entra ID

Microsoft Entra ID es el servicio de administración de identidad y acceso basado en la nube de Microsoft. Conecta a personas e identidades no humanas con aplicaciones, dispositivos, datos y recursos. Cuando una entidad intenta acceder a un recurso protegido, Entra ID puede autenticar esa entidad, evaluar políticas, emitir un token con notificaciones y permitir que el recurso tome una decisión de autorización.

El servicio lo usan directamente Microsoft 365 , Azure y miles de aplicaciones SaaS. También puede proteger aplicaciones personalizadas, API internas y soluciones multinube. Esto significa que Entra ID no se limita a “iniciar sesión en el portal de Azure ”: funciona como proveedor de identidades, directorio, emisor de tokens , motor de políticas y fuente de señales para decisiones de acceso.

Algunas capacidades dependen de licencias específicas, pero la lógica conceptual permanece: los objetos representan identidades; las credenciales y los métodos de autenticación comprueban quién o qué solicita acceso; los roles, permisos y políticas controlan el acceso; y los registros anotan los eventos. Servicios como Acceso condicional , Identity Protection , PIM y gobernanza se profundizarán en capítulos posteriores.

radio_button_uncheckedshort_text 5. Tenant, directorio, dominios y suscripciones

5.1 Tenant o inquilino

Un tenant es una instancia dedicada y aislada de Microsoft Entra ID asociada a una organización. Contiene objetos, dominios, configuraciones, políticas, registros de aplicaciones y registros de actividad. Cada tenant posee un identificador globalmente único, el tenant ID, normalmente representado por un GUID. Ese identificador es diferente del nombre del tenant y de los dominios usados para el inicio de sesión.

Al crear un tenant, la organización recibe un dominio inicial, como contoso.onmicrosoft.com. Se pueden agregar y verificar dominios personalizados, como contoso.com. La verificación demuestra que la organización controla el dominio DNS y permite utilizarlo en nombres de inicio de sesión, como ana@contoso.com. El dominio no sustituye al tenant ID y una misma organización puede administrar más de un tenant por razones jurídicas, geográficas, técnicas o de segregación.

5.2 Directorio

En el uso cotidiano, “tenant” y “directorio” aparecen casi como sinónimos. La diferencia de énfasis es útil: tenant destaca la instancia aislada y la frontera administrativa; directorio destaca el conjunto organizado de objetos y atributos existentes en esa instancia. Un objeto posee un object ID propio dentro del tenant, mientras que determinados tipos también tienen identificadores específicos, como el application (client) ID de una aplicación.

5.3 Un tenant y una suscripción de Azure no son lo mismo

Una suscripción de Azure es una frontera de facturación, cuotas y organización de recursos. Para autenticación y autorización, la suscripción confía en un tenant de Microsoft Entra ID . Un tenant puede estar asociado a varias suscripciones, y cada suscripción mantiene una relación con un tenant en un momento dado. Crear una suscripción no significa crear una nueva identidad para cada usuario; las identidades del tenant reciben roles sobre suscripciones, grupos de recursos o recursos específicos mediante Azure RBAC .

Trampa de examen

Tenant, suscripción y dominio son conceptos relacionados pero distintos. El tenant contiene identidades; la suscripción contiene recursos y facturación; el dominio proporciona un espacio de nombres y debe verificarse.

radio_button_uncheckedshort_text 6. Tipos de identidad y entidades de seguridad

Una identidad es una representación digital de una entidad. En Microsoft Entra ID , esa entidad puede ser una persona, un dispositivo, una aplicación, un servicio, una automatización o un agente de IA. Para que una identidad reciba permisos y participe en decisiones de acceso, debe representarse como una entidad de seguridad apropiada. Los usuarios son user principals; las aplicaciones y varias identidades no humanas se representan mediante entidades de servicio o tipos especializados construidos sobre esa infraestructura.

La clasificación ayuda a elegir mecanismos de autenticación y gobernanza. Las personas pueden usar MFA y métodos sin contraseña; los dispositivos construyen confianza de dispositivo; las cargas de trabajo deben evitar cuentas humanas y secretos estáticos; los agentes de IA necesitan identidad propia, un patrocinador, permisos específicos y una traza de auditoría. Tratar todas esas entidades como “usuarios” lleva a credenciales compartidas, privilegios excesivos y poca trazabilidad.

radio_button_uncheckedshort_text 7. Usuarios, grupos e identidades externas

7.1 Objetos de usuario

Un objeto de usuario representa a una persona o, en casos heredados que deben evitarse, una cuenta utilizada por un proceso. El objeto contiene atributos como nombre, UPN, dirección de correo electrónico, cargo, departamento, estado, métodos de autenticación, grupos y roles. El origen de la identidad puede ser exclusivamente en la nube, sincronizado desde un Active Directory local o externo.

Miembro e Invitado son propiedades de tipo de usuario, no una prueba absoluta de vínculo laboral u origen. Un usuario invitado normalmente tiene restricciones predeterminadas y se crea mediante colaboración B2B, pero los administradores pueden cambiar propiedades y conceder acceso. La seguridad depende de políticas, grupos, roles y revisiones, no solo de la etiqueta.

7.2 Grupos

Los grupos simplifican la administración al permitir que permisos, licencias y acceso a aplicaciones se asignen a un conjunto de identidades. Los grupos de seguridad se usan principalmente para el control de acceso. Los grupos de Microsoft 365 también proporcionan funciones de colaboración, como buzón, calendario y espacio compartido. La pertenencia puede asignarse manualmente o, en ediciones compatibles, calcularse dinámicamente en función de atributos.

La mejor práctica es conceder acceso a grupos siempre que tenga sentido, en lugar de crear muchas asignaciones individuales. Sin embargo, los grupos también necesitan propietarios, criterios de pertenencia y revisión. Un grupo dinámico con una regla incorrecta puede conceder acceso masivo; un grupo sin propietario puede mantener a usuarios dados de baja durante demasiado tiempo.

Principio operativo

El usuario es la identidad individual; el grupo es un mecanismo de organización y asignación. En general, el grupo no “inicia sesión”, pero puede recibir permisos que serán efectivos para sus miembros.

radio_button_uncheckedshort_text 8. Identidades de dispositivo

Una identidad de dispositivo es un objeto en Microsoft Entra ID que representa un equipo. Aporta información usada en decisiones de acceso y administración, como ID del dispositivo, propietario, estado de registro, sistema operativo y vínculo con servicios de administración. La identidad de dispositivo no sustituye la identidad del usuario; añade contexto. Una política puede exigir que el usuario esté autenticado y que el dispositivo esté registrado, administrado o en cumplimiento.

Estos estados se confunden con frecuencia con la administración. Registrar o unir un dispositivo crea una identidad y una relación de confianza; administrarlo con Microsoft Intune implica políticas, configuraciones y evaluación de cumplimiento. Los conceptos pueden trabajar juntos, pero no son sinónimos.

Punto para el examen

Un dispositivo registrado está asociado a Entra ID; un dispositivo unido pertenece al modelo de inicio de sesión de la organización; un dispositivo hybrid joined mantiene una relación con AD DS y Entra ID. El estado del dispositivo puede ser una señal de acceso.

radio_button_uncheckedshort_text 9. Aplicaciones, registros y aplicaciones empresariales

Las aplicaciones también necesitan identidad. Cuando un desarrollador registra una aplicación en Microsoft Entra ID , se crea un application object en el tenant de origen. Ese objeto funciona como definición o blueprint: contiene identificadores, URI de redirección, tipos de cuenta admitidos, permisos solicitados y otros metadatos usados por la plataforma de identidad.

Para que la aplicación se use en un tenant, existe una representación local denominada entidad de servicio (service principal). En el centro de administración, el área Registros de aplicaciones muestra los application objects del tenant de origen; el área Aplicaciones empresariales muestra las entidades de servicio, es decir, instancias locales de aplicaciones usadas en el tenant. Esta distinción es una de las más importantes para los administradores y aparece en preguntas conceptuales.

En una aplicación de un solo tenant, el uso se restringe al tenant previsto. En una aplicación multitenant, otros tenants pueden consentir su uso; cada tenant consumidor crea su propia entidad de servicio, con consentimientos, asignaciones y políticas locales. Así, un único application object puede originar varias entidades de servicio.

radio_button_uncheckedshort_text 10. Entidades de servicio e identidades de carga de trabajo

Una carga de trabajo, o workload, es software que ejecuta una función: aplicación web, API , servicio en segundo plano, canalización, función sin servidor, máquina virtual, contenedor o automatización. Una workload identity es la identidad que usa ese software para autenticarse y acceder a recursos. En Microsoft Entra , las aplicaciones, las entidades de servicio y las identidades administradas forman parte de este universo.

Una entidad de servicio puede autenticarse con secreto, certificado, credencial federada u otro mecanismo compatible. Una vez autenticada, recibe un token y actúa con los permisos concedidos. Como no hay una persona escribiendo credenciales, los controles son diferentes: rotación de certificados, restricción de ámbito, revisión de permisos, registros de inicios de sesión de entidades de servicio y eliminación de credenciales innecesarias se vuelven fundamentales.

Usar una cuenta de usuario para una automatización es una práctica frágil. La contraseña puede expirar, MFA puede interrumpir el proceso, la cuenta puede acumular permisos y los registros dejan de distinguir persona y carga de trabajo. Una identidad de carga de trabajo hace explícito el propósito y posibilita una gobernanza independiente.

radio_button_uncheckedshort_text 11. Identidades administradas

Las identidades administradas para recursos de Azure resuelven un problema recurrente: cómo permitir que el código acceda a Key Vault , Storage, SQL u otra API protegida sin colocar contraseña, secreto o certificado en un archivo de configuración. Al habilitar una identidad administrada, Azure crea una representación apropiada en Microsoft Entra ID . El código solicita un token al entorno de hospedaje, y la plataforma se encarga de la credencial subyacente.

11.1 Asignada por el sistema

La identidad administrada asignada por el sistema nace junto al recurso de Azure y comparte su ciclo de vida. Una máquina virtual o App Service recibe una identidad exclusiva; cuando el recurso se elimina, la identidad correspondiente también se quita. No puede compartirse entre varios recursos. Es adecuada cuando la identidad pertenece claramente a un único recurso.

11.2 Asignada por el usuario

La identidad administrada asignada por el usuario se crea como recurso independiente y puede asociarse a uno o varios recursos de Azure . Su ciclo de vida no depende de una VM o aplicación específica. Esto permite preautorizar una identidad, reutilizarla en instancias que se recrean y mantener permisos coherentes. Microsoft recomienda actualmente este tipo para muchos servicios cuando la reutilización y la independencia son deseables.

Regla de seguridad

La identidad administrada elimina la gestión de credenciales, pero no elimina la necesidad de autorización. Solo accederá al recurso de destino si recibe el rol o permiso adecuado.

radio_button_uncheckedshort_text 12. Identidades de agentes de IA

Los agentes de IA son software capaz de interpretar objetivos, planificar acciones e interactuar con herramientas, datos y servicios. Cuando un agente lee documentos, consulta API , crea tickets o ejecuta tareas en nombre de usuarios, tratarlo como una aplicación genérica puede producir poca granularidad y auditoría. Microsoft Entra Agent ID extiende la infraestructura de identidad para representar y gobernar agentes a escala.

En la arquitectura actual, las identidades de agente se construyen sobre la infraestructura de entidades de servicio, pero constituyen un tipo distinto. Un agent identity blueprint describe propiedades y capacidades compartidas y puede originar varias identidades de agente. El blueprint mantiene credenciales y realiza la obtención o el intercambio de tokens en nombre de las identidades; cada agente puede tener permisos y registros de auditoría propios. Ese modelo separa la plataforma que ejecuta agentes de la identidad concreta que actúa.

La noción de sponsor, o patrocinador responsable, es importante para la gobernanza. Una identidad no humana necesita una persona o unidad responsable de su propósito, acceso y ciclo de vida. Sin esa responsabilidad, los agentes pueden permanecer activos tras finalizar el proyecto, mantener permisos excesivos o ejecutar acciones difíciles de atribuir.

Para el SC-900

Concéntrate en el motivo: los agentes de IA necesitan identidad propia, privilegio mínimo, gobernanza y auditoría. La implementación es reciente y evoluciona con rapidez; los detalles de administración pueden cambiar más allá del alcance fundamental del examen.

radio_button_uncheckedshort_text 13. Identidad híbrida

La identidad híbrida es el modelo en el que una organización conecta capacidades locales y de la nube para proporcionar una identidad común. El usuario puede existir inicialmente en AD DS , aprovisionarse en Microsoft Entra ID y utilizar el mismo nombre de inicio de sesión para acceder a estaciones locales, Microsoft 365 , Azure y aplicaciones SaaS. La meta no es mantener dos cuentas independientes manualmente, sino coordinar ciclo de vida y atributos.

El aprovisionamiento es el proceso de crear, actualizar, habilitar, deshabilitar o eliminar objetos según reglas. La sincronización mantiene atributos correspondientes entre directorios. La autenticación es el proceso de comprobar la identidad durante el inicio de sesión. Esas tres palabras se relacionan, pero no son sinónimos. Una organización puede sincronizar usuarios y elegir diferentes métodos de autenticación híbrida.

13.1 Origen de autoridad

El origen de autoridad indica dónde se administra un atributo u objeto determinado. Para un usuario sincronizado, varios atributos siguen controlándose en AD DS y se envían a Entra ID. Modificarlos solo en la nube puede impedirse o sobrescribirse en la próxima sincronización. En entornos solo en la nube, el origen es el propio Entra ID. Definir claramente esa autoridad evita divergencias y cambios perdidos.

13.2 Coincidencia y source anchor

El mecanismo de sincronización debe asociar el objeto local con el objeto correcto en la nube. Para ello, utiliza atributos de coincidencia y un identificador estable, a menudo llamado source anchor. Los cambios de UPN, correo o nombre no deben crear automáticamente una nueva persona. Los errores de coincidencia pueden producir objetos duplicados o conectar identidades erróneas, por lo que la planificación de dominios y la limpieza del directorio son pasos críticos.

radio_button_uncheckedshort_text 14. Microsoft Entra Connect Sync y Cloud Sync

14.1 Microsoft Entra Connect Sync

Microsoft Entra Connect es una aplicación instalada en el entorno local para cumplir objetivos de identidad híbrida. Su componente de sincronización, Connect Sync , lee objetos y atributos de directorios locales, procesa reglas en el motor de sincronización y exporta cambios a Microsoft Entra ID . Sucedió a herramientas históricas como DirSync y Azure AD Sync.

Connect Sync ofrece funciones maduras y escenarios complejos, pero exige servidor, base de datos local, actualización, supervisión y planificación de alta disponibilidad. El modo de ensayo (staging mode) permite mantener un servidor adicional preparado sin exportar cambios hasta activarse. Connect Health proporciona supervisión de componentes híbridos en escenarios con licencia.

14.2 Microsoft Entra Cloud Sync

Microsoft Entra Cloud Sync es un enfoque moderno y administrado desde la nube. Agentes ligeros instalados localmente conectan AD DS con el servicio de aprovisionamiento en la nube. Esa arquitectura reduce la dependencia de un servidor de sincronización completo, facilita múltiples agentes y puede atender escenarios con bosques desconectados. Microsoft presenta Cloud Sync como dirección estratégica para la sincronización híbrida, aunque la elección depende de los recursos y requisitos de la organización.

No memorices “uno siempre sustituye al otro”

Para el examen, reconoce que ambos posibilitan la identidad híbrida. En un proyecto real, usa la matriz oficial de funciones y la herramienta de evaluación para elegir. La compatibilidad y la migración cambian con la evolución del producto.

radio_button_uncheckedshort_text 15. Sincronización de hash y métodos de inicio de sesión híbridos

15.1 Password Hash Synchronization - PHS

En la sincronización de hash de contraseña, Microsoft Entra Connect procesa una representación derivada del hash de contraseña existente en AD DS y envía un hash adicional a Microsoft Entra ID por un canal protegido. La contraseña en texto sin formato no se sincroniza, y el hash original de AD DS no se envía directamente. Cuando el usuario inicia sesión en la nube, Entra ID valida la contraseña usando el valor almacenado en su infraestructura.

Una forma útil de recordarlo es “ hash del hash ”, aunque la implementación incluye sal y funciones adicionales. El objetivo conceptual es permitir la autenticación en la nube con la misma contraseña sin depender del controlador de dominio local en cada inicio de sesión. Esto mejora la resiliencia y reduce la dependencia de la conectividad, además de permitir que las señales de credenciales filtradas se apliquen a identidades híbridas en escenarios admitidos.

15.2 Pass-through Authentication - PTA

En la autenticación de paso, el usuario proporciona la contraseña a la experiencia de inicio de sesión de Entra ID, y agentes locales validan la credencial contra Active Directory. La validación depende de la infraestructura local y de los agentes disponibles. PTA puede atender a organizaciones que no desean mantener una representación de hash para la autenticación en la nube, pero exige planificación de disponibilidad y conectividad.

15.3 Federación

En la federación, Microsoft Entra ID confía en un servicio de federación, como AD FS u otro proveedor compatible, para autenticar al usuario. El IdP federado aplica su lógica y emite una aserción o token reconocido por Microsoft. El modelo ofrece control e integración con requisitos específicos, pero añade infraestructura, certificados, disponibilidad y complejidad operativa.

15.4 Escritura diferida de contraseñas y SSO

La escritura diferida de contraseñas (password writeback) permite que determinados cambios o restablecimientos de contraseña realizados en la nube se escriban de vuelta en AD DS en escenarios configurados y con licencia. Esto es diferente de PHS : PHS envía material derivado de la contraseña local para la autenticación en la nube; la escritura diferida envía una nueva contraseña definida en la nube al entorno local. El SSO fluido (Seamless SSO ) puede reducir las solicitudes de credencial en dispositivos corporativos, pero también es una capacidad distinta del método de sincronización.

Trampa importante

Sincronizar usuarios no determina automáticamente cómo se autenticarán. El aprovisionamiento/sincronización y el método de inicio de sesión son decisiones separadas, aunque se configuren en el mismo proyecto híbrido.

radio_button_uncheckedshort_text 16. Microsoft Entra External ID y colaboración B2B

Microsoft Entra External ID reúne capacidades para trabajar con personas ajenas a la organización. En un workforce tenant, la colaboración B2B permite compartir aplicaciones y recursos corporativos con socios e invitados sin crear y administrar una contraseña interna separada para cada persona. El usuario normalmente se autentica con su propia identidad de origen, mientras que el tenant de recurso controla la autorización y las políticas locales.

16.1 Invitación y canje

En el flujo tradicional, un usuario o administrador envía una invitación. El socio canjea esa invitación y se autentica usando una cuenta corporativa, una cuenta Microsoft, un código de un solo uso por correo u otro proveedor configurado. Tras el canje, el tenant de recurso mantiene un objeto de usuario que normalmente tiene userType Guest. En representaciones históricas, el UPN puede incluir el marcador #EXT#, pero el invitado sigue utilizando sus credenciales de origen.

Esa separación es poderosa: la organización de origen administra la credencial y el ciclo de vida de la cuenta doméstica; la organización de recurso decide qué aplicaciones, grupos, sitios y datos accede el invitado. Si el socio deja la empresa, las señales entre tenants y los procesos de gobernanza pueden reducir el riesgo, pero el tenant de recurso aún debe revisar y quitar accesos que ya no son necesarios.

16.2 Configuraciones entre tenants

La configuración de acceso entre tenants (cross-tenant access settings) controla la confianza y las restricciones de entrada y salida entre organizaciones de Microsoft Entra . Puede determinar la colaboración B2B, la confianza en la MFA o el estado de dispositivo de otro tenant y el acceso por organización. La configuración de colaboración externa (external collaboration settings) controla, entre otros puntos, quién puede invitar a invitados y qué dominios pueden permitirse o bloquearse. Son capas complementarias, no sinónimas.

16.3 B2B direct connect

B2B direct connect crea una relación de confianza mutua para la colaboración directa entre tenants. El escenario actual más conocido es Teams shared channels, en el que los usuarios colaboran con sus identidades domésticas sin ser agregados como invitados tradicionales en el otro tenant. La función requiere configuración entre las organizaciones y no debe confundirse con una invitación B2B común.

radio_button_uncheckedshort_text 17. B2B, B2C y CIAM: diferencias conceptuales

B2B significa business-to-business y describe la colaboración entre organizaciones. El usuario externo accede a recursos de una fuerza de trabajo, generalmente manteniendo su identidad de origen. B2C significa business-to-consumer y describe la relación entre una organización y consumidores. En identidad, ese dominio suele llamarse CIAM - Customer Identity and Access Management - e implica autorregistro, recuperación de cuenta, proveedores sociales, consentimiento, personalización de marca y gran escala.

En la arquitectura actual de Microsoft Entra External ID , la organización usa un workforce tenant para empleados y colaboración B2B. Para aplicaciones dirigidas a consumidores o clientes comerciales, crea un external tenant separado, configurado para CIAM. Ese tenant contiene los usuarios de las aplicaciones y ofrece sus propios flujos de registro e inicio de sesión. Separar los escenarios reduce la exposición de los recursos internos y permite políticas adecuadas al público externo.

Azure AD B2C es el producto heredado conocido por muchos profesionales. Microsoft informa de que no está disponible para su compra por nuevos clientes desde el 1 de mayo de 2025; los tenants existentes siguen tratándose mediante la documentación de migración y soporte aplicable. Para nuevos proyectos, la dirección es Microsoft Entra External ID en external tenants. Para el SC-900, la distinción conceptual es más importante que los detalles comerciales: B2B es colaboración con socios; B2C/CIAM es identidad de clientes en aplicaciones.

radio_button_uncheckedshort_text 18. Escenario práctico integrado

Considera Contoso, una empresa con Active Directory local, Microsoft 365 , cargas de trabajo en Azure y un portal para clientes. Desea reducir contraseñas técnicas, colaborar con proveedores y preparar agentes de IA para atención interna. La arquitectura de identidad puede razonarse por capas.

1. Contoso utiliza un workforce tenant de Microsoft Entra ID . Sus dominios contoso.com y subsidiarias están verificados en el tenant.
2. Los usuarios y grupos de AD DS se aprovisionan en Entra ID. La empresa evalúa Cloud Sync para nuevos entornos y mantiene Connect Sync donde hay requisitos aún no cubiertos.
3. Se elige PHS como método primario de inicio de sesión en la nube por simplicidad y resiliencia. La escritura diferida de contraseñas se configura para integrar el restablecimiento de contraseña con AD DS .
4. Los portátiles corporativos modernos son Microsoft Entra joined y administrados; los equipos en transición permanecen hybrid joined; los dispositivos personales son registered cuando se permite.
5. Una aplicación interna se registra en el tenant. Su application object define la autenticación; la entidad de servicio local recibe asignaciones y políticas.
6. Un App Service usa una identidad administrada asignada por el usuario para leer secretos de Key Vault . No se almacena ningún secreto de cliente en el código.
7. Los proveedores se invitan mediante B2B y se agregan a grupos específicos. Se usarán paquetes y revisiones de acceso para limitar la duración y confirmar la necesidad.
8. El portal de clientes se registra en un external tenant de CIAM, separado del workforce tenant, con autorregistro y proveedores sociales.
9. Cada agente de IA recibe una identidad de agente y permisos mínimos para las herramientas necesarias, con sponsor y registros específicos.

Cómo resolver preguntas de escenario

Primero identifica la entidad: persona, dispositivo, aplicación, socio, cliente o agente. Luego identifica la frontera: tenant interno, tenant externo o AD DS . Por último, elige el mecanismo: sincronización, entidad de servicio, identidad administrada, B2B o CIAM.

radio_button_uncheckedshort_text 19. Buenas prácticas de arquitectura y seguridad

19.1 Usa privilegio mínimo e identidades específicas

Concede solo los permisos necesarios, en el ámbito necesario y por el tiempo necesario. Separa las cuentas administrativas de las cuentas de productividad. Para las cargas de trabajo, crea identidades por función o componente cuando eso mejore el aislamiento y la auditoría. Evita una única identidad muy privilegiada compartida por muchas automatizaciones.

19.2 Elimina los secretos siempre que sea posible

Prefiere identidades administradas para cargas de trabajo en Azure y credenciales federadas para plataformas externas compatibles. Cuando un secreto o certificado sea inevitable, usa un almacén, expiración, rotación y alertas. Nunca incorpores credenciales en el código fuente, la imagen de contenedor o un archivo distribuido sin protección.

19.3 Controla el ciclo de vida

Toda identidad necesita creación, mantenimiento y finalización. Define propietarios para grupos, aplicaciones, entidades de servicio y agentes. Deshabilita identidades huérfanas, quita credenciales antiguas y revisa consentimientos. En B2B, el acceso externo debe tener plazo y justificación cuando sea posible.

19.4 Planifica el origen de autoridad

En entornos híbridos, documenta qué atributos se administran en AD DS y cuáles son administrados desde la nube. Prueba cambios de UPN, fusiones, bajas y recuperación. Supervisa los errores de sincronización y mantén procedimientos para el fallo del componente híbrido.

19.5 Usa registros y señales

Los inicios de sesión de usuarios, entidades de servicio e identidades administradas producen registros distintos. Audita los cambios administrativos, los consentimientos y las asignaciones. Las identidades modernas son valiosas precisamente porque permiten atribuir acciones a una entidad específica; compartir una cuenta o credencial destruye esa capacidad.

radio_button_uncheckedshort_text 20. Repaso para el SC-900 y trampas de examen

20.1 Confusiones frecuentes

• Microsoft Entra ID no es un controlador de dominio alojado y no sustituye automáticamente todas las funciones de AD DS .
• Un tenant y una suscripción de Azure no son la misma frontera.
• El registro de aplicación y la aplicación empresarial no son dos aplicaciones independientes; normalmente representan un application object y una entidad de servicio.
• Una identidad administrada es un tipo especial de identidad de carga de trabajo, no un usuario humano sin contraseña.
• La identidad híbrida no significa que la contraseña en texto sin formato se copie a la nube.
• B2B no es un portal para consumidores; B2C/CIAM no es la forma estándar de invitar a un proveedor a SharePoint.
• Los dispositivos registrado, unido y administrado son conceptos diferentes, aunque puedan coexistir.
• Una identidad autenticada aún necesita ser autorizada para cada recurso.

Resumen en una frase

Microsoft Entra ID mantiene la frontera de identidad en la nube; representa personas y entidades no humanas; integra directorios locales; y extiende la confianza a socios, clientes, cargas de trabajo y agentes con políticas y auditoría.

radio_button_uncheckedshort_text 21. Conclusión

Microsoft Entra ID es el núcleo de identidad de la nube de Microsoft. Su valor no está solo en almacenar cuentas, sino en representar entidades diferentes dentro de una frontera lógica, autenticar esas entidades, emitir tokens , aplicar políticas y registrar actividades. Tenants, usuarios, grupos, dispositivos, application objects y entidades de servicio forman el lenguaje básico usado para comprender el producto.

Las identidades no humanas ganan una importancia creciente. Las workload identities y las identidades administradas permiten que las aplicaciones accedan a recursos sin depender de cuentas humanas y, en muchos casos, sin secretos administrados manualmente. Agent ID amplía esta lógica a los agentes de IA, añadiendo separación entre el blueprint, la identidad del agente, los permisos, el sponsor y la auditoría.

Los entornos híbridos demuestran que la modernización rara vez ocurre de una sola vez. AD DS y Entra ID pueden coexistir mediante aprovisionamiento y sincronización, usando Connect Sync o Cloud Sync y métodos de inicio de sesión como PHS , PTA o federación. External ID , a su vez, separa la colaboración B2B de las experiencias de clientes en CIAM. Mi evaluación es que dominar estas distinciones es más valioso que memorizar nombres: cuando el lector entiende qué entidad existe, en qué tenant y con qué responsabilidad, la arquitectura se vuelve previsible y las preguntas del SC-900 dejan de parecer una lista desconectada de productos.

Siguiente paso de la ruta

Con los tipos de identidad y los entornos híbridos comprendidos, el próximo capítulo profundiza en cómo esas identidades comprueban quiénes son: métodos de autenticación, MFA , Microsoft Authenticator , FIDO2, Windows Hello for Business , SSPR y tecnologías sin contraseña.

radio_button_uncheckedshort_text 22. Preguntas de repaso

1. Una organización registra una aplicación multitenant en el tenant A. Cuando el tenant B concede consentimiento para usar esa aplicación, ¿qué objeto representa la instancia local en el tenant B?

• A) Un nuevo tenant de Microsoft Entra ID .
• B) Una entidad de servicio.
• C) Un usuario invitado.
• D) Una identidad de dispositivo.

Respuesta comentada

Respuesta correcta: B. El application object permanece en el tenant de origen; cada tenant consumidor crea su propia entidad de servicio, que recibe consentimientos y permisos locales.

2. ¿Qué opción permite que un App Service acceda a Azure Key Vault sin que el desarrollador almacene un secreto de cliente en el código?

• A) Un usuario invitado B2B.
• B) Un grupo dinámico.
• C) Una identidad administrada.
• D) Sincronización de hash de contraseña.

Respuesta comentada

Respuesta correcta: C. La identidad administrada proporciona al recurso una identidad en Entra ID y permite obtener tokens sin exponer credenciales al código. La identidad aún necesita recibir autorización en Key Vault .

3. Una empresa quiere que los empleados de AD DS usen la misma contraseña para autenticarse directamente en la nube, incluso durante la indisponibilidad de los controladores de dominio locales. ¿Qué método es más compatible con ese objetivo?

• A) Password Hash Synchronization .
• B) Pass-through Authentication .
• C) B2B direct connect.
• D) Solo federación con AD FS .

Respuesta comentada

Respuesta correcta: A. Con PHS , una representación derivada del hash se mantiene en Entra ID, permitiendo la validación en la nube sin consultar AD DS en cada inicio de sesión.

4. ¿Qué afirmación diferencia correctamente B2B de B2C/CIAM?

• A) B2B es para clientes anónimos; CIAM es solo para administradores.
• B) B2B comparte recursos corporativos con socios; CIAM gestiona el registro y el inicio de sesión de clientes en aplicaciones.
• C) B2B y CIAM son nombres diferentes para la misma configuración de tenant.
• D) CIAM exige que todo cliente tenga una cuenta de empleado en el workforce tenant.

Respuesta comentada

Respuesta correcta: B. B2B atiende la colaboración con socios e invitados. B2C/CIAM atiende a consumidores y clientes de aplicaciones, normalmente en un external tenant dedicado.

radio_button_uncheckedshort_text 23. Referencias y fuentes de profundización

Base primaria del alcance: plan de estudios SC-900 proporcionado por el usuario, Capítulo 3 - Microsoft Entra ID , Tipos de Identidad y Entornos Híbridos.

• Microsoft Learn - Study guide for Exam SC-900
• Microsoft Learn - Describe the function and identity types of Microsoft Entra ID
• Microsoft Learn - ¿Qué es Microsoft Entra?
• Microsoft Learn - Apps and service principals in Microsoft Entra ID
• Microsoft Learn - Managed identities for Azure resources
• Microsoft Learn - Agent identities, service principals, and applications
• Microsoft Learn - Hybrid identity with Microsoft Entra ID
• Microsoft Learn - ¿Qué es la sincronización de hash de contraseña?
• Microsoft Learn - Microsoft Entra B2B collaboration
• Microsoft Learn - Device identity in Microsoft Entra ID

Fuentes oficiales consultadas el 23 de julio de 2026. Como los servicios en la nube evolucionan continuamente, los detalles de licenciamiento, disponibilidad regional, nombres de menús y funciones en versión preliminar deben confirmarse en la documentación actual antes de una implementación real.

Cierre del capítulo

Has completado los tipos de identidad y los entornos híbridos de Microsoft Entra ID . El siguiente paso natural es estudiar los métodos de autenticación modernos: MFA , Microsoft Authenticator , FIDO2, Windows Hello for Business , SSPR y las tecnologías sin contraseña.