Condividi tramite

Usare un provider di identità (IdP) SAML 2.0 per l'accesso Single Sign-On

  • Articolo

Questo documento contiene informazioni sull'uso di un provider di identità basato sul profilo SP-Lite conforme a SAML 2.0 come servizio token di sicurezza/provider di identità preferito. 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 di identità federate Security Assertion Markup Language (SAML) per fornire un framework di accesso 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 altre informazioni sul provider di identità basato sul profilo SP-Lite SAML 2.0, rivolgersi all'organizzazione da cui è stato 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, tra cui:
    • 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 client 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 l'accesso 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). La relying party SAML 2.0 (SP-STS) per un servizio cloud Microsoft usato in questo scenario è Microsoft Entra ID.

È consigliabile assicurarsi che i messaggi di output del provider di identità SAML 2.0 siano simili alle tracce di esempio fornite il più possibile. Usare inoltre valori di attributo specifici dei metadati di Microsoft Entra forniti, se possibile. Dopo aver soddisfatto i messaggi di output, è possibile eseguire test con Microsoft Connessione ivity 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 l'algoritmo SHA-1 di sicurezza è deprecato. Assicurarsi di usare un algoritmo più sicuro, ad esempio SHA-256. Altre informazioni sono disponibili.

Binding supportati

I binding sono i parametri di comunicazione correlati al trasporto richiesti. Ai binding 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 REINDIRIZZA per il messaggio di disconnessione 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 dell'entità utente (UPN) è elencato nella risposta SAML come elemento con il nome IDPEmail Il nome UserPrincipalName (UPN) dell'utente in Microsoft Entra ID / Microsoft 365. Il nome dell'entità utente è nel formato indirizzo di posta elettronica. Valore UPN in Windows Microsoft 365 (ID Microsoft Entra).
Autorità di certificazione Deve essere un URI del provider di identità. Non riutilizzare l'autorità di certificazione dai messaggi di esempio. Se sono presenti più domini di primo livello nei tenant di Microsoft Entra, l'autorità emittente deve corrispondere all'impostazione dell'URI specificata configurata per dominio.

Importante

Microsoft Entra ID supporta attualmente l'URI del formato NameID seguente 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>

Configurare il 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. La relying party SAML 2.0 per un servizio cloud Microsoft usato in questo scenario è Microsoft Entra ID.

Aggiungere i metadati di Microsoft Entra

Il provider di identità SAML 2.0 deve rispettare le informazioni sulla relying party 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 relying party

È necessario abilitare la comunicazione tra il provider di identità SAML 2.0 e l'ID Microsoft Entra. Questa configurazione dipende dal provider di identità specifico ed è necessario farvi riferimento alla documentazione. In genere si imposta l'ID relying party sullo stesso id 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 vuole eseguire la federazione usando il provider di identità SAML 2.0 deve essere aggiunto come dominio Single Sign-On o convertito in un dominio Single Sign-On 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. Connessione 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 con codifica Base64 del certificato di firma del 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 si configura 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 di entità utente in Microsoft Entra ID/Microsoft 365

Prima di poter autenticare gli utenti in Microsoft 365, è necessario effettuare il provisioning dell'ID Microsoft Entra con entità utente che corrispondono all'asserzione nell'attestazione SAML 2.0. Se queste entità utente non sono note in anticipo all'ID Microsoft Entra, non possono essere usate per l'accesso federato. È possibile usare Microsoft Entra Connessione o PowerShell per effettuare il provisioning delle entità utente.

Microsoft Entra Connessione può essere usato per effettuare il provisioning delle entità nei domini in Microsoft Entra Directory dal 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. Connessione a Microsoft Entra Directory come amministratore tenant usando Connessione-MgGraph.

  2. Creare una nuova entità 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".

Verificare l'accesso Single Sign-On con l'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. Il provider di identità SAML 2.0 è stato configurato
  3. Installare PowerShell per l'accesso Single Sign-On (SSO) con il provider di identità SAML 2.0
  4. Configurare un trust tra il provider di identità SAML 2.0 e l'ID Microsoft Entra
  5. È stato effettuato il provisioning di un'entità utente di test nota in Microsoft Entra ID (Microsoft 365) tramite PowerShell o Microsoft Entra Connessione.
  6. Configurare la sincronizzazione della directory usando Microsoft Entra Connessione.

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. In un computer aggiunto al dominio, accedere al servizio cloud usando lo stesso nome di accesso usato per le credenziali aziendali.
  2. Selezionare all'interno della casella password. Se l'accesso Single Sign-On è configurato, la casella della password è ombreggiata e verrà visualizzato il messaggio seguente: "You're now required to sign-in at <your company>".
  3. Selezionare il collegamento Accedi all'azienda<>. Se è possibile accedere, viene configurato l'accesso Single Sign-On.

Passaggi successivi