Risoluzione dei problemi di ADFS in Azure Active Directory e di Office 365

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 3079872
Questo articolo illustra la risoluzione dei problemi per problemi di autenticazione per gli utenti federati Azure Active Directory o di Office 365 del flusso di lavoro.
Sintomi
  • Utenti federati non possono accedere a Office 365 oppure Microsoft Azure anche se gestiti solo cloud utenti che dispongono di un suffisso UPN domainxx.onmicrosoft.com possono accedere senza problemi.
  • Reindirizzamento a Active Directory Federation Services (ADFS) o STS non si verifica per un utente federato. In alternativa, viene generato un errore "Impossibile visualizzare la pagina".
  • Quando si tenta di eseguire l'autenticazione con ADFS, viene visualizzato un messaggio di avviso relativi ai certificati in un browser. Questo significa convalida dei certificati o che il certificato non è attendibile.
  • Errore "Metodo di autenticazione sconosciuto" o messaggi di errore indicanti che AuthnContext non è supportato. Inoltre, gli errori al livello di ADFS o STS quando si viene reindirizzati da Office 365.
  • ADFS genera un errore "Accesso negato".
  • ADFS genera un errore che indica la presenza di problemi di accesso del sito. Ciò include un numero di ID di riferimento.
  • Viene chiesto ripetutamente le credenziali a livello di ADFS.
  • Impossibile autenticare gli utenti federati da una rete esterna o quando si utilizza un'applicazione che utilizza la route di rete esterna (ad esempio, Outlook).
  • Utenti federati non possono accedere dopo la modifica di un certificato di firma di token di ADFS.
  • Quando un utente federato accede a Office 365 in Microsoft Azure, viene generato un errore "Siamo spiacenti, ma problemi durante l'accesso". Questo errore include codici di errore, ad esempio C 8004786, 80041034, 80041317, 80043431, 80048163, 06 80045C, 8004789A o CATTIVE richiedono.

Risoluzione dei problemi del flusso di lavoro
  1. Access https://Login.microsoftonline.com, quindi immettere (nome di accesso dell'utente federatoun utente@esempio.COM). Dopo aver premuto Tab per rimuovere lo stato attivo nella finestra di accesso, verificare se lo stato della pagina Cambia "Reindirizzamento" e quindi si viene reindirizzati di Active Directory Federation Services (ADFS) per l'accesso.

    Quando si verifica il reindirizzamento, viene visualizzata la pagina seguente:

    La schermata per il passaggio 1
    1. Se si verifica alcun reindirizzamento e viene chiesto di immettere una password nella stessa pagina, significa che Azure Active Directory (AD) o Office 365 non riconosce l'utente o il dominio dell'utente deve essere federato. Per controllare se vi è una relazione di trust federativa tra servizi Azure o Office 365 e il server ADFS, eseguire il Get-msoldomain cmdlet di AD PowerShell Azure. Se un dominio è federato, la proprietà di autenticazione verrà visualizzata come "Federato", come nell'immagine riportata di seguito:

      Passaggio sul dominio federato
    2. Se si verifica il reindirizzamento, ma non si viene reindirizzati al server ADFS per l'accesso, verificare se il nome del servizio ADFS risolva correttamente l'IP e se esso può connettersi a tale IP sulla porta TCP 443.

      Se il dominio viene visualizzato come "Federato", è possibile ottenere informazioni di relazione di trust federativa eseguendo i comandi seguenti:
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      Controllare l'URI, URL e certificati del partner della federazione che per Office 365 o AD Azure è configurato.
  2. Dopo essere stati reindirizzati su ADFS, il browser che genera un errore di certificato relativi ai trust e per alcuni client e dispositivi che non consente di stabilire una sessione SSL con AD FS. Per risolvere questo problema, attenersi alla seguente procedura:
    1. Assicurarsi che il certificato di comunicazione del servizio ADFS presentati al client corrisponde a quella che viene configurato per ADFS.

      Nell'immagine riportata sul passaggio a

      In teoria, il certificato di comunicazione del servizio ADFS deve essere lo stesso certificato SSL presentato al client quando tenta di stabilire un tunnel SSL con il servizio ADFS.

      In ADFS 2.0:

      • Associare il certificato a IIS-> primo sito predefinito.
      • Utilizzare lo snap-in ADFS per aggiungere lo stesso certificato come certificato di comunicazioni di servizio.

      AD FS 2012 R2:

      • Utilizzare lo snap-in ADFS o Aggiungere-adfscertificate comando per aggiungere un certificato di comunicazione del servizio.
      • Utilizzare il Set-adfssslcertificate comando per impostare lo stesso certificato per l'associazione di SSL.

    2. Assicurarsi che il certificato di comunicazione del servizio ADFS è considerato attendibile dal client.
    3. Se SNI – client che non sta tentando di stabilire una sessione SSL con AD FS o WAP R2 2-12, il tentativo potrebbe non riuscire. In questo caso, è possibile aggiungere una voce di Fallback nei server ADFS o WAP per supportare i client non-SNI. Per ulteriori informazioni, vedere post di blog di seguito:
  3. È possibile riscontrare un errore di "Metodo di autenticazione sconosciuto" o messaggi di errore indicanti che AuthnContext non è supportato il livello di ADFS o STS quando si viene reindirizzati da Office 365. Questo è più comune quando Office 365 e AD Azure reindirizza ad Active Directory FS o STS tramite un parametro che consente di applicare un metodo di autenticazione. Per applicare un metodo di autenticazione, utilizzare uno dei seguenti metodi:
    • Per WS-Federation, utilizzare una stringa di query WAUTH per imporre un metodo di autenticazione preferenziale.
    • Per SAML2.0, utilizzare la seguente:
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    Quando il metodo di autenticazione imposta viene inviato con un valore non corretto oppure se tale metodo di autenticazione non è supportata in ADFS o STS, viene visualizzato un messaggio di errore prima che sono autenticati.

    La tabella seguente mostra il tipo di autenticazione gli URI che vengono riconosciuti da ADFS per WS-Federation autenticazione passivo.
    Metodo di autenticazione desideratoURI wauth
    Autenticazione di nome e la password dell'utenteurn: oasis: nomi: tc: SAML:1.0:am:password
    Autenticazione del client SSLurn: ietf:rfc:2246
    Autenticazione integrata di Windowsurn: federation: autenticazione: windows

    È supportato SAML classi di contesto di autenticazione

    Metodo di autenticazione Classe di contesto autenticazione URI
    Nome utente e passwordurn: oasis: nomi: tc: SAML:2.0:ac:classes:Password
    Trasporto protetto da passwordurn: oasis: nomi: tc: SAML:2.0:ac:classes:PasswordProtectedTransport
    Client di Transport Layer Security (TLS)urn: oasis: nomi: tc: SAML:2.0:ac:classes:TLSClient
    Certificato x. 509urn: oasis: nomi: tc: SAML:2.0:ac:classes:X. 509
    Autenticazione integrata di Windowsurn: federation: autenticazione: windows
    Kerberosurn: oasis: nomi: tc: SAML:2.0:ac:classes:Kerberos

    Per assicurarsi che il metodo di autenticazione è supportato a livello di ADFS, verificare quanto segue.

    AD FS 2.0

    Sotto /ADFS/ls/Web.config, assicurarsi che sia presente la voce per il tipo di autenticazione.

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    Aggiungere nome = "Forms" page="FormsSignIn.aspx" / >
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    AD FS 2.0: Come modificare il tipo di autenticazione locale

    AD FS 2012 R2

    Sotto Gestione di Active Directory FS, fare clic su Criteri di autenticazione nello snap-in ADFS.

    Nel Autenticazione principale Fare clic su Modifica accanto a Impostazioni globali. È inoltre possibile fare Criteri di autenticazione e quindi selezionare Modifica di autenticazione principale globale. O, nel Azioni riquadro, seleziona Modifica di autenticazione principale globale.

    Nel Modifica dei criteri di autenticazione globali finestra via il Primario scheda, è possibile configurare le impostazioni come parte del criterio di autenticazione globali. Per l'autenticazione primaria, ad esempio, è possibile selezionare i metodi di autenticazione disponibili in Extranet e Intranet.

    * * Rendere assicurarsi che sia selezionata la casella di controllo di metodo di autenticazione richiesto.
  4. Se si ottiene per di ADFS e di immettere le credenziali, ma è Impossibile autenticare, controllare i seguenti problemi.
    1. Problema di replica Active Directory

      Se la replica di Active Directory è interrotta, potrebbero non sincronizzare le modifiche apportate all'utente o al gruppo sui controller di dominio. Tra i controller di dominio, potrebbe trattarsi di una password, UPN, GroupMembership, o ProxyAddress mancata corrispondenza che interessa la risposta di ADFS (autenticazione e crediti). È consigliabile iniziare la ricerca sui controller di dominio nello stesso sito di ADFS. Esecuzione di un comando repadmin /showreps o un DCdiag /v comando deve rivelare se vi è un problema sui controller di dominio che ADFS è molto probabile che al contatto.

      È inoltre possibile raccogliere un riepilogo della replica di Active Directory per assicurarsi che le modifiche di Active Directory vengono replicate correttamente in tutti i controller di dominio. Il repadmin /showrepl * /csv > showrepl. csv l'output è utile per verificare lo stato di replica. Per ulteriori informazioni, vedere Risoluzione dei problemi di replica di Active Directory.
    2. Account bloccato o disabilitato in Active Directory

      Quando un utente finale viene autenticato tramite ADFS, egli non riceverà un messaggio di errore indicante che l'account è bloccato o disabilitato. Da ADFS e il controllo degli accessi, sarà possibile determinare se l'autenticazione non riuscita a causa di una password non corretta, se l'account è disattivato o bloccato e così via.

      Per abilitare ADFS e il controllo su di ADFS server di accesso, attenersi alla seguente procedura:
      1. Utilizzare criteri locali o di dominio per attivare l'esito positivo e negativo per i seguenti criteri:
        • Controlla eventi di accesso, che si trova nel Computer computer\Impostazioni Windows\Impostazioni setting\Local Criteri Locali\Criterio controllo"
        • Controlla accesso agli oggetti, che si trova nel Computer computer\Impostazioni Windows\Impostazioni setting\Local Criteri Locali\Criterio controllo"
        Nell'immagine riportata sui criteri
      2. Disattivare il criterio seguente:

        Controllo: Forza sottocategoria criteri di controllo (Windows Vista o versione successiva) per eseguire l'override di impostazioni categoria

        Questo criterio si trova nel Computer computer\Impostazioni Windows\Impostazioni setting\Local locali\Impostazioni opzione.

        La schermata sui criteri

        Se si desidera configurare questa impostazione mediante il controllo avanzato, fare clic su qui.
      3. Configurare ADFS per il controllo:
        1. Apri AD FS 2.0 snap-in Gestione.
        2. Nel riquadro Azioni , fare clic su Modifica proprietà del servizio federativo.
        3. Nella proprietà del servizio federativo nella finestra di dialogo scegliere la eventi scheda.
        4. Selezionare il operazioni riuscite e controlli non riusciti le caselle di controllo.

          Il sceenshot sull'attivazione del controllo di ADFS
        5. Eseguire GPupdate /force sul server.
    3. Nome dell'entità servizio (SPN) non è registrato correttamente

      Potrebbe esserci SPN duplicati o un nome SPN registrato con un account diverso dall'account del servizio ADFS. Per un'installazione di AD FS Farm, assicurarsi che SPN HOST/AD FSservicename viene aggiunto l'account del servizio che esegue il servizio ADFS. Per un'installazione autonoma di ADFS, dove il servizio è in esecuzione Servizio di rete, il SPN deve essere nell'account di computer server che ospita ADFS.

      La schermata il nome del servizio ADFS

      Assicurarsi che non vi siano SPN duplicati per il servizio ADFS, poiché ciò potrebbe causare errori di autenticazione intermittenti con AD FS. Per elencare gli SPN, eseguire SETSPN – L<ServiceAccount></ServiceAccount>.

      Nell'immagine riportata sull'elenco di SPN

      Eseguire SETSPN – FSservicename ServiceAccount HOST/annunci Per aggiungere il nome SPN.

      Eseguire SETSPN – X -F Per cercare il SPN duplicati.
    4. UPN duplicati in Active Directory

      Un utente potrebbe essere possibile autenticare tramite ADFS quando utilizzano SAMAccountName ma in grado di eseguire l'autenticazione quando si utilizza l'UPN. In questo scenario, Active Directory può contenere due utenti che hanno la stessa UPN. È possibile che le due utenti che hanno la stessa UPN quando gli utenti vengono aggiunti e modificati tramite script (ad esempio ADSIedit).

      Quando UPN viene utilizzato per l'autenticazione in questo scenario, l'utente è autenticato in base all'utente duplicato. Pertanto, non vengono convalidate le credenziali fornite.

      Per verificare se sono presenti più oggetti in Active Directory che hanno gli stessi valori di un attributo, è possibile utilizzare le query come segue:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      Assicurarsi che viene rinominato l'UPN dell'utente duplicati, in modo che la richiesta di autenticazione con il nome principale utente viene convalidata rispetto gli oggetti corretti.
    5. In uno scenario, dove si utilizza il tuo indirizzo email come ID di accesso in Office 365, e si immette lo stesso indirizzo di posta elettronica quando si viene reindirizzati al ADFS per l'autenticazione, autenticazione potrebbe non riuscire con un errore di "NO_SUCH_USER" nei registri di controllo. Per abilitare ADFS trovare un utente per l'autenticazione utilizzando un attributo UPN o SAMaccountname, è necessario configurare ADFS per supportare un ID di accesso alternativo. Per ulteriori informazioni, vedere Configurazione di ID di accesso alternativo.

      In Active Directory FS 2012 R2

      1. Installare Aggiornamento 2919355.
      2. Aggiornare la configurazione di ADFS eseguendo il seguente cmdlet PowerShell su qualsiasi server federativo della farm (se si dispone di una farm WID, è necessario eseguire questo comando sul server ADFS primario della farm):

        "Autorità di Active Directory" di TargetIdentifier - set-AdfsClaimsProviderTrust - AlternateLoginID <attribute>- LookupForests <forest domain=""></forest> </attribute>

        NotaAlternateLoginID è il nome LDAP dell'attributo che si desidera utilizzare per l'accesso. E LookupForests è l'elenco delle voci DNS che gli utenti appartengono a foreste.

        Per attivare la funzionalità di ID di accesso alternativo, è necessario configurare il AlternateLoginID e LookupForests parametri con un valore non null e valido.

    6. L'account del servizio ADFS non dispone dell'accesso in lettura sul token ADFS che è la chiave privata del certificato di firma. Per aggiungere questa autorizzazione, attenersi alla seguente procedura:
      1. Quando si aggiunge un nuovo certificato di firma di Token, viene visualizzato il seguente avviso: "Assicurarsi che la chiave privata del certificato scelto sia accessibile all'account del servizio per il servizio federativo in ogni server della farm".
      2. Fare clic su Start, scegliere Esegui, tipo MMC.exe, quindi premere INVIO.
      3. Fare clic su Filee quindi fare clic su Aggiungi/Rimuovi Snap-in.
      4. Fare doppio clic su certificati.
      5. Selezionare l'account del computer in questione e quindi fare clic su Avanti.
      6. Selezionare computer localee fare clic su Fine.
      7. Espandere certificati (Computer locale), <b00> </b00>utentel e quindi selezionare certificati.
      8. Fare il nuovo certificato di firma di token, selezionare Tutte le attivitàe quindi selezionare Gestisci chiavi Private.

        Il sceenshot su passaggio 8
      9. Aggiungere l'accesso in lettura per l'account di servizio 2.0 ADFS e quindi fare clic su OK.
      10. Chiudere MMC certificati.
    7. L'opzione Di protezione estesa per l'autenticazione di Windows è attivata per la directory virtuale di ADFS o LS. Ciò potrebbe causare problemi con determinati browser. In alcuni casi venga visualizzato ripetutamente richieste le credenziali di ADFS e questo potrebbe essere correlato al Protezione estesa impostazione che è attivata per l'autenticazione di Windows per l'applicazione di ADFS o LS in IIS.

      Il sceenshot su passaggio 8
      Quando Protezione estesa per l'autenticazione è abilitata, le richieste di autenticazione sono associate a entrambi i nomi delle entità servizio (SPN) del server a cui il client tenta di connettersi e al canale di protezione TLS (Transport Layer) esterno in cui si verifica l'autenticazione integrata di Windows. La protezione estesa migliora la funzionalità di autenticazione di Windows esistente per ridurre i server Relay Server di autenticazione o attacchi "man centrale". Tuttavia, alcuni browser non funzionano con il Protezione estesa impostazione; al contrario vengono ripetutamente richieste le credenziali e quindi negare l'accesso. La disattivazione Protezione estesa consente sia di questo scenario.

      Per ulteriori informazioni, vedere AD FS 2.0: Continuamente richieste le credenziali durante l'utilizzo del debugger di Fiddler web.

      Per AD FS 2012 R2

      Eseguire il seguente cmdlet per disattivare Extendedprotection:

      Set-ADFSProperties-ExtendedProtectionTokenCheck None

    8. Le regole di autorizzazione rilascio del trust di terze parti che si basa (RP) possono negare l'accesso agli utenti. Sul trust parte di ricorrere AD FS, è possibile configurare le regole di autorizzazione rilascio che controllano se un utente autenticato deve emettere un token per una parte che si basa. Gli amministratori possono utilizzare le attestazioni che vengono emessi per decidere se si desidera negare l'accesso a un utente che è un membro di un gruppo che verrà spostato verso l'alto come attestazione.

      Se alcuni utenti federati non possono autenticare tramite ADFS, è possibile controllare le regole di autorizzazione rilascio per il RP di Office 365 e vedere se il Consentono di accedere a tutti gli utenti regola è configurata.

      Alla schermata di informazioni sulle regole
      Se non si configura questa regola, studiando le regole di autorizzazione personalizzati per verificare se la condizione in tale regola viene restituito "true" per l'utente interessato. Per ulteriori informazioni, vedere le risorse seguenti:
      Se quando si accede direttamente al server ADFS, ma è Impossibile autenticare quando si accede AD FS tramite un proxy di AD FS, è possibile autenticare da una rete intranet, verificare i seguenti problemi:
      • Problema di sincronizzazione ora sul server ADFS e proxy di AD FS

        Assicurarsi che l'ora del server ADFS e l'ora del proxy sono sincronizzati. Quando l'ora del server ADFS è disattivata per più di cinque minuti dal momento in cui il controller di dominio, si verificano errori di autenticazione. Quando l'ora sul proxy di ADFS non è sincronizzato con ADFS, il trust proxy interessato e interrotto. Pertanto, una richiesta che passa attraverso il proxy di AD FS ha esito negativo.
      • Verificare se il proxy di AD FS Trust con il servizio ADFS funziona correttamente. Eseguire nuovamente la configurazione del proxy se si sospetta che il proxy è corrotta.
  5. Dopo un annuncio di Azure, token di problemi di ADFS o Office 365 genera un errore. In questo caso, verificare i seguenti problemi:
    • Le attestazioni che vengono emessi da ADFS nel token devono corrispondere i rispettivi attributi dell'utente in Active Directory Azure. Nel token ad Azure o Office 365, le attestazioni seguenti sono obbligatori.

      WSFED:
      UPN: Il valore dell'attestazione deve corrispondere l'UPN degli utenti in Active Directory Azure.
      ImmutableID: Il valore dell'attestazione deve corrispondere il sourceAnchor o ImmutableID dell'utente in Active Directory Azure.

      Per ottenere il valore dell'attributo utente in Active Directory di Azure, eseguire la seguente riga di comando: Get-MsolUser – UserPrincipalName<UPN></UPN>

      SAML 2.0:
      IDPEmail: Il valore dell'attestazione deve corrispondere il nome principale utente degli utenti in Active Directory Azure.
      NAMEID: Il valore dell'attestazione deve corrispondere il sourceAnchor o ImmutableID dell'utente in Active Directory Azure.

      Per ulteriori informazioni, vedere Utilizzare un provider di identità SAML 2.0 per implementare servizio single sign-on.

      Esempi:
      Questo problema può verificarsi quando viene modificato l'UPN di un utente sincronizzato in Active Directory, ma senza aggiornamento della directory in linea. In questo scenario, è possibile correggere UPN dell'utente in Active Directory (al nome di accesso dell'utente correlati) o eseguire il seguente cmdlet per modificare il nome di accesso dell'utente correlato nella directory in linea:

      Set-MsolUserPrincipalName - UserPrincipalName [ExistingUPN] - NewUserPrincipalName [DomainUPN-Active Directory]

      È anche possibile che si utilizza AADsync per la sincronizzazione INVIARE come UPN e EMPID come SourceAnchor, ma la parte che si basa regole a livello di ADFS non sono state aggiornate per l'invio di attestazioni INVIARE come UPN e EMPID come ImmutableID.
    • Non c'è una firma di token certificato mancata corrispondenza tra ADFS e Office 365.

      Questo è uno dei problemi più comuni. ADFS utilizza il certificato di firma di token per firmare il token che viene inviato all'utente o applicazione. La relazione di trust tra l'ADFS e Office 365 è una relazione di trust federativa basato su questo certificato di firma di token (ad esempio, Office 365 verifica che il token ricevuto viene firmato con un certificato di firma di token del provider di attestazioni [il servizio ADFS] attendibile).

      Se il certificato per la firma di token di ADFS causa automatica certificato Rollover o dall'intervento dell'amministratore dopo o prima della scadenza certificato, i dettagli del nuovo certificato deve essere aggiornato su affittuario Office 365 per il dominio federato.

      Office 365 o Azure Active Directory tenterà di raggiungere il servizio ADFS, purché il raggiungibile dalla rete pubblica. Si tenta di eseguire il polling dei metadati di federazione ADFS a intervalli regolari, per tirare le modifiche di configurazione di ADFS, principalmente il certificato di firma di token. Se questo processo non funziona, l'amministratore globale deve vedere una notifica sul portale Office 365, avviso sulla scadenza certificato per la firma di Token e le azioni da adottare per aggiornarlo.

      È possibile utilizzare Get-MsolFederationProperty - DomainName<domain></domain> Per eseguire il dump della proprietà federazione ADFS e Office 365. Qui è possibile confrontare l'identificazione personale del TokenSigningCertificate, per verificare se la configurazione di Office 365 tenant per il dominio federato è sincronizzata con AD FS. Se si trova una corrispondenza nella configurazione del certificato di firma di token, eseguire il comando seguente per aggiornare:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      È inoltre possibile eseguire il seguente strumento per pianificare un'operazione sul server ADFS che dovrà monitorare per il rollover di Auto-certificato del token di firma certificato e aggiornamento di Office 365 tenant automaticamente.

      Strumento di installazione di automazione di Microsoft Office 365 federazione aggiornamento dei metadati

      Verificare e gestire single sign-on con ADFS
    • Le regole di attestazione di trasformazione rilascio per il RP di Office 365 non sono configurate correttamente.

      In uno scenario in cui si dispone più TLD (domini di livello superiore), è possibile avere problemi di accesso se il Supportmultipledomain opzione non è stato utilizzato quando la relazione di trust RP è stata creata e aggiornata. Per ulteriori informazioni, fare clic su qui.
    • Assicurarsi che la crittografia di token è non utilizzato da Active Directory, ADFS o STS quando viene emesso un token di Azure Active Directory o di Office 365.
  6. Sono disponibili credenziali memorizzate nella cache non aggiornate in Gestione credenziali Windows.

    A volte durante l'accesso in da una workstation al portale (o quando si utilizza Outlook), quando viene richiesto per le credenziali, possono essere salvate le credenziali al servizio di destinazione (Office 365 o AD FS) in Gestione credenziali Windows (gestione di Accounts\Credential Panel\User di controllo). Questo consente di evitare una richiesta di credenziali per un certo tempo, ma potrebbe causare un problema dopo aver cambiato la password dell'utente e la gestione di credenziali non è aggiornata. In questo scenario, le credenziali non aggiornate vengono inviate al servizio ADFS e pertanto l'autenticazione non riesce. Può essere utile rimuovere o aggiornare le credenziali memorizzate in Gestione credenziali Windows.
  7. Assicurarsi che Secure Hash Algorithm configurato sul Trust parte basarsi per Office 365 è impostato su SHA1.

    Quando la relazione di trust tra il servizio STS/ADFS e Azure Active Directory oppure Office 365 utilizza il protocollo SAML 2.0, algoritmo Hash protetto è configurato per la firma digitale deve essere SHA1.
  8. Se nessuna delle precedenti cause applicata alla situazione, creare un caso di supporto con Microsoft e chiedere di verificare se l'account utente viene visualizzato in modo coerente sotto quest'ultimo Office 365. Per ulteriori informazioni, vedere le risorse seguenti:

    Messaggio di errore di ADFS 2.0 quando un utente federato accede a Office 365: "Errore durante l'accesso al sito"

    Un utente federato è ripetutamente richieste le credenziali quando egli si connette all'endpoint del servizio 2.0 ADFS durante l'accesso Office 365
  9. A seconda di quale servizio cloud (integrato con Active Directory Azure) si accede a, la richiesta di autenticazione inviato al ADFS può variare. Ad esempio: determinate richieste possono includere parametri aggiuntivi, ad esempio Wauth o Wfresh, e questi parametri possono provocare un comportamento diverso livello di ADFS.

    È consigliabile che i file binari di ADFS sempre mantenuto aggiornato per includere le correzioni per problemi noti. Per ulteriori informazioni sugli aggiornamenti più recenti, vedere la tabella seguente.

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 3079872 - Ultima revisione: 08/11/2015 20:19:00 - Revisione: 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtit
Feedback