Accedi a Microsoft
Accedi o crea un account.
Salve,
Select a different account.
Hai più account
Scegli l'account con cui vuoi accedere.

Continuare con la risoluzione dei problemi per verificare potenziali problemi con la relying party.

Continuare con i controlli aggiuntivi relativi alla controparte.

Continuare la risoluzione dei problemi per verificare il certificato SSL.

Continuare la risoluzione dei problemi per verificare la relazione di trust tra il Proxy di applicazione Web e AD FS proxy.

L'associazione sia in conflitto con l'associazione del certificato di ADFS sulla porta 443.

Qual è il problema si possono incontrare SSO?

Questo problema può verificarsi la pagina di accesso ADFS o a lato dell'applicazione.

Se il problema si verifica la pagina di accesso AD FS, viene visualizzato un "errore", "HTTP 503 Servizio non disponibile" o altro messaggio di errore. L'URL della pagina di errore viene visualizzato il nome di servizio di ADFS come fs.contoso.com.

Se il problema si verifica al lato dell'applicazione, l'URL della pagina di errore viene visualizzato l'indirizzo IP o il nome del sito del servizio di destinazione.

Dove è si verifica questo problema?

Questo problema influisce tutti gli utenti?

L'utente può accedere qualsiasi le relying party?

Questo problema si verifica in uno scenario AD Azure?

L'utente può accedere qualsiasi le relying party?

Se il certificato di firma di token è stato rinnovato recentemente da ADFS, verificare se il nuovo certificato viene prelevato dal partner della federazione. Nel caso in cui ADFS utilizza un token di decrittografia di certificato che è stato inoltre rinnovato recentemente, eseguire lo stesso controllo. Per verificare se il token ADFS corrente firma certificato su ADFS corrisponde a quello del partner di federazione, attenersi alla seguente procedura:

  1. Ottenere il token corrente firma certificato su ADFS eseguendo il comando seguente:
    Get-ADFSCertificate -CertificateType token-signing

  2. Nell'elenco di certificati restituiti, individuare quello con IsPrimary = TRUEe prendere nota dell'identificazione digitale.

  3. Ottenere l'identificazione personale del certificato nel partner di federazione di firma token corrente. Il proprietario dell'applicazione deve fornire questo.

  4. Confrontare le identificazioni personali dei due certificati .

Eseguire lo stesso controllo se ADFS utilizza un token rinnovato la decrittografia di certificato, ad eccezione del fatto che il comando per ottenere il token di decrittografia di certificato in ADFS è come segue:
Get-ADFSCertificate -CertificateType token-decrypting

Se il token token o certificato decrittografia certificato autofirmato, AutoCertificateRollover è attivata per impostazione predefinita per questi certificati e ADFS gestisce il rinnovo automatico dei certificati quando questi si avvicina la scadenza.

Per determinare se si stanno utilizzando i certificati autofirmati, attenersi alla seguente procedura:

  1. Eseguire il comando seguente:
    Get-ADFSCerticate -CertificateType "token-signing"
    Get-ADFSCertificate

  2. Esaminare gli attributi di certificato.
    Se gli attributi oggetto e autorità emittente iniziano con "CN = ADFS firma...", il certificato autofirmato e gestito da AutoCertRollover.

Per verificare se i certificati rinnovati automaticamente, attenersi alla seguente procedura:

  1. Eseguire il comando seguente:
    Get-ADFSProperties | FL AutoCertificateRollover
    Get-ADFSProperties

  2. Esaminare l'attributo AutoCertificateRollover.

    • Se AutoCertificateRollover = TRUE, ADFS automaticamente genera nuovi certificati (30 giorni prima della scadenza per impostazione predefinita) e li imposta come principale dei certificati (25 giorni prima della scadenza).

    • Se AutoCertificateRollover = FALSE, è necessario sostituire manualmente i certificati.

Corrispondono le identificazioni personali?

Per verificare se vi è corrispondenza, attenersi alla seguente procedura:

  1. Determinare l'algoritmo utilizzato dal componente eseguendo il comando seguente: Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    I valori possibili sono SHA1 o SHA256 .

  2. Rivolgersi al proprietario dell'applicazione per l'algoritmo utilizzato sul lato dell'applicazione.

  3. Verificare se i due algoritmi corrispondano.

Esiste una mancata corrispondenza?

È visualizzato un prompt di NTLM imprevisto o una richiesta di autenticazione basata su form?

È visualizzato un prompt per l'autenticazione a più fattori imprevisto? O è visualizzato più volte il prompt dei comandi?

Questo problema si verifica in uno scenario AD Azure?

La richiesta di autenticazione inviata AD Azure include il parametro di accesso = richiesta?

I parametri di richiesta come WAUTH e RequestedAuthNContext nelle richieste di autenticazione possono avere metodi di autenticazione specificati. Il parametro di richiesta applica la richiesta di autenticazione imprevisti?

Utilizzare i seguenti metodi per la risoluzione dei problemi.

Controllare lo stato dell'utente in Windows PowerShell o l'interfaccia utente. Se l'utente è disabilitato, consentono all'utente.

Controllare lo stato di utente con Windows PowerShell

  1. Accedere a qualsiasi controller di dominio.

  2. Aprire Windows PowerShell.

  3. Controllare lo stato dell'utente eseguendo il comando seguente:
    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    Get-ADUser

Controllare lo stato dell'utente nell'interfaccia utente

  1. Accedere a qualsiasi controller di dominio.

  2. Aprire la console di gestione di Active Directory Users and Computers .

  3. Fare clic sul nodo utenti , fare l'utente nel riquadro di destra e quindi scegliere proprietà.

  4. Fare clic sulla scheda Account .

  5. In Opzioni Account, verificare se è selezionato l'Account è disattivato .
    The "Account is disabled" option under Account options

  6. Se l'opzione è selezionata, deselezionarla.

Il problema è stato risolto?

Se le proprietà dell'utente viene aggiornato in Active Directory, comporta una modifica nei metadati dell'oggetto utente. Controllare l'oggetto metadati utente per visualizzare le proprietà che sono state aggiornate di recente. Se vengono rilevate modifiche, assicurarsi che essi vengono prelevati dai servizi correlati. Per verificare se sono state eseguite modifiche di proprietà a un utente, la procedura seguente:

  1. Accedere a un controller di dominio.

  2. Aprire Windows PowerShell.

  3. Ottenere i metadati dell'oggetto utente eseguendo il comando seguente:
    repadmin /showobjmeta <destination DC> "user DN"

    Un esempio del comando è:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. Nei metadati, esaminare la colonna Data/ora per ogni attributo per qualsiasi indicazione di una modifica. Nell'esempio seguente, l'attributo userPrincipleName ha una data più recente rispetto agli altri attributi che rappresenta una modifica ai metadati dell'oggetto utente.
    repadmin show user metadata

Il problema è stato risolto?

In un ambiente di ADFS più insiemi di strutture, un trust bidirezionale è necessario tra la foresta in cui viene distribuito AD FS e gli altri insiemi che utilizzano la distribuzione di ADFS per l'autenticazione. Per verificare se la relazione di trust tra insiemi di strutture funziona come previsto, attenersi alla seguente procedura:

  1. Accedere a un controller di dominio nell'insieme di strutture in cui viene distribuito AD FS.

  2. Aprire Active Directory Domains and Trusts console di gestione.

  3. Nel console di gestione, pulsante destro del mouse sul dominio contenente il trust che si desidera verificare e scegliere proprietà.

  4. Fare clic sulla scheda trust .

  5. In domini trusted di questo dominio (trust in uscita) o domini trusting di questo dominio (trust in ingresso), fare clic sul trust da verificare e quindi scegliere proprietà.

  6. Fare clic su convalida.
    Nella finestra di dialogo Servizi di dominio Active Directory , selezionare una delle opzioni.

    • Se si seleziona No, si consiglia ripetere la procedura per il dominio reciproco.

    • Se si seleziona , è possibile fornire una credenziale utente con privilegi amministrativi per il dominio reciproco. Non è necessario eseguire la stessa procedura per il dominio reciproco.

Active Directory Domain Services

  • Il problema è stato risolto?

L'applicazione Scarica Token è utile quando il debug di problemi con il servizio federativo, nonché la convalida personalizzata richiedere regole. Non è una soluzione ufficiale, ma una buona soluzione Debug indipendente che è consigliabile ai fini della risoluzione dei problemi.

Prima di utilizzare l'applicazione Dump Token, è necessario:

  1. Del componente di informazioni per l'applicazione che si desidera accedere. Se viene implementata l'autenticazione OAuth, informazioni OAuth client anche.

  2. Consente di impostare l'applicazione Dump Token.

Ottenere la controparte e le informazioni sul client OAuth

Se si utilizza una relying party convenzionale, procedere come segue:

  1. Sul server ADFS, aprire Windows PowerShell con l'opzione Esegui come amministratore .

  2. Aggiungi annuncio componente ADFS 2.0 per Windows PowerShell utilizzando il comando seguente:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Ottenere informazioni sull'entità componente eseguendo il comando seguente:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Ottenere le informazioni sul client OAuth eseguendo il comando seguente:
    $client = Get-AdfsClient ClientName

Se si utilizza la funzionalità gruppo di applicazioni in Windows Server 2016, attenersi alla procedura descritta di seguito:

  1. Sul server ADFS, aprire Windows PowerShell con l'opzione Esegui come amministratore .

  2. Ottenere informazioni sull'entità componente eseguendo il comando seguente:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Se il client OAuth è pubblico, il client di ottenere informazioni eseguendo il comando seguente:
    $client = Get-AdfsNativeClientApplication ClientName

    Se il client OAuth riservato, il client di ottenere informazioni eseguendo il comando seguente:
    $client = Get-AdfsServerApplication ClientName

Impostare l'applicazione Dump Token

Per impostare l'applicazione Dump Token, eseguire i seguenti comandi nella finestra di Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Continuare con i seguenti metodi di risoluzione dei problemi. Al termine di ogni metodo, vedere se il problema è risolto. In caso contrario, utilizzare un altro metodo.

In questo metodo, è necessario innanzitutto ottenere il dettagli di criteri e quindi utilizzare l'applicazione Dump Token per la diagnosi il criterio per verificare se l'utente è interessato.

Ottenere i dettagli dei criteri

$rp. IssuanceAuthorizationRules Mostra le regole di autorizzazione del componente di.

In Windows Server 2016 e versioni successive, è possibile utilizzare $rp. AccessControlPolicyName per configurare i criteri di autenticazione e autorizzazione. Se $rp. AccessControlPolicyName ha valore, un criterio di controllo di accesso in loco determina i criteri di autorizzazione. In questo caso , $rp. IssuanceAuthorizationRules è vuoto. Utilizzare $rp. ResultantPolicy per scoprire i dettagli sui criteri di controllo di accesso.

Se $rp. ResultantPolicy non sono i dettagli sui criteri, esaminare le regole di domanda effettiva. Per ottenere le regole attestazione, procedere come segue:

  1. Impostare il criterio di controllo di accesso $null eseguendo il comando seguente:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null

  2. Ottenere informazioni sull'entità componente eseguendo il comando seguente:
    $rp = Get-AdfsRelyingPartyTrust RPName

  3. Check $rp.IssuanceAuthorizationRulese$rp. AdditionalAuthenticationRules.

Utilizzare il Token Dump app per diagnosticare i criteri di autorizzazione

  1. Impostare i criteri di autenticazione Token Dump dello stesso come controparte fallita.

  2. Richiedere all'utente di aprire uno dei collegamenti riportati di seguito in base ai criteri di autenticazione che è impostata.

    • WS-Fed:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML-P:https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Imporre l'autenticazione a più fattori:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  3. Accedere la pagina di accesso.

Il risultato è l'insieme di attestazioni dell'utente. Verificare se esiste qualcosa nel criterio di autorizzazione che nega in modo esplicito o consente all'utente basato su tali attestazioni.

Il problema è stato risolto?

  1. Configurare le regole attestazione nell'applicazione di Dump Token siano le stesse regole attestazione del componente di errore.

  2. Configurare il criterio Dump Token di autenticazione per essere lo stesso errore controparte.

  3. Richiedere all'utente di aprire uno dei collegamenti riportati di seguito in base ai criteri di autenticazione che è impostata.

    • WS-Fed:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML-P:https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Imporre l'autenticazione a più fattori:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Accedere la pagina di accesso.

Questo è l'insieme di attestazioni che la relying party passa per l'utente. Se le attestazioni sono mancanti o imprevisto, individuare il criterio di rilascio per scoprire il motivo.

Se tutte le attestazioni sono presenti, rivolgersi al proprietario dell'applicazione per vedere quale attestazione è mancante o non previsto.

Il problema è stato risolto?

Se le regole di autorizzazione di controllo per dispositivi, verificare se uno qualsiasi di queste affermazioni dispositivo mancano nell'elenco delle attestazioni che si ottiene da app Dump Token. Le attestazioni mancante potrebbero impedire l'autenticazione dei dispositivi. Per ottenere i crediti da app Dump Token, seguire i passaggi della sezione utilizza il Token Dump app per diagnosticare i criteri di autorizzazione nel metodo di verifica dei criteri di autorizzazione se l'utente ha subito l'impatto .

Di seguito sono riportate le attestazioni del dispositivo. Le regole di autorizzazione possono utilizzare alcuni di essi.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser

  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown

  • http://schemas.microsoft.com/2014/02/deviceusagetime

  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant

  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Se esiste un'attestazione manca, la procedura in per assicurarsi che l'ambiente è configurato per l'autenticazione dei dispositivi di accesso condizionato locale configurare utilizzando registrata dispositivi .

Se tutte le attestazioni sono presenti, vedere se i valori dei crediti da app Dump Token corrispondono ai valori richiesti nei criteri di autorizzazione.

Il problema è stato risolto?

Utilizzare i seguenti metodi per la risoluzione dei problemi. Al termine di ogni metodo, vedere se il problema è risolto. In caso contrario, utilizzare un altro metodo.

Se un utente tenta di accedere a servizi Azure, essi verranno reindirizzati al ADFS per l'autenticazione per un dominio federato. Uno dei possibili motivi per cui un accesso non è che l'utente non è ancora sincronizzato con Azure Active Directory. È possibile che un ciclo da Azure Active Directory per ADFS dopo la prima autenticazione tenta in ADFS. Per determinare se l'utente è sincronizzato con Active Directory Azure, procedere come segue:

  1. Scaricare e installare il modulo di Azure PowerShell di Active Directory per Windows PowerShell.

  2. Aprire Windows PowerShell con l'opzione "Esegui come amministratore".

  3. Avviare la connessione AD Azure eseguendo il comando seguente:
    Connect-MsolService

  4. Fornire le credenziali di amministratore globale per la connessione.

  5. Ottenere l'elenco di utenti in Active Directory Azure eseguendo il comando seguente:
    Get-MsolUser

  6. Verificare se l'utente è presente nell'elenco.

Se l'utente non è presente nell'elenco, eseguire la sincronizzazione all'utente di Active Directory Azure.

Il problema è stato risolto?

Active Directory Azure richiede immutableID e UPN dell'utente per autenticare l'utente.

Nota: immutableID è l'acronimo di sourceAnchor nei seguenti strumenti:

  • Azure sincronizzazione di Active Directory

  • Sincronizzazione azure Active Directory (DirSync)

è possibile utilizzare Connetti AD Azure per la gestione automatica di attendibilità ADFS ad Azure. Se non si gestisce la relazione di trust tramite Azure Connect di Active Directory, si consiglia di eseguire in modo che una download Azure Connect AD. Consente di azure Connect AD automatiche richiedere la gestione delle regole in base alle impostazioni di sincronizzazione.

Per verificare se l'attestazione basata su regole per immutableID e UPN in ADFS corrisponde quanto AD Azure utilizza, attenersi alla seguente procedura:

  1. Ottenere sourceAnchor e UPN in Azure Connect di Active Directory.

    1. Connettersi AD Azure aperto.

    2. Fare clic su configurazione di visualizzazione corrente.
      Azure AD Connect -View current configuration

    3. Nella pagina Revisione della soluzione , prendere nota dei valori di Ancoraggio di origine e Il nome dell'entità utente.
      Azure AD Connect -Review your solution

  2. Verifica della regola configurata sul server ADFS di richiedere i valori di immutableID (sourceAnchor) e UPN corrispondente.

    1. Aprire l'ADFS sul server ADFS, console di gestione.

    2. Fare clic su componente trust.

    3. Il trust di terze parti relying party con AD Azure, destro, quindi scegliere Modifica criteri di rilascio attestazioni .

    4. Aprire la regola attestazione UPN e ID di immutabile.

    5. Verificare se le variabili di query per i valori di immutableID e UPN sono per lo più quelli visualizzati in Azure Connect di Active Directory.
      Issue UPN and ImmutableID

    6. Se esiste una differenza, utilizzare uno dei metodi descritti di seguito:

      • Se ADFS è gestito da Azure Connect di Active Directory, è possibile reimpostare il trust di terze parti relying utilizzando Azure Connect di Active Directory.

      • Se non è gestito da Azure Connect AD ADFS, correggere le attestazioni con gli attributi di destra.
         

Il problema è stato risolto?

Le informazioni saranno utilizzato nei passaggi successivi della risoluzione dei problemi.

 

Se si utilizza una relying party convenzionale, procedere come segue:

  1. Sul server ADFS primario, aprire Windows PowerShell con l'opzione Esegui come amministratore .

  2. Aggiungi annuncio componente ADFS 2.0 per Windows PowerShell utilizzando il comando seguente:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Ottenere informazioni sull'entità componente eseguendo il comando seguente:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Ottenere le informazioni sul client OAuth eseguendo il comando seguente:
    $client = Get-AdfsClient ClientName

Se si utilizza la funzionalità gruppo di applicazioni in Windows Server 2016, attenersi alla procedura descritta di seguito:

  1. Sul server ADFS primario, aprire Windows PowerShell con l'opzione Esegui come amministratore .

  2. Ottenere informazioni sull'entità componente eseguendo il comando seguente:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Se il client OAuth è pubblico, ottenere le informazioni sul client eseguendo il comando seguente:
    $client = Get-AdfsNativeClientApplication ClientName

    Se il client è riservato, è possibile ottenere le informazioni del client eseguendo il comando seguente:
    $client = Get-AdfsServerApplication ClientName

Continuare con i seguenti metodi di risoluzione dei problemi.

Il componente identificatore di terze parti, ID client e reindirizza URI dovrebbero essere fornite dal proprietario dell'applicazione e il client. Tuttavia, vi può essere ancora una mancata corrispondenza tra ciò che fornisce il proprietario e che cosa sono configurati in ADFS. Ad esempio, una mancata corrispondenza potrebbe essere causata da un errore di digitazione. Controllare se le impostazioni fornite dalla corrispondenza proprietario quelle configurate in ADFS. I passaggi nella pagina precedente per ottengono le impostazioni configurate in ADFS tramite PowerShell.

Impostazioni fornite dal proprietario

Impostazioni configurate in ADFS

Utilizzare ID parte

$rp.Identifier

Utilizzare l'URI di reindirizzamento di terze parti

Una corrispondenza di prefisso o un carattere jolly del

  • $rp. WSFedEndpoint per una relying party WS-Fed

  • $rp. SamlEndpoints per una relying party SAML

ID client

$client.ClientId

URI di reindirizzamento client

Una corrispondenza di prefisso di $client. RedirectUri

Se gli elementi nella tabella corrisponde, inoltre verificare queste impostazioni corrispondano tra appaiono nella richiesta di autenticazione inviata al ADFS e quali sono configurate in ADFS. Provare a riprodurre il problema durante il quale acquisire una traccia Fiddler su richiesta di autenticazione inviata dall'applicazione per ADFS. Esaminare i parametri di richiesta per eseguire i seguenti controlli in base al tipo di richiesta.

Richieste OAuth

Una richiesta di OAuth è analogo al seguente:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Controllare se i parametri della richiesta corrispondono a quelle configurate in ADFS.

Parametri di richiesta

Impostazioni configurate in ADFS

client_id

$client.ClientId

redirect_uri

Una corrispondenza di prefisso di @client_RedirectUri

Il parametro "è risorsa" dovrebbe rappresentare una relying party valida in ADFS. Ottenere informazioni sull'entità componente eseguendo uno dei seguenti comandi.

  • Se si utilizza una relying party convenzionale, eseguire il comando seguente:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"

  • Se si utilizza la funzionalità gruppo di applicazioni in Windows Server 2016, eseguire il comando seguente:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

Richieste WS-Fed

Una richiesta di WS-Fed è analogo al seguente:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Verificare se i parametri della richiesta corrispondono a quelle configurate in ADFS:

Parametri di richiesta

Impostazioni configurate in ADFS

wtrealm

$rp.Identifier

wreply

Una corrispondenza di prefisso o caratteri jolly di $rp. WSFedEndpoint

Richieste SAML

Una richiesta SAML analogo al seguente:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Decodificare il valore del parametro SAMLRequest utilizzando l'opzione "Da DeflatedSAML" della procedura guidata testo Fiddler. Il valore decodificato è analogo al seguente:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Eseguire i seguenti controlli all'interno del valore decodificato:

  • Controllare se il valore di destinazione è nome host il nome dell'host di ADFS.

  • Controllare se il valore dell'autorità emittente corrisponde$rp.Identifier.

Note aggiuntive per SAML

  • $rp. SamlEndpoints: Mostra tutti i tipi di endpoint SAML. Gli URL corrispondenti configurati nell'endpoint viene inviata la risposta da ADFS. Un endpoint di tipo SAML è possibile utilizzare le associazioni di reindirizzamento, post o elemento per la trasmissione dei messaggi. Tutti gli URL possono essere configurati in ADFS.

  • $rp. SignedSamlRequestsRequired: Se il valore è impostato, la richiesta SAML inviata dalla relying party parte deve essere firmato. I parametri "SigAlg" e "Firma" è necessario che siano presenti nella richiesta.

  • $rp. RequestSigningCertificate: Questo è il certificato di firma utilizzato per generare la firma nella richiesta di SAML. Assicurarsi che il certificato sia valido e chiedere al proprietario dell'applicazione di associare il certificato.

Il problema è stato risolto?

Se$rp.EncryptClaimsRestituisce "Enabled", che si basa la crittografia di terze parti è attivato. ADFS utilizza il certificato di crittografia per crittografare le attestazioni. Eseguire i seguenti controlli:

  • $rp. EncryptionCertificate: Utilizzare questo comando per ottenere il certificato e controllare se è valido.

  • $rp. EncryptionCertificateRevocationCheck: Requisiti di controllo Usa questo comando per verificare se il certificato soddisfa la revoca.

Il problema è stato risolto?

Se sono presenti incongruenze di certificato, verificare che il partner utilizza i nuovi certificati. I certificati sono inclusi nei metadati della federazione pubblicato dal server ADFS.

Nota: I partner di fare riferimento a tutte le risorse organizzazione o account organizzazione partner, rappresentati di ADFS relying party trust di terze parti e attendibilità provider di attestazioni.

I partner possono accedere ai metadati di federazione

Se i partner possono accedere ai metadati di federazione, chiedere al partner di utilizzare i nuovi certificati.

Il partner non può accedere ai metadati di federazione

In questo caso, è necessario inviare manualmente i partner di chiavi pubbliche dei nuovi certificati. A tale scopo, attenersi alla seguente procedura:

  1. Esportare le chiavi pubbliche come file .cert o come file p7b per includere le catene di certificati intero.

  2. Invia le chiavi pubbliche ai partner.

  3. Contattare il partner a utilizzare i nuovi certificati.

Il problema è stato risolto?

  1. Aprire la console di gestione di ADFS.

  2. Destro il componente trust di terze parti e quindi scegliere proprietà.

  3. Nella scheda Avanzate , selezionare l'algoritmo in modo che corrisponda a quanto richiesto dall'applicazione.
    Relying party trust-Hash algorithm

È stato risolto il problema ?

  1. Sul server ADFS, scarica le regole di trasformazione rilascio eseguendo il comando seguente:
    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules

  2. Individuare la regola che invia la richiesta di NameIdentifier. Se non esiste una regola, ignorare questo passaggio.
    Di seguito è riportato un esempio della regola:

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    Si noti il formato NameIdentifier la sintassi seguente:
    Properties["Property-type-URI"] = "ValueURI"

    Di seguito sono elencati i formati possibili. Il primo formato è quello predefinito.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  3. Chiedere al proprietario dell'applicazione per il formato NameIdentifier richiesto dall'applicazione.

  4. Verificare se i due formati NameIdentifier corrispondano.

  5. Se i formati non corrispondono, è possibile configurare la richiesta NameIdentifier per utilizzare il formato richiesto dall'applicazione. A tale scopo, attenersi alla seguente procedura:

    1. Aprire la console di gestione di ADFS.

    2. Fare clic su Attendibilità componente, selezionare il partner di federazione appropriato e quindi fare clic su Modifica criterio di rilascio attestazioni nel riquadro Azioni .

    3. Se nessuna regola per inviare la richiesta di NameIdentifier o aggiornare una regola esistente, aggiungere una nuova regola. Selezionare Nome ID per tipo di attestazione in ingressoe quindi specificare il formato richiesto dall'applicazione.
      Configure claim rule

Il problema è stato risolto?

Nota: È inoltre possibile utilizzare Fiddler per risolvere il problema. L'idea è lo stesso.

L'applicazione Scarica Token è utile quando il debug di problemi con il servizio federativo, nonché la convalida personalizzata richiedere regole. Non è una soluzione ufficiale, ma una buona soluzione Debug indipendente che è consigliabile ai fini della risoluzione dei problemi. Per il Dump Token app, attenersi alla seguente procedura:

  1. Impostare l'applicazione Dump Token eseguendo i comandi seguenti:
    $authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"https://dumptoken.azurewebsites.net/default.aspx"
    $samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
    Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

  2. Replicare la configurazione parte componente guasto da copia le regole di rilascio dalla controparte DumpToken. A tale scopo, eseguire il comando seguente:
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules

  3. Richiedere all'utente di aprire uno dei collegamenti riportati di seguito in base ai criteri di autenticazione che è impostata.

    • WS-Fed:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML:https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Imporre l'autenticazione a più fattori:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Ottenere le attestazioni per chiedere all'utente di accedere la pagina di autenticazione.

  5. Output in the Dump Token, espandere la sezione XML non elaborato di Token e quindi controllare l'istruzione attributo controllando le seguenti stringhe per vedere se corrispondano a ciò che è configurato nel criterio di rilascio attestazioni :

    • SAML:NameIdentifier: indica il formato NameIdentifier.

    • SAML:AttributeStatement: Mostra ogni coppia tipo/valore di attestazione per il token.

    • SAML:AuthenticationStatement: indica il metodo di autenticazione e l'autenticazione immediata.

Il problema è stato risolto?

Utilizzare la pagina IdpInititatedSignOn per verificare se il servizio ADFS sia in esecuzione e la funzionalità di autenticazione funzioni correttamente. Per aprire la pagina IdpInitiatedSignOn, attenersi alla seguente procedura:

  1. Abilitare la pagina IdpInitiatedSignOn eseguendo il comando seguente sul server ADFS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. Da un computer che si trova all'interno della rete, visitare la seguente pagina:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. Immettere le credenziali corrette di un utente valido nella pagina di accesso.

È il segno-in ha esito positivo?

Per risolvere il problema, controllare i seguenti componenti e servizi.

Accesso AD FS deve fare riferimento direttamente a uno dei server ADFS o il bilanciamento del carico davanti al server ADFS. Eseguire i seguenti controlli:

  • Il ping del nome servizio federativo (ad esempio fs.contoso.com). Verificare se l'indirizzo IP che risolve in uno dei server ADFS o sistema di bilanciamento del carico dei server ADFS.

  • Controllare se vi è un record per il servizio federativo nel server DNS. Il record deve puntare a uno dei server ADFS o per il bilanciamento del carico dei server ADFS.

Il problema è stato risolto?

  • Controlla se firewall sta bloccando il traffico tra:

    • Il server ADFS e il bilanciamento del carico.

    • La WAP (Web Proxy di applicazione) server e il bilanciamento del carico, se viene utilizzato WAP.

  • Se sonda è stato attivato il servizio di bilanciamento del carico, verificare quanto segue:

    • Se si esegue Windows Server 2012 R2, assicurarsi che il Agosto 2014 aggiornamento cumulativo è installato.

    • Controllare se la porta 80 è attivata il firewall sul server ADFS e server WAP.

    • Che tale sonda sia impostata per la porta 80 e per l'endpoint/adfs/probe.

Il problema è stato risolto?

  1. Sul server ADFS, aprire Server Manager.

  2. In Server Manager, fare clic su Strumenti > servizi.

  3. Controllare lo stato di Active Directory Federation Services sia in esecuzione.

Il problema è stato risolto?

ADFS offre vari endpoint per scenari e funzionalità diverse. Non tutti gli endpoint sono attivati per impostazione predefinita. Per controllare lo stato dell'endpoint, attenendosi alla procedura seguente:

  1. Sul server ADFS, aprire la Console di gestione AD FS.

  2. Espandere servizi > endpoint.

  3. Individuare i punti finali e verificare se gli Stati sono attivati nella colonna attivato .
    ADFS Endpoints status

Il problema è stato risolto?

Si consiglia di utilizzare Azure Connect di Active Directory che semplifica la gestione dei certificati SSL.

Connetti AD Azure sono installato nel proprio ambiente?

Verificare se è installato Azure Connect di Active Directory, che è utilizzato per gestire e aggiornare i certificati SSL.

Il problema è stato risolto?

Il certificato SSL deve soddisfare i seguenti requisiti:

  • Il certificato proviene da un'autorità di certificazione principale attendibile.
    ADFS è necessario che i certificati SSL da un'autorità di certificazione principale attendibile. Se dal computer collegati tramite join non di dominio di ADFS, si consiglia di utilizzare un certificato SSL da un'autorità di certificazione radice attendibili di terze parti come DigiCert, VeriSign e così via. Se il certificato SSL non è un'autorità di certificazione principale attendibile, è possono interrompere le comunicazioni SSL.

  • Il nome del soggetto del certificato è valido.
    Il nome del soggetto deve corrispondere al nome del servizio federativo, non il nome del server ADFS o un altro nome. Per ottenere il nome del servizio federativo, eseguire il comando seguente sul server ADFS primario:
    Get-AdfsProperties | select hostname

  • Il certificato non sia stato revocato.
    Verificare la revoca dei certificati. Se il certificato viene revocato, la connessione SSL non può essere attendibile e verrà bloccata dai client.

Il certificato SSL soddisfa questi requisiti?

Per risolvere il problema, ottenere un certificato completo per le comunicazioni SSL.

Il problema è risolto dopo aver utilizzato un certificato SSL completo?

Selezionare le seguenti configurazioni del certificato SSL.

Il certificato SSL deve essere installato nell'archivio personale del computer locale in ogni server federativo della farm. Per installare il certificato, fare doppio clic su di. File PFX del certificato e seguire la procedura guidata.

Per verificare se il certificato viene installato nella posizione corretta, attenersi alla seguente procedura:

  1. Elenca i certificati presenti nell'archivio personale del computer locale utilizzando il comando seguente:
    dir Cert:\LocalMachine\My

  2. Verifica se il certificato nell'elenco.

Il problema è stato risolto?

Ottenere l'identificazione personale del certificato utilizzato per le comunicazioni SSL e verificare se l'identificazione personale corrisponde l'identificazione personale del certificato previsto.

Per ottenere l'identificazione personale del certificato in uso, eseguire il comando seguente in Windows PowerShell:

Get-AdfsSslCertificate

Se viene utilizzato il certificato corretto, è possibile impostare il certificato corretto eseguendo il comando seguente:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Il problema è stato risolto?

Il certificato SSL deve essere impostato come il certificato di comunicazione del servizio nella farm di ADFS. Ciò non avviene automaticamente. Per controllare se è impostato il certificato corretto, procedere come segue:

  1. Nella Console di gestione AD FS, espandere servizi > certificati.

  2. Verificare se il certificato in comunicazioni di servizio il certificato previsto.

Se è presente il certificato corretto, impostare il certificato corretto e quindi concedere che l'autorizzazione di lettura per il certificato di servizio di ADFS. A tale scopo, attenersi alla seguente procedura:

  1. Impostare il certificato corretto:

    1. Destro certificatie quindi fare clic su Imposta certificato di comunicazione del servizio.

    2. Selezionare il certificato corretto.

  2. Verificare se il servizio ADFS dispone dell'autorizzazione di lettura per il certificato:

    1. Aggiungere lo snap-in certificati per l'account del computer locale in Microsoft Management Console (MMC).

    2. Espandere certificati (Computer locale) > personali > certificati.

    3. Il pulsante destro del certificato SSL, fare clic su Tutte le attività > Gestisci chiavi Private.

    4. Verificare se adfssrv è elencato in nomi di gruppo e utente con autorizzazione di lettura .

  3. Se adfssrv non è elencato, concedere che l'autorizzazione di lettura per il certificato di servizio di ADFS:

    1. Fare clic su Aggiungi, fare clic su percorsi, fare clic sul server e quindi fare clic su OK.

    2. Nella casella Immettere i nomi degli oggetti da selezionare, immettere service\adfssrv nt, fare clic su Controlla nomie quindi fare clic su OK.
      Se si utilizza AD FS con dispositivo di registrazione del servizio (DRS), immettere service\drs nt .

    3. Concedere l'autorizzazione di lettura e quindi fare clic su OK.

Il problema è stato risolto?

In ADFS è stato configurato DRS?

Se è stata configurata ADFS con DRS, assicurarsi che il certificato SSL sia configurato correttamente anche per RDS. Ad esempio, se sono presenti due contoso.com di suffissi UPN e fabrikam.com, il certificato deve avere enterpriseregistration.contoso.com ed enterpriseregistration.fabrikma.com come nome alternativo soggetto (SAN).

Per verificare se il certificato SSL è il SANs corretto, procedere come segue:

  1. Elencare tutti i suffissi UPN utilizzati nell'organizzazione eseguendo il comando seguente:
    Get-AdfsDeviceRegistratrionUpnSuffix

  2. Verificare se è richiesto il certificato SSL SANs configurato.

Il certificato SSL dispone i nomi corretti di DRS come SANs?

Per risolvere questo problema, ottenere un nuovo certificato SSL con il corretta SAN per DRS e quindi utilizzarlo come il certificato SSL per ADFS.

Il problema è stato risolto?

Controllare se il certificato SSL corretto è impostato su tutti i server WAP

  1. Assicurarsi che il certificato SSL installato nell'archivio personale del computer locale su ciascun server WAP.

  2. Ottenere il certificato SSL utilizzato da WAP eseguendo il comando seguente:
    Get-WebApplicationProxySslCertificate

  3. Se il certificato SSL non è corretto, è possibile impostare il certificato SSL corretto eseguendo il comando seguente:
    Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint

Controllare i binding del certificato e aggiornarli, se necessario

Per supportare i casi di non-SNI, gli amministratori possono specificare le associazioni di fallback. Federationservicename:443 di standard di associazione, cercare associazioni fallback sotto i seguenti ID applicazione:

  • {5d89a20c-beab-4389-9447-324788eb944a}
    Questo è l'ID applicazione per ADFS.

  • {f955c070-e044-456c-ac00-e9e4275b3f04}
    Si tratta dell'ID di applicazione per il Proxy di applicazione Web.

Ad esempio, se il certificato SSL è stato specificato per un'associazione di fallback come 0.0.0.0:443, assicurarsi che l'associazione viene aggiornato di conseguenza quando viene aggiornato il certificato SSL.

Il problema è stato risolto?

  1. Sul server ADFS, aprire Server Manager.

  2. In Server Manager, fare clic su Strumenti > servizi.

  3. Controllare lo stato di Active Directory Federation Services sia in esecuzione.

Il problema è stato risolto?

Utilizzare la pagina di IdpInititatedSignOn per verificare rapidamente se il servizio ADFS è verso l'alto e in esecuzione e la funzionalità di autenticazione funzioni correttamente. Per aprire la pagina IdpInitiatedSignOn, attenersi alla seguente procedura:

  1. Abilitare la pagina IdpInitiatedSignOn eseguendo il comando seguente sul server ADFS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. Da un computer che si trova all'esterno della rete, visitare la seguente pagina:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. Immettere le credenziali corrette di un utente valido nella pagina di accesso.

È il segno-in ha esito positivo?

Per risolvere il problema, controllare i seguenti componenti e servizi.

Accesso AD FS deve fare riferimento direttamente a uno dei server WAP (Web Proxy di applicazione) o il bilanciamento del carico che precede il server WAP. Eseguire i seguenti controlli:

  • Il ping del nome servizio federativo (ad esempio fs.contoso.com). Verificare se l'indirizzo IP che viene risolto il Ping è uno dei server WAP o del sistema di bilanciamento del carico dei server WAP.

  • Controllare se vi è un record per il servizio federativo nel server DNS. Il record deve puntare a uno dei server WAP o per il bilanciamento del carico dei server WAP.

Se non è implementato WAP nello scenario per l'accesso esterno, verificare se unccessing AD FS fa direttamente riferimento a uno dei server ADFS o il bilanciamento del carico davanti al server ADFS:

  • Il ping del nome servizio federativo (ad esempio fs.contoso.com). Verificare se l'indirizzo IP che risolve in uno dei server ADFS o sistema di bilanciamento del carico dei server ADFS.

  • Controllare se vi è un record per il servizio federativo nel server DNS. Il record deve puntare a uno dei server ADFS o per il bilanciamento del carico dei server ADFS.

Il problema è stato risolto?

  • Controlla se firewall sta bloccando il traffico tra:

    • Il server ADFS e il bilanciamento del carico.

    • La WAP (Web Proxy di applicazione) server e il bilanciamento del carico, se viene utilizzato WAP.

  • Se sonda è stato attivato il servizio di bilanciamento del carico, verificare quanto segue:

    • Se si esegue Windows Server 2012 R2, assicurarsi che il Agosto 2014 aggiornamento cumulativo è installato.

    • Controllare se la porta 80 è attivata il firewall sul server WAP e server ADFS.

    • Che tale sonda sia impostata per la porta 80 e /adfs/probe l'endpoint.

Il problema è stato risolto?

  1. Verificare se è stato attivato il traffico in ingresso attraverso la porta TCP 443:

    • til firewall tra il server Proxy di applicazione Web e server farm federativa.

    • il firewall tra i client e il server Proxy di applicazione Web.

  2. Controllare se il traffico in ingresso attraverso la porta TCP 49443 è stato attivato il firewall tra i client e il server Proxy di applicazione Web quando sono vere le seguenti condizioni:

    • È abilitata l'autenticazione client TLS con certificati x. 509.

    • Si utilizza AD FS in Windows Server 2012 R2.

      Nota: La configurazione non è necessario sul firewall tra il server Proxy di applicazione Web e i server di federazione.

Il problema è stato risolto?

 

Il problema è stato risolto?

ADFS offre vari endpoint per scenari e funzionalità diverse. Non tutti gli endpoint sono attivati per impostazione predefinita. Per verificare se l'endpoint è stato attivato il proxy, attenendosi alla procedura seguente:

  1. Sul server ADFS, aprire la Console di gestione AD FS.

  2. Espandere servizi > endpoint.

  3. Individuare il punto finale e verificare se lo stato è attivato sulla colonna Proxy attivato .
    ADFS endpoints proxy status

 

Il problema è stato risolto?

Nota: Informazioni su questa pagina si applicano a AD FS 2012 R2 e versioni successive.

Se il Proxy dell'applicazione Web (WAP) è distribuito, è necessario creare la relazione di trust proxy tra il server WAP e il server ADFS. Verificare se la relazione di trust proxy viene stabilita o inizia a non riuscire ad un certo punto nel tempo.

Informazioni generali

La relazione di trust proxy è certificato client basato su. Quando si esegue la procedura guidata dopo l'installazione di Proxy di applicazione Web, viene generato un certificato autofirmato utilizzando le credenziali specificate nella procedura guidata. La procedura guidata quindi inserisce il certificato nel database di configurazione di ADFS e lo aggiunge all'archivio certificati AdfsTrustedDevices sul server ADFS.

Per le comunicazioni SSL, HTTP. sys viene utilizzato il seguente ordine di priorità per le associazioni di certificati SSL per creare una corrispondenza:

Priorità

Nome

Parametri

Descrizione

1

IP

IP:port

Corrispondenza esatta IP e porta

2

SNI

Hostname:port

Corrispondenza esatta hostname (connessione specificare SNI)

3

CCS

Porta

Richiamare l'archivio centrale

4

Carattere jolly IPv6

Porta

Corrispondenza con caratteri jolly IPv6 (connessione deve essere IPv6)

5

IP jolly

Porta

Corrispondenza con caratteri jolly (connessione può essere IPv4 o IPv6)

AD FS 2012 R2 e versioni successive sono indipendenti di Internet Information Services (IIS) e viene eseguito come un servizio basato su HTTP. sys. binding a certificati SSL nomehost: porta vengono utilizzati da ADFS. Durante l'autenticazione dei certificati client, ADFS invia un elenco di certificati attendibili (CTL) basato sui certificati nell'archivio di AdfsTrustedDevices. Se un'associazione di certificati SSL per il server ADFS utilizza creato o l'archivio CTL non AdfsTrustedDevices, non viene stabilita la relazione di trust proxy.

Ottenere il binding a certificati SSL per ADFS

Sul server ADFS, eseguire il comando seguente in Windows PowerShell:
netsh http show sslcert

Nell'elenco di associazioni ha restituito, cercare quelli con l'ID applicazione di 5d89a20c-beab-4389-9447-324788eb944a. Di seguito è riportato un esempio di un'associazione integro. Nota le parti in grassetto.

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Risoluzione dei problemi

Per rilevare automaticamente i problemi con la relazione di trust proxy, eseguire lo script seguente. In base al problema rilevato, intervenire di conseguenza alla fine della pagina.

param

(

  [switch]$syncproxytrustcerts

)

function checkhttpsyscertbindings()

{

Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")

$httpsslcertoutput = netsh http show sslcert

$adfsservicefqdn = (Get-AdfsProperties).HostName

$i = 1

$certbindingissuedetected = $false

While($i -lt $httpsslcertoutput.count)

{

        $ipport = $false

        $hostnameport = $false

        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }

        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }

        # Check for IP specific certificate bindings

        if ( ( $ipport -eq $true ) )

        {

            $httpsslcertoutput[$i]

            $ipbindingparsed = $httpsslcertoutput[$i].split(":")

            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )

            {

                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning

                $certbindingissuedetected = $true

            }

            $i = $i + 14

            continue

        }

        # check that CTL Store is set for ADFS service binding

        elseif ( $hostnameport -eq $true )

        {

            $httpsslcertoutput[$i]

            $ipbindingparsed = $httpsslcertoutput[$i].split(":")

            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )

            {

                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"

                $certbindingissuedetected = $true

            }

        $i = $i + 14

        continue

        }

    $i++

}

If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }

}

function checkadfstrusteddevicesstore()

{

# check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store

Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"

$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}

If ( $certlist.count -gt 0 )

{

    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"

    $certlist | Format-List Subject

}

Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }

}

function checkproxytrustcerts

{

    Param ([bool]$repair=$false)

    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")

    $doc = new-object Xml

    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")

    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString

    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"

    $cli = new-object System.Data.SqlClient.SqlConnection

    $cli.ConnectionString = $connString

    $cmd = new-object System.Data.SqlClient.SqlCommand

    $cmd.CommandText = $command

    $cmd.Connection = $cli

    $cli.Open()

    $configString = $cmd.ExecuteScalar()

    $configXml = new-object XML

    $configXml.LoadXml($configString)

    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2

    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices

    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")

    $store.open("MaxAllowed")

    $atLeastOneMismatch = $false

    $badCerts = @()

    foreach($rawCert in $rawCerts)

    {   

        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')

        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)

        $now = Get-Date

        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))

        {

            $certThumbprint = $cert.Thumbprint

         $certSubject = $cert.Subject

         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue

         if ($ctlMatch -eq $null)

         {

       $atLeastOneMismatch = $true

          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"

       if ($repair -eq $true)

       {

        write-Warning "Attempting to repair"

        $store.Add($cert)

        Write-Warning "Repair successful"

       }

                else

                {

                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")

                }

         }

        }

    }

    $store.Close()

    if ($atLeastOneMismatch -eq $false)

    {

     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")

    }

}

checkhttpsyscertbindings

checkadfstrusteddevicesstore

checkproxytrustcerts($syncproxytrustcerts)

Write-Host; Write-Host("All checks completed.")

Qual è il problema rilevato?

L'associazione creato ha la precedenza più elevata. Se il binding a certificati SSL di FS AD un'associazione di IP: Port, HTTP. sys utilizza sempre il certificato per l'associazione per le comunicazioni SSL. Per risolvere questo problema, utilizzare i metodi seguenti.

Metodo 1: Rimuovere l'associazione creato

Tenere presente che l'associazione creato può essere nuovamente dopo averlo rimosso. Ad esempio, è possibile automaticamente ricreare un'applicazione configurata con questa associazione creato sull'avvio del servizio successivo.

Metodo 2: Utilizzare un altro indirizzo IP per le comunicazioni AD FS SSL

Se l'associazione creato è necessario, risolvere il nome FQDN di servizio ADFS a un altro indirizzo IP non utilizzato in tutte le associazioni. In questo modo, HTTP. sys verrà utilizzata l'associazione nomehost: porta per le comunicazioni SSL.

Metodo 3: Impostare AdfsTrustedDevices come archivio per l'associazione creato CTL

è l'ultima risorsa se non è possibile utilizzare i metodi descritti sopra. Ma è consigliabile comprendere le seguenti condizioni prima di modificare CTL archivio predefinito per AdfsTrustedDevices:

  • Associazione perché il creato è disponibile.

  • Se l'associazione si basa su CTL archivio per l'autenticazione certificato client predefinito.

Il problema è stato risolto?

Se è installato Azure Connect di Active Directory, utilizzare AAD la connessione su cui per impostare il nome di archivio CTL AdfsTrustedDevices per il binding a certificati SSL su tutti i server ADFS. Se Azure Connect di Active Directory non è installato, rigenerare il binding a certificati ADFS eseguendo il seguente comando su tutti i server ADFS.
Set-AdfsSslCertificate -Thumbprint Thumbprint

Il problema è stato risolto?

Se una CA di emissione di certificati nell'archivio certificati in genere esistono solo certificati autofirmati, il CTL generato dall'archivio contiene solo CA di emissione di certificati. L'archivio certificati AdfsTrustedDevices è tale un archivio deve per contenere solo i certificati autofirmati. Questi certificati sono:

  • MS-organizzazione-accesso: Il certificato autofirmato utilizzato per il rilascio di certificati di join sul posto di lavoro.

  • ADFS Proxy attendibile: I certificati per ogni server di Proxy di applicazione Web.

AdfsTrustedDevices certificates

Pertanto, è possibile eliminare qualsiasi certificato emesso dall'archivio certificati AdfsTrustedDevices.

Il problema è stato risolto?

Quando viene stabilita una relazione di trust proxy con un server ADFS, il certificato client è scritto nel database di configurazione di ADFS e aggiunto all'archivio certificati AdfsTrustedDevices sul server ADFS. Per la distribuzione di una farm di ADFS, il certificato client dovrebbe essere sincronizzato con gli altri server ADFS. Se la sincronizzazione non ha luogo per qualche motivo, una relazione di trust proxy funziona solo per il server ADFS che con la relazione di trust è stata stabilita, ma non per gli altri server ADFS.

Per risolvere questo problema, utilizzare uno dei metodi descritti di seguito.

Metodo 1

In tutti i server ADFS, installare l'aggiornamento documentato in 2964735 KB . Dopo aver installato l'aggiornamento, la sincronizzazione del certificato client è previsto che verranno eseguiti automaticamente.

Metodo 2

Eseguire lo script con switch – syncproxytrustcerts sincronizzare manualmente i certificati client dal database di configurazione di ADFS all'archivio certificati AdfsTrustedDevices. Lo script deve essere eseguito su tutti i server ADFS nella farm.

Si noti che non si tratta una soluzione permanente in quanto i certificati client vengono rinnovati regolarmente.

Il problema è stato risolto?

Controllare se vi è corrispondenza ora o fuso orario. Se ma il tempo di zona non corrisponde a tempo, la relazione di trust proxy potrà riuscire a stabilire.

Il problema è stato risolto?

Se la terminazione SSL avviene su una periferica di rete tra server ADFS e il server WAP, la comunicazione tra ADFS e WAP verrà interrotta perché la comunicazione è basata sul certificato client.

Disattivare la terminazione SSL della periferica di rete tra il server ADFS e WAP.

Il problema è stato risolto?

Controllare le impostazioni di autenticazione integrata di Windows nel browser client, le impostazioni di ADFS e parametri di richiesta di autenticazione.

Controllare il browser del client dell'utente

Verificare le seguenti impostazioni in Opzioni Internet:

  • Nella scheda Avanzate , assicurarsi che sia attivata l'impostazione Abilita autenticazione Windows integrata .

  • In seguito protezione > intranet locale > siti > Avanzate, assicurarsi che l'URL di ADFS Active Directory nell'elenco dei siti Web.

  • Seguente protezione > intranet locale > livello personalizzato, assicurarsi che sia selezionata l'impostazione accesso automatico solo nell'area Intranet .

Se si utilizza Safari, Firefox o Chrome, assicurarsi che siano attivate le impostazioni equivalenti in questi browser.

Controllare le impostazioni di ADFS

Controllare l'impostazione di WindowsIntegratedFallback

  1. Aprire Windows PowerShell con l'esecuzione come amministratore.

  2. Ottenere il criterio di autenticazione globali eseguendo il comando seguente:
    Get-ADFSGlobalAuthenticationPolicy

  3. Esaminare il valore dell'attributo WindowsIntegratedFallbackEnbaled.

È previsto Se il valore è True, autenticazione basata su form. Ciò significa che la richiesta di autenticazione proviene da un browser che non supporta l'autenticazione integrata di Windows. Vedere la sezione successiva su come ottenere il browser supportato.

Se il valore è False, autenticazione integrata di Windows deve essere previsto.

Controllare l'impostazione di WIASupportedUsersAgents

  1. Ottenere l'elenco degli agenti utente supportati eseguendo il comando seguente:
    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  2. Esaminare l'elenco delle stringhe agente utente che restituisce il comando.

Verificare se la stringa agente utente del browser è presente nell'elenco. In caso contrario, aggiungere la stringa agente utente mediante la procedura seguente:

  1. Vai a http://useragentstring.com/ che rileva e Mostra la stringa agente utente del browser.

  2. Ottenere l'elenco degli agenti utente supportati eseguendo il comando seguente:
    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  3. Aggiungere la stringa agente utente del browser utilizzando il comando seguente:
    $wiaStrings = $wiaStrings+"NewUAString"
    Esempio:$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

  4. Aggiornare l'impostazione WIASupportedUserAgents eseguendo il comando seguente:
    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Controllare i parametri di richiesta di autenticazione

Verificare se la richiesta di autenticazione specifica l'autenticazione basata su form come metodo di autenticazione

  1. Se la richiesta di autenticazione è un richiesta WS-Federation, verificare se la richiesta include wauth = urn: oasis: nomi: tc: SAML:1.0:am:password.

  2. Se la richiesta di autenticazione è una richiesta SAML, controllare se la richiesta include un samlp:AuthnContextClassRef elemento con valore urn: oasis: nomi: tc: SAML:2.0:ac:classes:Password.

Per ulteriori informazioni, vedere Panoramica dei gestori di autenticazione di ADFS, pagine di accesso.

Verificare se l'applicazione di Microsoft Online Services per Office 365

Se l'applicazione che si desidera accedere non è Microsoft Online Services, si è previsto e controllato da una richiesta di autenticazione in ingresso . Lavorare con il proprietario dell'applicazione per modificare il comportamento.

Se l'applicazione di Microsoft Online Services, si potrebbe essere controllata dal PromptLoginBehavior impostazione di dall'oggetto dell'area di autenticazione attendibile. Questa impostazione Controlla invio richiesta di titolari AD Azure = account di accesso per ADFS. Per impostare il PromptLoginBehavior impostazioneattenersi alla seguente passaggi:

  1. Aprire Windows PowerShell con l'opzione "Esegui come amministratore".

  2. Ottenere l'impostazione di federazione di dominio esistente eseguendo il comando seguente:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  3. Definire l'impostazione PromptLoginBehavior eseguendo il comando seguente:
    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>

    I valori per il parametro PromptLoginBehavior sono:

    1. TranslateToFreshPasswordAuth: AD Azure Invia a ADFS anziché prompt dei comandi wauth e wfresh = accesso. Questo si traduce in un richiesta di autenticazione da utilizzare l'autenticazione basata su form.

    2. NativeSupport: il parametro di accesso = richiesta viene inviato come per ADFS.

    3. Disattivato: non viene inviato AD FS.

Per ulteriori informazioni sul comando Set-MSOLDomainFederationSettings, vedere richiede Active Directory Federation Services = accesso parametro supporto.

Il problema è stato risolto?

Autenticazione a più fattori può essere attivata in un server ADFS, relying party, o specificato nel parametro di richiesta di autenticazione. Verificare le configurazioni per vedere se siano impostate correttamente. Se autenticazione multifattore previsto ma si're chiesto ripetutamente, verificare le regole di emissione parte relying party per verificare se l'autenticazione multifattore attestazioni vengono passate all'applicazione.

Per ulteriori informazioni sull'autenticazione multifattore in ADFS, vedere i seguenti articoli:

Controllare la configurazione del server ADFS e controparte

Per verificare la configurazione del server ADFS, convalidare le regole di autenticazione aggiuntivi globali. Per verificare la configurazione la relying party, convalidare le regole di autenticazione aggiuntivi per il componente trust di terze parti.

  1. Per verificare la configurazione del server ADFS, eseguire il comando seguente in una finestra di Windows PowerShell.
    Get-ADFSAdditionalAuthenticationRule

    Per verificare la configurazione del componente, eseguire il comando seguente:
    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules

    Nota: Se i comandi restituiscono nothing, le regole di autenticazione aggiuntivi non sono configurate. Ignorare questa sezione.

  2. Osservare la regola attestazione impostare configurato.

Verificare se l'autenticazione multifattore è attivata nel set di regole attestazione

Un set di regole attestazione è composto da sezioni che seguono:

  • L'istruzione della condizione:C:[Type=…,Value=…]

  • L'istruzione del problema:=> issue (Type=…,Value=…)

Se l'istruzione problema contiene la seguente richiesta, viene specificato l'autenticazione a più fattori.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Di seguito sono riportati esempi che richiedono l'autenticazione multifattore da utilizzare per i dispositivi collegati non-area di lavoro e per l'accesso extranet:

  • c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

  • c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Controllare le regole di emissione componente di terze parti

Se l'utente riceve ripetutamente richieste di autenticazione multifattore dopo la prima autenticazione viene eseguita, è possibile che la parte replying non passa attraverso le richieste di autenticazione multifattore all'applicazione. Per verificare se le richieste di autenticazione vengono passate, procedere come segue:

  1. In Windows PowerShell, eseguire il comando seguente:
    Get-ADFSRelyingPartyTrust -TargetName ClaimApp

  2. Osservare la regola impostata definito negli attributi IssuanceAuthorizationRules o IssuanceAuthorizationRulesFile.

Il set di regole deve includere la seguente regola di emissione di passare attraverso le richieste di autenticazione a più fattori:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

Controllare il parametro di richiesta di autenticazione

Verificare se la richiesta di autenticazione specifica l'autenticazione a più fattori come il metodo di autenticazione

  • Se la richiesta di autenticazione è un richiesta WS-Federation, verificare se la richiesta include wauth = http://schemas.microsoft.com/claims/multipleauthn.

  • Se la richiesta di autenticazione è una richiesta SAML, controllare se la richiesta include un samlp:AuthnContextClassRef elemento con valore http://schemas.microsoft.com/claims/multipleauthn.

Per ulteriori informazioni, vedere Panoramica dei gestori di autenticazione di ADFS, pagine di accesso.

Verificare se l'applicazione di Microsoft Online Services per Office 365

Se l'applicazione che si desidera accedere a Microsoft Online Services per Office 365, controllare l'impostazione di federazione di dominio SupportsMFA.

  1. Ottenere l'impostazione corrente della federazione di dominio di SupportsMFA eseguendo il comando seguente:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  2. Se l'impostazione SupportsMFA è FALSE, è necessario impostarla su TRUE eseguendo il comando seguente:
    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE

Il problema è stato risolto?

Disattivare la funzionalità di accesso = richiesta eseguendo il comando seguente:
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Dopo aver eseguito questo comando, le applicazioni di Office 365 non includono il parametro di accesso = richiesta in ogni richiesta di autenticazione.

Il problema è stato risolto?

Modificare il parametro di richiesta per utilizzare il metodo di autenticazione previsto.

Il problema è stato risolto?

SSO è disattivata, attivarla.

Il problema è stato risolto?

Congratulazioni! È stato risolto il problema SSO.

Siamo spiacenti che il problema persiste. Ci piacerebbe se si compila il questionario con i dettagli del problema.

Scopo di questa Guida

Risolve servizio single sign-on (SSO) problemi con Active Directory Federation Services (ADFS).

Che è per?

Gli amministratori che guida diagnosticare problemi SSO per i propri utenti.

Come funziona?

Inizieremo mediante la richiesta del problema che siano rivolte agli utenti. Quindi potrà passare attraverso una serie di operazioni specifiche per la propria situazione.

Tempo stimato di completamento:

30-45 minuti.

Serve aiuto?

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa a Microsoft Insider

Queste informazioni sono risultate utili?

Come valuti la qualità della lingua?
Cosa ha influito sulla tua esperienza?

Grazie per il feedback!

×