Compartir vía

Uso de un proveedor de identidades (IdP) de SAML 2.0 para el inicio de sesión único

  • Artículo

Este documento contiene información sobre el uso de un proveedor de identidades basado en un perfil de SP-Lite y compatible con SAML 2.0 como proveedor de identidades o servicio de token de seguridad (STS) preferido. Este escenario resulta útil si ya tiene un directorio de usuario y un almacén de contraseñas local a los que se puede acceder mediante SAML 2.0. Este directorio de usuario existente se puede usar para iniciar sesión en Microsoft 365 y otros recursos protegidos por Microsoft Entra ID. El perfil SP-Lite de SAML 2.0 se basa en el estándar de identidad federada del lenguaje de marcado de aserción de seguridad (SAML) de uso generalizado y proporciona un marco de inicio de sesión e intercambio de atributos.

Nota:

Para obtener una lista de Idp de terceros cuyo uso se ha probado con Microsoft Entra ID, consulte la Lista de compatibilidad de federación de Microsoft Entra

Microsoft admite esta experiencia de inicio de sesión único como la integración de un servicio en la nube de Microsoft, como Microsoft 365, con el Idp basado en el perfil de SAML 2.0 configurado. Dado que los proveedores de identidades de SAML 2.0 son productos de terceros, Microsoft no proporciona soporte técnico con la implementación, la configuración y los procedimientos recomendados de solución de problemas en relación a ellos. Una vez configurada adecuadamente, se puede probar la integración con el proveedor de identidades de SAML 2.0 para ver si es correcta mediante la herramienta Analizador de conectividad de Microsoft que se describe con más detalle a continuación. Para obtener más información sobre el proveedor de identidades basado en un perfil SP-Lite de SAML 2.0, consulte con la organización que lo suministra.

Importante

Solo un conjunto limitado de clientes están disponibles en este escenario de inicio de sesión con proveedores de identidades de SAML 2.0, entre los que se incluyen:

  • Clientes basados en web como Outlook Web Access y SharePoint Online
  • Clientes enriquecidos para el correo electrónico que usan la autenticación básica y un método de acceso de Exchange compatible, como IMAP, POP, Active Sync, MAPI, etc. (Es necesario implementar el punto de conexión del protocolo de cliente mejorado), incluido lo siguiente:
    • Microsoft Outlook 2010, Outlook 2013, Outlook 2016, iPhone de Apple (distintas versiones de iOS)
    • Varios dispositivos de Android de Google
    • Windows Phone 7, Windows Phone 7.8 y Windows Phone 8.0
    • Cliente de correo de Windows 8 y Windows 8.1
    • Cliente de correo de Windows 10

Todos los demás clientes no están disponibles en este escenario de inicio de sesión con el proveedor de identidades de SAML 2.0. Por ejemplo, el cliente de escritorio Lync 2010 no es capaz de iniciar sesión en el servicio con el proveedor de identidades de SAML 2.0 configurado para el inicio de sesión único.

Requisitos del protocolo SAML 2.0 de Microsoft Entra

Este documento contiene los requisitos detallados sobre el protocolo y el formato de mensaje que debe implementar su proveedor de identidades de SAML 2.0 para la federación con Microsoft Entra ID a fin de habilitar el inicio de sesión en uno o varios servicios en la nube de Microsoft (como Microsoft 365). El usuario de confianza de SAML 2.0 (SP-STS) que se usa en este escenario para un servicio en la nube de Microsoft es Microsoft Entra ID.

Se recomienda que se asegure de que sus mensajes de salida del proveedor de identidades de SAML 2.0 sean lo más parecidos posibles a los seguimientos de ejemplo proporcionados. Además, cuando sea posible, use valores de atributo específicos de los metadatos de Microsoft Entra suministrados. Cuando esté satisfecho con los mensajes de salida, puede probar con el Analizador de conectividad de Microsoft, como se describe a continuación.

Los metadatos de Microsoft Entra se pueden descargar desde esta dirección URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Para los clientes en China que usan la instancia de Microsoft 365 específica para China, se debe usar el punto de conexión de federación siguiente: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Requisitos del protocolo SAML

En esta sección se detalla como se unen los pares de mensajes de solicitud y respuesta para ayudarle a dar formato a los mensajes correctamente.

Microsoft Entra ID se puede configurar para funcionar con proveedores de identidades que usan el perfil SP-Lite de SAML 2.0 con algunos requisitos específicos, que se indican a continuación. Mediante el uso de los mensajes de solicitud y respuesta de SAML de ejemplo, junto con las pruebas manuales y automatizadas, puede trabajar para conseguir la interoperabilidad con Microsoft Entra ID.

Requisitos del bloque de firma

En el mensaje de respuesta de SAML, el nodo de firma contiene información sobre la firma digital del propio mensaje. El bloque de firma tiene los siguientes requisitos:

  1. El propio nodo de aserción debe estar firmado.
  2. El algoritmo RSA-sha1 debe usarse como DigestMethod. No se aceptan otros algoritmos de firma digital. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. También puede firmar el documento XML.
  4. El algoritmo Transform debe coincidir con los valores del ejemplo siguiente:<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
  5. El algoritmo SignatureMethod debe coincidir con el ejemplo siguiente:<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Nota

Para mejorar la seguridad, el algoritmo SHA-1 está en desuso. Asegúrese de usar un algoritmo más seguro como SHA-256. Dispone de más información.

Enlaces admitidos

Los enlaces son los parámetros de comunicación relacionados con el transporte que son necesarios. Los siguientes requisitos se aplican a los enlaces:

  1. HTTPS es el transporte requerido.
  2. Microsoft Entra ID necesita HTTP POST para el envío del token durante el inicio de sesión.
  3. Microsoft Entra ID usa HTTP POST en la solicitud de autenticación al proveedor de identidades y REDIRECT en el mensaje de cierre de sesión al proveedor de identidades.

Atributos requeridos

En esta tabla se muestran los requisitos de atributos específicos en el mensaje de SAML 2.0.

Atributo Descripción
NameID El valor de esta aserción debe ser el mismo que el valor de ImmutableID del usuario de Microsoft Entra. Puede tener hasta 64 caracteres alfanuméricos. Los caracteres seguros que no sean HTML deben estar codificados, por ejemplo, un carácter "+" se muestra como ".2B".
IDPEmail El nombre principal de usuario (UPN) aparece en la respuesta SAML como un elemento con el nombre IDPEmail. Este es el valor de UserPrincipalName (UPN) del usuario en Microsoft Entra ID o Microsoft 365. El UPN está en formato de dirección de correo electrónico. Valor UPN en Windows Microsoft 365 (Microsoft Entra ID).
Emisor Es necesario que sea un URI del proveedor de identidades. No debe volver a usar el emisor de los mensajes de ejemplo. Si tiene varios dominios de nivel superior en sus inquilinos de Microsoft Entra, el emisor debe coincidir con el valor de URI especificado configurado por dominio.

Importante

Actualmente, Microsoft Entra ID admite el siguiente URI de formato NameID para SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

Ejemplo de mensajes de solicitud y respuesta de SAML

Se muestra un mensaje de solicitud y respuesta para el intercambio de mensajes de inicio de sesión. A continuación, se muestra un mensaje de solicitud de ejemplo que se envía desde Microsoft Entra ID a un proveedor de identidades de SAML 2.0 de ejemplo. El proveedor de identidades de SAML 2.0 de ejemplo está configurado por los Servicios de federación de Active Directory (AD FS) para usar el protocolo SAML-P. Las pruebas de interoperabilidad también se han realizado con otros proveedores de identidades de SAML 2.0.

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Si isSignedAuthenticationRequestRequired está habilitado como se explica en internaldomainfederation-update, la solicitud tendría el siguiente aspecto:

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

A continuación, se muestra un mensaje de respuesta de ejemplo que se envía desde el proveedor de identidades compatible con SAML 2.0 de ejemplo a Microsoft Entra ID o Microsoft 365.

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

Configuración del proveedor de identidades compatible con SAML 2.0

Esta sección contiene instrucciones sobre cómo configurar el proveedor de identidades de SAML 2.0 para la federación con Microsoft Entra ID con el fin de habilitar el acceso de inicio de sesión único a uno o varios servicios en la nube de Microsoft (como Microsoft 365) mediante el protocolo SAML 2.0. El usuario de confianza de SAML 2.0 que se usa en este escenario para un servicio en la nube de Microsoft es Microsoft Entra ID.

Agregar metadatos de Microsoft Entra

El proveedor de identidades de SAML 2.0 debe adherirse a la información sobre el usuario de confianza de Microsoft Entra ID. Microsoft Entra ID publica metadatos en https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

Se recomienda importar siempre los metadatos más recientes de Microsoft Entra al configurar el proveedor de identidades de SAML 2.0.

Nota:

Microsoft Entra ID no lee los metadatos del proveedor de identidades.

Agregar a Microsoft Entra ID como un usuario de confianza

Deberá habilitar la comunicación entre el proveedor de identidades de SAML 2.0 y Microsoft Entra ID. Esta configuración dependerá de su proveedor de identidades específico, así que debería consultar la documentación correspondiente. Normalmente el id. del usuario de confianza se establecerá en el mismo valor de entityID de los metadatos de Microsoft Entra.

Nota:

Compruebe que el reloj del servidor del proveedor de identidades de SAML 2.0 esté sincronizado con una fuente horaria precisa. Una hora inexacta del reloj puede hacer que los inicios de sesión federados produzcan error.

Instalación de PowerShell para el inicio de sesión con el proveedor de identidades de SAML 2.0

Después de configurar el proveedor de identidades de SAML 2.0 para su uso con el inicio de sesión de Microsoft Entra, el siguiente paso consiste en descargar e instalar el módulo de PowerShell de Microsoft Graph. Una vez instalado, usará estos cmdlets para configurar los dominios de Microsoft Entra como dominios federados.

El módulo de PowerShell de Microsoft Graph es básicamente una descarga que le ayudará a administrar los datos de su organización en Microsoft Entra ID. Este módulo instala un conjunto de cmdlets en PowerShell; esos cmdlets se ejecutan para configurar el acceso de inicio de sesión único en Microsoft Entra ID y, a su vez, a todos los servicios en la nube a los que está suscrito. Para obtener instrucciones sobre cómo descargar e instalar los cmdlets, consulte Instalación del SDK de PowerShell de Microsoft Graph.

Configuración de una relación de confianza entre el proveedor de identidades de SAML y Microsoft Entra ID

Antes de configurar la federación en un dominio de Microsoft Entra, debe tener configurado un dominio personalizado. No se puede federar el dominio predeterminado proporcionado por Microsoft. El dominio predeterminado de Microsoft finaliza con onmicrosoft.com. Ejecutará una serie de cmdlets de PowerShell para agregar o convertir dominios para el inicio de sesión único.

Todos los dominios de Microsoft Entra que quiera federar mediante su proveedor de identidades de SAML 2.0 se deben agregar como un dominio de inicio de sesión único o convertirse en uno de estos dominios a partir de un dominio estándar. El hecho de agregar o convertir un dominio establece una relación de confianza entre el proveedor de identidades de SAML 2.0 y Microsoft Entra ID.

En el procedimiento siguiente se explica cómo convertir un dominio estándar existente en un dominio federado mediante SP-Lite de SAML 2.0.

Nota

Tenga en cuenta que el dominio puede sufrir una interrupción del sistema que afecte a los usuarios durante un período de tiempo de hasta dos horas después de realizar este paso.

Configuración de un dominio en Microsoft Entra Directory para federación

  1. Conéctese a su instancia de Microsoft Entra Directory como un administrador de inquilinos:

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

  2. Configure el dominio de Microsoft 365 deseado para usar la federación con SAML 2.0:

    $Domain = "contoso.com"  
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
$MyUri = "urn:uri:MySamlp2IDP"
$idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
$MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
$Protocol = "saml"

New-MgDomainFederationConfiguration `
  -DomainId $Domain `
  -ActiveSignInUri $ecpUrl `
  -IssuerUri $MyUri `
  -PassiveSignInUri $LogOnUrl `
  -PreferredAuthenticationProtocol $Protocol `
  -SignOutUri $LogOffUrl `
  -SigningCertificate $MySigningCert

  3. Puede obtener la cadena codificada en base64 del certificado de firma de su archivo de metadatos de IDP. A continuación se proporciona un ejemplo de esta ubicación, pero puede ser algo diferente en función de la implementación.

    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="signing">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
     <X509Data>
       <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
</IDPSSODescriptor>

Para obtener más información, consulte New-MgDomainFederationConfiguration.

Nota:

Solo debe usar $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" si configura una extensión ECP para el proveedor de identidades. Los clientes de Exchange Online, excepto Outlook Web Application (OWA), dependen de un punto de conexión activo basado en POST. Si el STS de SAML 2.0 implementa un punto de conexión activo de forma similar a ECP de Shibboleth, es posible que estos clientes enriquecidos puedan interactuar con el servicio Exchange Online.

Una vez configurada la federación, puede cambiar de nuevo a "no federado" (o "administrado"); sin embargo, este cambio tarda hasta dos horas en realizarse y requiere la asignación de nuevas contraseñas aleatorias para el inicio de sesión basado en la nube de cada usuario. Volver a cambiar a "administrado" puede ser necesario en algunos escenarios para restablecer un error de la configuración. Para obtener más información sobre la conversión de dominios, vea Remove-MgDomainFederationConfiguration.

Aprovisionamiento de entidades de seguridad de usuario para Microsoft Entra ID o Microsoft 365

Antes de poder autenticar a los usuarios en Microsoft 365, debe aprovisionar Microsoft Entra ID con entidades de seguridad de usuario que correspondan a la aserción en la notificación de SAML 2.0. Si Microsoft Entra ID no conoce estas entidades de seguridad de usuario de antemano, no se podrán usar para el inicio de sesión federado. Puede usar Microsoft Entra Connect o PowerShell para aprovisionar las entidades de seguridad de usuario.

Microsoft Entra Connect se puede usar para aprovisionar entidades de seguridad en los dominios de Microsoft Entra Directory desde la instancia de Active Directory local. Para obtener más información, consulte Integración de los directorios locales con Microsoft Entra ID.

También se puede usar PowerShell para automatizar la adición de nuevos usuarios a Microsoft Entra ID y sincronizar los cambios desde el directorio local. Para usar los cmdlets de PowerShell, debe descargar el módulo de PowerShell de Microsoft Graph.

Este procedimiento muestra cómo agregar un único usuario a Microsoft Entra ID.

  1. Conéctese a su directorio de Microsoft Entra como un administrador de inquilinos medianteConnect-MgGraph.

  2. Cree una nueva entidad de seguridad de usuario:

    $Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
$PasswordProfile = @{ Password = "$Password" }

New-MgUser `
  -UserPrincipalName "elwoodf1@contoso.com" `
  -DisplayName "Elwood Folk" `
  -GivenName "Elwood" `
  -Surname "Folk" `
  -AccountEnabled `
  -MailNickName 'ElwoodFolk' `
  -OnPremisesImmutableId ABCDEFG1234567890 `
  -OtherMails "Elwood.Folk@contoso.com" `
  -PasswordProfile $PasswordProfile `
  -UsageLocation "US"

Para obtener más información, consulte New-MgUser.

Nota:

El valor "UserPrincipalName" debe coincidir con el valor que se enviará para "IDPEmail" en la notificación de SAML 2.0, y el valor "OnPremisesImmutableId" debe coincidir con el valor enviado en la aserción "NameID".

Comprobación del inicio de sesión único con el IDP SAML 2.0

Como administrador, antes de comprobar y administrar el inicio de sesión único (también llamado federación de identidades), revise la información y realice los pasos que se describen en los siguientes artículos para configurar el inicio de sesión único con su proveedor de identidades basado en SP-Lite de SAML 2.0:

  1. Ha revisado los requisitos del protocolo SAML 2.0 de Microsoft Entra
  2. Ha configurado el proveedor de identidades de SAML 2.0.
  3. Instale PowerShell para el inicio de sesión único (SSO) con el proveedor de identidades de SAML 2.0
  4. Configuración de una relación de confianza entre el proveedor de identidades de SAML 2.0 y Microsoft Entra ID
  5. Ha aprovisionado una entidad de seguridad de usuario de prueba conocida en Microsoft Entra ID (Microsoft 365) a través de PowerShell o Microsoft Entra Connect.
  6. Configure la sincronización de directorios mediante Microsoft Entra Connect.

Después de configurar el SSO con el proveedor de identidades basado en SP-Lite de SAML 2.0, debe comprobar que funciona correctamente. Para más información sobre cómo probar el inicio de sesión único basado en SAML, consulte Prueba del inicio de sesión único basado en SAML.

Nota:

Si ha convertido un dominio, en lugar de agregar uno, puede tardar hasta 24 horas en configurar el inicio de sesión único. Antes de comprobar el inicio de sesión único, debe finalizar la configuración de la sincronización de Active Directory, sincronizar los directorios y activar los usuarios sincronizados.

Comprobación manual de que el inicio de sesión único se ha configurado correctamente

La comprobación manual proporciona más pasos que puede realizar para asegurarse de que el proveedor de identidades de SAML 2.0 funciona correctamente en muchos escenarios. Para comprobar que ese inicio de sesión único está configurado correctamente, realice los pasos siguientes:

  1. En un equipo unido a un dominio, inicie sesión en su servicio en la nube con el mismo nombre de inicio de sesión que usa en las credenciales corporativas.
  2. Seleccione dentro del cuadro de contraseña. Si el inicio de sesión único está configurado, el cuadro de contraseña aparecerá sombreado y verá un mensaje que le indica que debe iniciar sesión en <su empresa>.
  3. Seleccione Iniciar sesión en el vínculo de <su empresa>. Si puede iniciar sesión, significa que el inicio de sesión único está configurado.

Pasos siguientes