Condividi tramite

Usare un provider di identità (IdP) SAML 2.0 per l'accesso unico

  • Articolo

Questo documento contiene informazioni sull'uso di un provider di identità basato sul profilo SP-Lite conforme a SAML 2.0, come provider preferito per il servizio token di sicurezza (STS). Si tratta di uno scenario utile quando si hanno già una directory di utenti e un archivio di password locali a cui è possibile accedere con SAML 2.0. Questa directory utente esistente può essere usata per l'accesso a Microsoft 365 e ad altre risorse protette da MICROSOFT Entra ID. Il profilo SP-Lite SAML 2.0 si basa sul diffuso standard Security Assertion Markup Language (SAML) per l'identità federata per fornire un framework di autenticazione e scambio degli attributi.

Nota

Per un elenco degli IDP di terze parti testati per l'uso con Microsoft Entra ID, vedere l'elenco di compatibilità della federazione di Microsoft Entra

Microsoft supporta questa esperienza di accesso come integrazione di un servizio cloud Microsoft, ad esempio Microsoft 365, con l'IdP basato sul profilo SAML 2.0 configurato correttamente. I provider di identità SAML 2.0 sono prodotti di terze parti e pertanto Microsoft non fornisce supporto per la distribuzione, la configurazione e la risoluzione dei problemi relativi alle procedure consigliate. Una volta eseguita correttamente la configurazione, è possibile testare la corretta configurazione dell'integrazione con il provider di identità SAML 2.0 usando Microsoft Connectivity Analyzer Tool, descritto in dettaglio più avanti. Per ulteriori informazioni sul provider di identità basato sul profilo SP-Lite SAML 2.0, chiedere all'organizzazione che lo ha fornito.

Importante

In questo scenario di accesso con i provider di identità SAML 2.0 è disponibile solo un set limitato di client, tra cui:

  • Client basati sul Web, ad esempio Outlook Web Access e SharePoint Online
  • Client avanzati di posta elettronica che usano l'autenticazione di base e un metodo di accesso di Exchange supportato, ad esempio IMAP, POP, Sincronizzazione attiva, MAPI e così via. È necessario distribuire il punto finale del protocollo client avanzato, incluso:
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (diverse versioni di iOS)
    • Diversi dispositivi Google Android
    • Windows Phone 7, Windows Phone 7.8 e Windows Phone 8.0
    • Client di posta elettronica di Windows 8 e Windows 8.1
    • Client di posta elettronica di Windows 10

Tutti gli altri clienti non sono disponibili in questo scenario di accesso con il provider di identità SAML 2.0. Ad esempio, il client desktop Lync 2010 non è in grado di accedere al servizio con il provider di identità SAML 2.0 configurato per il Single Sign-On.

Requisiti del protocollo SAML 2.0 di Microsoft Entra

Questo documento contiene requisiti dettagliati sul protocollo e sulla formattazione dei messaggi che il provider di identità SAML 2.0 deve implementare per eseguire la federazione con Microsoft Entra ID per abilitare l'accesso a uno o più servizi cloud Microsoft (ad esempio Microsoft 365). In questo scenario, la parte fidata SAML 2.0 (SP-STS) per un servizio cloud Microsoft è Microsoft Entra ID.

È consigliabile assicurarsi che i messaggi di output del provider di identità SAML 2.0 siano il più possibile simili alle tracce di esempio fornite. Usare inoltre valori di attributo specifici dei metadati di Microsoft Entra forniti, se possibile. Dopo aver soddisfatto i messaggi di output, è possibile eseguire il test con Microsoft Connectivity Analyzer come descritto di seguito.

I metadati di Microsoft Entra possono essere scaricati da questo URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Per i clienti in Cina che usano l'istanza specifica della Cina di Microsoft 365, è necessario usare l'endpoint federativo seguente: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Requisiti del protocollo SAML

Questa sezione illustra in modo dettagliato come vengono combinate le coppie di messaggi di richiesta e di risposta per consentire la corretta formattazione dei messaggi.

Microsoft Entra ID può essere configurato per l'uso con i provider di identità che usano il profilo SAML 2.0 SP Lite con alcuni requisiti specifici, come indicato di seguito. Usando i messaggi di richiesta e risposta SAML di esempio insieme ai test automatizzati e manuali, è possibile lavorare per ottenere l'interoperabilità con Microsoft Entra ID.

Requisiti del blocco di firma

Nel messaggio di risposta SAML, il nodo Signature contiene informazioni sulla firma digitale del messaggio stesso. Il blocco di firma ha i requisiti seguenti:

  1. Il nodo di asserzione deve essere firmato
  2. È necessario usare l'algoritmo RSA-sha1 come DigestMethod. Altri algoritmi di firma digitale non vengono accettati. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. È anche possibile firmare il documento XML.
  4. Il valore dell'algoritmo di trasformazione deve corrispondere ai valori nell'esempio seguente: <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. L'algoritmo SignatureMethod deve corrispondere all'esempio seguente: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Nota

Per migliorare la sicurezza, l'algoritmo SHA-1 è considerato obsoleto. Assicurarsi di usare un algoritmo più sicuro, ad esempio SHA-256. Altre informazioni sono disponibili.

Associazioni supportate

I binding sono i parametri di comunicazione relativi al trasporto necessari. Ai vincoli si applicano i requisiti seguenti

  1. Il trasporto richiesto è HTTPS.
  2. Microsoft Entra ID richiede HTTP POST per l'invio di token durante l'accesso.
  3. Microsoft Entra ID usa HTTP POST per la richiesta di autenticazione al provider di identità e REDIRECT per il messaggio di logout al provider di identità.

Attributi obbligatori

Questa tabella mostra i requisiti per gli attributi specifici nel messaggio SAML 2.0.

Attributo Descrizione
NameID Il valore di questa asserzione deve essere uguale a ImmutableID dell'utente di Microsoft Entra. Può essere composto da un massimo di 64 caratteri alfanumerici. Qualsiasi carattere non compatibile con HTML deve essere codificato. Ad esempio, il carattere "+" viene visualizzato come ".2B".
IDPEmail Il Nome Principale Utente (UPN) è elencato nella risposta SAML come elemento con il nome IDPEmail. Il UserPrincipalName (UPN) dell'utente in Microsoft Entra ID / Microsoft 365. L'UPN è nel formato indirizzo email. Valore UPN in Windows Microsoft 365 (ID Microsoft Entra).
Emittente Deve essere un URI del provider di identità. Non riutilizzare l'emittente dai messaggi di esempio. Se sono presenti più domini di primo livello nei tenant di Microsoft Entra, l'issuer deve corrispondere all'impostazione URI specificata configurata per ciascun dominio.

Importante

Microsoft Entra ID attualmente supporta il seguente URI del formato NameID per SAML 2.0: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

Messaggi di richiesta e di risposta SAML di esempio

Per lo scambio di messaggi di accesso viene visualizzata una coppia di messaggi di richiesta e di risposta. Di seguito è riportato un messaggio di richiesta di esempio inviato da Microsoft Entra ID a un provider di identità SAML 2.0 di esempio. Il provider di identità SAML 2.0 di esempio è Active Directory Federation Services (AD FS) configurato per l'uso del protocollo SAML-P. È stato anche completato un test di interoperabilità con altri provider di identità 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>

Se isSignedAuthenticationRequestRequired è abilitato come illustrato in internaldomainfederation-update, la richiesta sarà simile all'esempio seguente:

  <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>

Di seguito è riportato un messaggio di risposta di esempio inviato dal provider di identità conforme a SAML 2.0 di esempio all'ID Microsoft Entra / 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>

Configura il tuo provider di identità conforme a SAML 2.0

Questa sezione contiene linee guida su come configurare il provider di identità SAML 2.0 per la federazione con Microsoft Entra ID per abilitare l'accesso Single Sign-On a uno o più servizi cloud Microsoft (ad esempio Microsoft 365) usando il protocollo SAML 2.0. In questo scenario, la relying party SAML 2.0 per un servizio cloud Microsoft è Microsoft Entra ID.

Aggiungere i metadati di Microsoft Entra

Il provider di identità SAML 2.0 deve adattarsi alle informazioni sulla parte affidabile di Microsoft Entra ID. Microsoft Entra ID pubblica i metadati all'indirizzo https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

È consigliabile importare sempre i metadati più recenti di Microsoft Entra durante la configurazione del provider di identità SAML 2.0.

Nota

Microsoft Entra ID non legge i metadati dal provider di identità.

Aggiungere l'ID di Microsoft Entra come parte affidabile

È necessario abilitare la comunicazione tra il provider di identità SAML 2.0 e l'ID Microsoft Entra. Questa configurazione dipende dal tuo specifico provider di identità e dovresti consultare la sua documentazione. In genere si imposta l'ID relying party allo stesso valore dell'entityID dai metadati di Microsoft Entra.

Nota

Verificare che l'orologio del server del provider di identità SAML 2.0 sia sincronizzato con un'origine di ora precisa. L'impostazione non corretta dell'ora può comportare un errore degli accessi federati.

Installare PowerShell per l'accesso con il provider di identità SAML 2.0

Dopo aver configurato il provider di identità SAML 2.0 per l'uso con l'accesso a Microsoft Entra, il passaggio successivo consiste nel scaricare e installare il modulo Microsoft Graph PowerShell . Dopo l'installazione, questi cmdlet verranno usati per configurare i domini Microsoft Entra come domini federati.

Il modulo Microsoft Graph PowerShell è un download per la gestione dei dati delle organizzazioni in Microsoft Entra ID. Questo modulo installa un set di cmdlet in PowerShell; questi cmdlet vengono eseguiti per configurare l'accesso Single Sign-On a Microsoft Entra ID e a loro volta a tutti i servizi cloud a cui si è iscritti. Per istruzioni su come scaricare e installare i cmdlet, vedere Installare Microsoft Graph PowerShell SDK.

Configurare un trust tra il provider di identità SAML e Microsoft Entra ID

Prima di configurare la federazione in un dominio Microsoft Entra, deve essere configurato un dominio personalizzato. Non è possibile eseguire la federazione del dominio predefinito fornito da Microsoft. Il dominio predefinito di Microsoft termina con onmicrosoft.com. Si eseguirà una serie di cmdlet di PowerShell per aggiungere o convertire domini per l'accesso Single Sign-On.

Ogni dominio di Microsoft Entra che si desidera federare utilizzando il fornitore di identità SAML 2.0 deve essere aggiunto come dominio di accesso singolo o convertito in un dominio di accesso singolo da un dominio standard. L'aggiunta o la conversione di un dominio configura un trust tra il provider di identità SAML 2.0 e l'ID Microsoft Entra.

La procedura seguente illustra i passaggi per la conversione di un dominio standard esistente in un dominio federato con SP-Lite SAML 2.0.

Nota

Dopo l'esecuzione di questo passaggio, potrebbe verificarsi un'interruzione del dominio che potrebbe influire sugli utenti per un periodo di massimo 2 ore.

Configurazione di un dominio in Microsoft Entra Directory per la federazione

  1. Connettersi a Microsoft Entra Directory come amministratore tenant:

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

  2. Configurare il dominio di Microsoft 365 desiderato per l'uso della federazione 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. È possibile ottenere la stringa codificata in Base64 del certificato di firma a partire dal file di metadati dell'IdP. Di seguito è riportato un esempio di questa posizione, ma può essere leggermente diverso in base all'implementazione.

    <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>

Per altre informazioni, vedere New-MgDomainFederationConfiguration.

Nota

È necessario usare $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" solo se avete configurato un'estensione ECP per il provider di identità. I client di Exchange Online, ad eccezione di Outlook Web Application (OWA), usano un endpoint attivo basato su POST. Se il servizio token di sicurezza SAML 2.0 implementa un endpoint attivo simile all'implementazione ECP di Shibboleth di un endpoint attivo, potrebbe essere possibile per questi rich client interagire con il servizio Exchange Online.

Dopo aver configurato la federazione, è possibile tornare a "non federato" (o "gestito"), tuttavia questa modifica richiede fino a due ore per completare e richiede l'assegnazione di nuove password casuali per l'accesso basato sul cloud a ogni utente. La reimpostazione della modalità gestita potrebbe essere necessaria in alcuni scenari per correggere un errore nelle impostazioni. Per altre informazioni sulla conversione del dominio, vedere Remove-MgDomainFederationConfiguration.

Effettuare il provisioning dei principali utente in Microsoft Entra ID/Microsoft 365

Prima di poter autenticare gli utenti in Microsoft 365, è necessario configurare l'ID Microsoft Entra con entità utente che corrispondono all'asserzione nella rivendicazione SAML 2.0. Se questi principali utente non sono noti in anticipo all'ID Microsoft Entra, non possono essere usati per l'accesso federato. È possibile usare Microsoft Entra Connect o PowerShell per effettuare il provisioning degli utenti.

Microsoft Entra Connect può essere usato per provisionare i principali nei domini nel directory di Microsoft Entra dalla Active Directory locale. Per informazioni più dettagliate, vedere Integrare le directory locali con Microsoft Entra ID.

PowerShell può essere usato anche per automatizzare l'aggiunta di nuovi utenti all'ID Microsoft Entra e per sincronizzare le modifiche dalla directory locale. Per usare i cmdlet di PowerShell, è necessario scaricare il modulo PowerShell di Microsoft Graph.

Questa procedura illustra come aggiungere un singolo utente all'ID Microsoft Entra.

  1. Connettersi a Microsoft Entra Directory come amministratore tenant usando Connect-MgGraph.

  2. Creare un nuovo principale utente.

    $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"

Per altre informazioni, vedere New-MgUser.

Nota

Il valore "UserPrincipalName" deve corrispondere al valore che verrà inviato per "IDPEmail" nell'attestazione SAML 2.0 e il valore "OnPremisesImmutableId" deve corrispondere al valore inviato nell'asserzione "NameID".

Verifica l'autenticazione unica con il tuo IdP SAML 2.0

Prima di verificare e gestire l'accesso Single Sign-On (anche noto come federazione delle identità), l'amministratore deve esaminare le informazioni ed eseguire i passaggi negli articoli seguenti per configurare l'accesso Single Sign-On con il provider di identità basato su SP-Lite SAML 2.0:

  1. Sono stati esaminati i requisiti del protocollo Microsoft Entra SAML 2.0
  2. Hai configurato il provider di identità SAML 2.0
  3. Installare PowerShell per l'autenticazione Single Sign-On (SSO) con il fornitore di identità SAML 2.0
  4. Configurare un trust tra il provider di identità SAML 2.0 e l'ID Microsoft Entra
  5. È stato eseguito il provisioning di un principale utente di test noto in Microsoft Entra ID (Microsoft 365) tramite PowerShell o Microsoft Entra Connect.
  6. Configurare la sincronizzazione della directory con Microsoft Entra Connect.

Dopo aver configurato l'accesso SSO con il provider di identità basato su SAML 2.0 SP-Lite, è necessario verificare che funzioni correttamente. Per altre informazioni sul test dell'accesso Single Sign-On basato su SAML, vedere Testare l'accesso Single Sign-On basato su SAML.

Nota

Se è stato convertito un dominio, invece che aggiungerne uno, potrebbero essere necessarie fino a 24 ore per la configurazione di Single Sign-On. Prima di verificare l'accesso Single Sign-On, completare la configurazione della sincronizzazione di Active Directory, sincronizzare le directory e attivare gli utenti sincronizzati.

Verificare manualmente la corretta configurazione di Single Sign-On

La verifica manuale fornisce altri passaggi che è possibile eseguire per assicurarsi che il provider di identità SAML 2.0 funzioni correttamente in molti scenari. Per verificare che l'accesso Single Sign-On sia configurato correttamente, completare la procedura seguente:

  1. Su un computer collegato a un dominio, accedi al tuo servizio cloud utilizzando lo stesso nome di accesso che usi per le tue credenziali aziendali.
  2. Seleziona all'interno del campo password. Se l'accesso Single Sign-On è configurato, la casella della password è ombreggiata e verrà visualizzato il messaggio seguente: "Ora è necessario accedere presso <la tua azienda>".
  3. Seleziona il link Accedi alla tua azienda<>. Se riesci ad accedere, l'accesso Single Sign-On è stato configurato.

Passaggi successivi