Risolvere i problemi relativi all'accesso Single Sign-On con Active Directory Federation Services (AD FS)

Questo articolo illustra come risolvere i problemi di Single Sign-On (SSO) con Active Directory Federation Services (AD FS).

Selezionare una delle sezioni seguenti in base al tipo di problema riscontrato.

Si applica a: Active Directory Federation Services
Numero KB originale: 4034932

Richiesta di autenticazione basata su form o NTLM

Durante la risoluzione dei problemi relativi all'accesso Single Sign-On (SSO) con Active Directory Federation Services (AD FS), se gli utenti ricevono richieste di autenticazione NTLM o basate su moduli impreviste, seguire la procedura descritta in questo articolo per risolvere questo problema.

Controllare le impostazioni di autenticazione integrata di Windows

Per risolvere questo problema, controllare le impostazioni di autenticazione integrata di Windows nel browser client, le impostazioni di AD FS e i parametri della richiesta di autenticazione.

Controllare il browser client dell'utente

Controllare le impostazioni seguenti in Opzioni Internet:

• Nella scheda Avanzate verificare che l'impostazione Abilita autenticazione integrata di Windows sia abilitata.
• Dopo Security Local Intranet Sites Advanced (Siti>Intranet locali>di sicurezza>avanzati), assicurarsi che l'URL di AD FS sia incluso nell'elenco dei siti Web.
• Dopo il livello Sicurezza > locale Intranet > personalizzata, assicurarsi che sia selezionata l'impostazione Accesso automatico solo nell'area Intranet.

Se usi Firefox, Chrome o Safari, assicurati che le impostazioni equivalenti in questi browser siano abilitate.

Controllare le impostazioni di AD FS

Controllare l'impostazione WindowsIntegratedFallback

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

2. Ottenere i criteri di autenticazione globali eseguendo il comando seguente:

   Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
   

3. Esaminare il valore dell'attributo WindowsIntegratedFallbackEnabled .

Se il valore è True, è prevista l'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, è necessario che sia prevista l'autenticazione integrata di Windows.

Controllare l'impostazione WIASupportedUsersAgents

1. Ottenere l'elenco degli agenti utente supportati eseguendo il comando seguente:

   Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

2. Esaminare l'elenco di stringhe dell'agente utente restituite dal comando.

Verificare se la stringa dell'agente utente del browser si trova nell'elenco. In caso contrario, aggiungere la stringa dell'agente utente seguendo questa procedura:

1. Passare a http://useragentstring.com/ che rileva e mostra la stringa dell'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 dell'agente utente del browser eseguendo 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 della richiesta di autenticazione

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

1. Se la richiesta di autenticazione è una richiesta WS-Federation, verificare se la richiesta include wauth= urn:oasis:names:tc:SAML:1.0:am:password.
2. Se la richiesta di autenticazione è una richiesta SAML, verificare se la richiesta include un elemento samlp:AuthnContextClassRef con valore urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Per altre informazioni, vedere Panoramica dei gestori di autenticazione delle pagine di accesso di AD FS.

Controllare se l'applicazione è Microsoft Online Services per Office 365

Se l'applicazione a cui si vuole accedere non è Microsoft Online Services, l'esperienza è prevista e controllata dalla richiesta di autenticazione in ingresso. Collaborare con il proprietario dell'applicazione per modificare il comportamento.

Note

I moduli Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per maggiori informazioni, leggere l'aggiornamento sulla deprecazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza alla migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, consultare le Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero subire interruzioni dopo il 30 giugno 2024.

Se l'applicazione è Microsoft Online Services, l'esperienza utente può essere controllata dall'impostazione PromptLoginBehavior dall'oggetto dell'area di autenticazione attendibile. Questa impostazione controlla se i tenant di Microsoft Entra inviano prompt=login ad AD FS. Per impostare l'impostazione PromptLoginBehavior , seguire questa procedura:

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

2. Ottenere l'impostazione di federazione del dominio esistente eseguendo il comando seguente:

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

3. Impostare 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: Microsoft Entra ID invia wauth e wfresh ad AD FS invece di prompt=login. Ciò porta a una richiesta di autenticazione per l'uso dell'autenticazione basata su form.
   2. NativeSupport: il parametro prompt=login viene inviato così come è ad AD FS.
   3. Disabilitato: non viene inviato nulla ad AD FS.

Per altre informazioni sul comando Set-MSOLDomainFederationSettings, vedere Supporto dei parametri di accesso di Active Directory Federation Services.

Scenario di Microsoft Entra

Se la richiesta di autenticazione inviata a Microsoft Entra ID include il parametro prompt=login, disabilitare la funzionalità prompt=login eseguendo il comando seguente:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

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

Scenario non Microsoft Entra

I parametri di richiesta, ad esempio WAUTH e RequestedAuthNContext nelle richieste di autenticazione, possono avere metodi di autenticazione specificati. Controllare se altri parametri di richiesta applicano il prompt di autenticazione imprevisto. In tal caso, modificare il parametro della richiesta per usare il metodo di autenticazione previsto.

Controllare se l'accesso Single Sign-On è disabilitato

Se SSO è disabilitato, abilitarlo e verificare se il problema è stato risolto.

Richiesta di autenticazione a più fattori

Per risolvere questo problema, verificare se le regole attestazioni nella relying party sono impostate correttamente per l'autenticazione a più fattori.

L'autenticazione a più fattori può essere abilitata in un server AD FS, in una relying party o specificata in un parametro di richiesta di autenticazione. Controllare le configurazioni per verificare se sono impostate correttamente. Se è prevista l'autenticazione a più fattori, ma viene richiesta ripetutamente, controllare le regole di rilascio della relying party per verificare se le attestazioni di autenticazione a più fattori vengono passate all'applicazione.

Per altre informazioni sull'autenticazione a più fattori in AD FS, vedere gli articoli seguenti:

• Presentazione di Multi-Factor Authentication in ADFS - Parte 1: Criteri
• Presentazione di Multi-Factor Authentication in ADFS - Parte 2: Relying Party con riconoscimento MFA

Controllare la configurazione nel server AD FS e nella relying party

Per controllare la configurazione nel server AD FS, convalidare le regole di autenticazione aggiuntive globali. Per controllare la configurazione nella relying party, convalidare le regole di autenticazione aggiuntive per l'attendibilità della relying party.

1. Per controllare la configurazione nel server AD FS, eseguire il comando seguente in una finestra di Windows PowerShell.

   Get-ADFSAdditionalAuthenticationRule
   

   Per controllare la configurazione nella relying party, eseguire il comando seguente:

   Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
   

   Note

   Se i comandi non restituiscono nulla, le regole di autenticazione aggiuntive non vengono configurate. Ignorare questa sezione.

2. Osservare il set di regole attestazioni configurato.

Verificare se l'autenticazione a più fattori è abilitata nel set di regole attestazioni

Un set di regole attestazioni è costituito dalle sezioni seguenti:

• Istruzione condition: C:[Type=``…,Value=…]
• Istruzione issue: => issue (Type=``…,Value=…)

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

Ecco alcuni esempi che richiedono l'autenticazione a più fattori da usare rispettivamente per i dispositivi aggiunti all'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 rilascio della relying party

Se l'utente riceve ripetutamente richieste di autenticazione a più fattori dopo aver eseguito la prima autenticazione, è possibile che la parte di risposta non passi le attestazioni di autenticazione a più fattori all'applicazione. Per verificare se le attestazioni di autenticazione vengono passate, seguire questa procedura:

1. Eseguire il comando seguente in Windows PowerShell:

   Get-ADFSRelyingPartyTrust -TargetName ClaimApp
   

2. Osservare il set di regole definito negli attributi IssuanceAuthorizationRules o IssuanceAuthorizationRulesFile.

Il set di regole deve includere la regola di rilascio seguente per passare le attestazioni 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 della richiesta di autenticazione

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

• Se la richiesta di autenticazione è una richiesta WS-Federation, verificare se la richiesta include wauth= http://schemas.microsoft.com/claims/multipleauthn.
• Se la richiesta di autenticazione è una richiesta SAML, verificare se la richiesta include un elemento samlp:AuthnContextClassRef con valore http://schemas.microsoft.com/claims/multipleauthn.

Per altre informazioni, vedere Panoramica dei gestori di autenticazione delle pagine di accesso di AD FS.

Controllare se l'applicazione è Microsoft Online Services per Office 365

Se l'applicazione a cui si vuole accedere è Microsoft Online Services per Office 365, controllare l'impostazione di federazione del dominio SupportsMFA.

1. Ottenere l'impostazione corrente di federazione del dominio SupportsMFA eseguendo il comando seguente:

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

2. Se l'impostazione SupportsMFA è FALSE, impostarla su TRUE eseguendo il comando seguente:

   Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
   

Controllare se l'accesso Single Sign-On è disabilitato

Se SSO è disabilitato, abilitarlo e verificare se il problema è stato risolto.

Gli utenti non possono accedere al sito o al servizio di destinazione

Questo problema può verificarsi nella pagina di accesso di AD FS o sul lato applicazione.

Se il problema si verifica nella pagina di accesso di AD FS, viene visualizzato un messaggio di errore "Si è verificato un errore", "Servizio HTTP 503 non disponibile" o un altro messaggio di errore. L'URL della pagina di errore mostra il nome del servizio AD FS, fs.contoso.comad esempio .

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

Seguire la procedura descritta nella sezione seguente in base alla posizione in cui si verifica questo problema.

Questo problema si verifica nella pagina di accesso di AD FS

Per risolvere questo problema, verificare se tutti gli utenti sono interessati dal problema e se gli utenti possono accedere a tutte le relying party.

Tutti gli utenti sono interessati dal problema e l'utente non può accedere ad alcuna relying party

Controllare la funzionalità di accesso interna usando IdpInitiatedSignOn. A tale scopo, usare la pagina IdpInititatedSignOn per verificare se il servizio AD FS è attivo e in esecuzione e la funzionalità di autenticazione funziona correttamente. Per aprire la pagina IdpInitiatedSignOn, seguire questa procedura:

1. Abilitare la pagina IdpInitiatedSignOn eseguendo il comando seguente nel server AD FS:

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

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

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

L'accesso ha esito positivo

Se l'accesso ha esito positivo, verificare se lo stato del servizio AD FS è in esecuzione.

1. Nel server AD FS aprire Server Manager.
2. In Server Manager fare clic su Servizi strumenti>.
3. Controllare se lo stato di Active Directory Federation Services è in esecuzione.

Controllare quindi la funzionalità di accesso esterno usando IdpInitiatedSignOn. Usare la pagina IdpInititatedSignOn per verificare rapidamente se il servizio AD FS è attivo e in esecuzione e la funzionalità di autenticazione funziona correttamente. Per aprire la pagina IdpInitiatedSignOn, seguire questa procedura:

1. Abilitare la pagina IdpInitiatedSignOn eseguendo il comando seguente nel server AD FS:

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. Da un computer esterno alla rete visitare la pagina seguente:
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

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

Se l'accesso non riesce, vedere Controllare i componenti e i servizi correlati ad AD FS e Controllare la relazione di trust proxy.

Se l'accesso ha esito positivo, continuare la risoluzione dei problemi con i passaggi descritti in Tutti gli utenti sono interessati dal problema e l'utente può accedere ad alcune relying party.

L'accesso non è riuscito

Se l'accesso non riesce, controllare i componenti e i servizi correlati ad AD FS.

Controllare se lo stato del servizio AD FS è in esecuzione.

1. Nel server AD FS aprire Server Manager.
2. In Server Manager fare clic su Servizi strumenti>.
3. Controllare se lo stato di Active Directory Federation Services è in esecuzione.

Controllare se gli endpoint sono abilitati. AD FS offre diversi endpoint per diverse funzionalità e scenari. Non tutti gli endpoint sono abilitati per impostazione predefinita. Per controllare lo stato degli endpoint, seguire questa procedura:

1. Nel server AD FS aprire la Console di gestione di AD FS.

2. Espandere Endpoint servizio>.

3. Individuare gli endpoint e verificare se gli stati sono abilitati nella colonna Abilitato .

   

Controllare quindi se è installato Microsoft Entra Connect. È consigliabile usare Microsoft Entra Connect per semplificare la gestione dei certificati SSL.

Se Microsoft Entra Connect è installato, assicurarsi di usarlo per gestire e aggiornare i certificati SSL.

Se Microsoft Entra Connect non è installato, verificare se il certificato SSL soddisfa i requisiti di AD FS seguenti:

• Il certificato proviene da un'autorità di certificazione radice attendibile.

  AD FS richiede che i certificati SSL provenano da un'autorità di certificazione radice attendibile. Se AD FS è accessibile da computer non aggiunti a un dominio, è consigliabile usare un certificato SSL da un'autorità di certificazione radice di terze parti attendibile, ad esempio DigiCert, VeriSign e così via. Se il certificato SSL non proviene da un'autorità di certificazione radice attendibile, la comunicazione SSL può interrompersi.

• Il nome soggetto del certificato è valido.

  Il nome del soggetto deve corrispondere al nome del servizio federativo, non al nome del server AD FS o ad un altro nome. Per ottenere il nome del servizio federativo, eseguire il comando seguente nel server AD FS primario:
  Get-AdfsProperties | select hostname

• Il certificato non viene revocato.

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

Se il certificato SSL non soddisfa questi requisiti, provare a ottenere un certificato completo per la comunicazione SSL. È consigliabile usare Microsoft Entra Connect per semplificare la gestione dei certificati SSL. Vedere Aggiornare il certificato TLS/SSL per una farm di Active Directory Federation Services (AD FS).

Se il certificato SSL soddisfa questi requisiti, controllare le configurazioni seguenti del certificato SSL.

Controllare se il certificato SSL è installato correttamente

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

Per verificare se il certificato è installato nella posizione corretta, seguire questa procedura:

1. Elencare i certificati presenti nell'archivio personale per il computer locale eseguendo il comando seguente:
   dir Cert:\LocalMachine\My
2. Controllare se il certificato è presente nell'elenco.

Controllare se il certificato SSL corretto è in uso

Ottenere l'identificazione personale del certificato in uso per la comunicazione SSL e verificare se l'identificazione personale corrisponde all'identificazione personale prevista del certificato.

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

Get-AdfsSslCertificate

Se viene usato il certificato errato, impostare il certificato corretto eseguendo il comando seguente:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Controllare se il certificato SSL è impostato come certificato di comunicazione del servizio

Il certificato SSL deve essere impostato come certificato di comunicazione del servizio nella farm AD FS. Questo non avviene automaticamente. Per verificare se il certificato corretto è impostato, seguire questa procedura:

1. Nella Console di gestione di AD FS espandere Certificati del servizio>.
2. Verificare se il certificato elencato in Comunicazioni del servizio è il certificato previsto.

Se il certificato errato è elencato, impostare il certificato corretto e quindi concedere al servizio AD FS l'autorizzazione Lettura al certificato. A tale scopo, effettuare i passaggi seguenti:

1. Impostare il certificato corretto:

   1. Fare clic con il pulsante destro del mouse su Certificati, quindi scegliere Imposta certificato di comunicazione del servizio.
   2. Selezionare il certificato corretto.

2. Verificare se il servizio AD FS dispone dell'autorizzazione Lettura per il certificato:

   1. Aggiungere lo snap-in Certificati per l'account computer locale a Microsoft Management Console (MMC).
   2. Espandi Certificati (computer locale)>Personale>Certificati.
   3. Fare clic con il pulsante destro del mouse sul certificato SSL, scegliere Tutte le attività>Gestisci chiavi private.
   4. Verificare se adfssrv è elencato in Gruppi e nomi utente con l'autorizzazione Lettura .

3. Se adfssrv non è elencato, concedere al servizio AD FS l'autorizzazione Lettura per il certificato:

   1. Fare clic su Aggiungi, su Percorsi, sul server e quindi su OK.
   2. In Immettere i nomi degli oggetti da selezionare immettere nt service\adfssrv, fare clic su Controlla nomi e quindi fare clic su OK.
      Se si usa AD FS con il servizio Registrazione dispositivi (DRS), immettere invece nt service\drs .
   3. Concedere l'autorizzazione Lettura e quindi fare clic su OK.

Controllare se il servizio Registrazione dispositivi (DRS) è configurato in AD FS

Se AD FS è stato configurato con DRS, assicurarsi che anche il certificato SSL sia configurato correttamente per Servizi Desktop remoto. Ad esempio, se sono presenti due suffissi UPN e fabrikam.com, il certificato deve avere enterpriseregistration.contoso.com e enterpriseregistration.fabrikma.com come nomi alternativi contoso.com del soggetto (SAN).

Per verificare se il certificato SSL ha le san san corrette, seguire questa procedura:

1. Elencare tutti i suffissi UPN usati nell'organizzazione eseguendo il comando seguente:

   Get-AdfsDeviceRegistratrionUpnSuffix
   

2. Verificare se il certificato SSL dispone dei nomi di sicurezza necessari configurati.

3. Se il certificato SSL non dispone dei nomi DRS corretti come SAN, ottenere un nuovo certificato SSL con le san di sicurezza corrette per DRS e usarlo come certificato SSL per AD FS.

Controllare quindi la configurazione del certificato nei server WAP e le associazioni di fallback:

• Controllare se il certificato SSL corretto è impostato in tutti i server WAP.

  1. Assicurarsi che il certificato SSL sia installato nell'archivio personale per il computer locale in ogni server WAP.

  2. Ottenere il certificato SSL usato da WAP eseguendo il comando seguente:

     Get-WebApplicationProxySslCertificate
     

  3. Se il certificato SSL non è corretto, impostare il certificato SSL corretto eseguendo il comando seguente:

     Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
     

• Controllare le associazioni di certificati e aggiornarle, se necessario.

  Per supportare i casi non SNI, gli amministratori possono specificare associazioni di fallback. Oltre all'associazione federationservicename:443 standard, cercare associazioni di fallback con gli ID applicazione seguenti:

  • {5d89a20c-beab-4389-9447-324788eb944a}: ID applicazione per AD FS.
  • {f955c070-e044-456c-ac00-e9e4275b3f04}: ID applicazione per proxy applicazione Web.

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

Tutti gli utenti sono interessati dal problema e l'utente può accedere ad alcune delle relying party

Prima di tutto, ottenere le informazioni sul componente e sul client OAuth. Se si usa una relying party convenzionale, seguire questa procedura:

1. Nel server AD FS primario aprire Windows PowerShell con l'opzione Esegui come amministratore .

2. Aggiungere il componente AD FS 2.0 a Windows PowerShell eseguendo il comando seguente:

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Ottenere le informazioni sulla relying party 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 usa la funzionalità Gruppo di applicazioni in Windows Server 2016, seguire questa procedura:

1. Nel server AD FS primario aprire Windows PowerShell con l'opzione Esegui come amministratore .

2. Ottenere le informazioni sulla relying party 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, ottenere le informazioni sul client eseguendo il comando seguente:

   $client = Get-AdfsServerApplication ClientName
   

Continuare ora con i metodi di risoluzione dei problemi seguenti.

Controllare le impostazioni della relying party e del client

L'identificatore della relying party, l'ID client e l'URI di reindirizzamento devono essere forniti dal proprietario dell'applicazione e dal client. Tuttavia, potrebbe verificarsi una mancata corrispondenza tra ciò che il proprietario fornisce e gli elementi configurati in AD FS. Ad esempio, una mancata corrispondenza potrebbe essere causata da un errore di digitazioni. Controllare se le impostazioni fornite dal proprietario corrispondono a quelle configurate in AD FS. I passaggi della pagina precedente consentono di configurare le impostazioni in AD FS tramite PowerShell.

Impostazioni fornite dal proprietario	Impostazioni configurate in AD FS
Relying party ID	$rp. Identificatore
URI di reindirizzamento della relying party	Corrispondenza con prefisso o carattere jolly di $rp. WSFedEndpoint per una relying party WS-Fed $rp. SamlEndpoints per una relying party SAML
ID client	$client. ClientId
URI di reindirizzamento client	Corrispondenza del prefisso di $client. RedirectUri

Se gli elementi della tabella corrispondono, controllare inoltre se queste impostazioni corrispondono a quelle visualizzate nella richiesta di autenticazione inviate ad AD FS e a quelle configurate in AD FS. Provare a riprodurre il problema durante il quale si acquisisce una traccia Fiddler sulla richiesta di autenticazione inviata dall'applicazione ad AD FS. Esaminare i parametri della richiesta per eseguire i controlli seguenti a seconda del tipo di richiesta.

Richieste OAuth

Una richiesta OAuth è simile alla 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 alle impostazioni configurate in AD FS.

Parametri della richiesta	Impostazioni configurate in AD FS
client_id	$client. ClientId
redirect_uri	Corrispondenza del prefisso di @client_RedirectUri

Il parametro "resource" deve rappresentare una relying party valida in AD FS. Ottenere le informazioni sulla relying party eseguendo uno dei comandi seguenti.

• Se si usa una relying party convenzionale, eseguire il comando seguente:
  Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
• Se si usa la funzionalità Gruppo di applicazioni in Windows Server 2016, eseguire il comando seguente:
  Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

Richieste WS-Fed

Una richiesta WS-Fed è simile alla 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

Controllare se i parametri della richiesta corrispondono alle impostazioni configurate in AD FS:

Parametri della richiesta	Impostazioni configurate in AD FS
wtrealm	$rp. Identificatore
wreply	Corrispondenza del prefisso o corrispondenza con caratteri jolly di $rp. WSFedEndpoint

Richieste SAML

Una richiesta SAML è simile alla 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 usando l'opzione "From DeflatedSAML" nella Creazione guidata testo Fiddler. Il valore decodificato è simile 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 controlli seguenti all'interno del valore decodificato:

• Controllare se il nome host nel valore di Destination corrisponde al nome host di AD FS.
• Controllare se il valore di Issuer corrisponde a $rp.Identifier.

Note aggiuntive per SAML:

• $rp. SamlEndpoints: mostra tutti i tipi di endpoint SAML. La risposta da AD FS viene inviata agli URL corrispondenti configurati negli endpoint. Un endpoint SAML può usare associazioni di reindirizzamento, post o artefatto per la trasmissione di messaggi. Tutti questi URL possono essere configurati in AD FS.
• $rp. SignedSamlRequestsRequired: se il valore è impostato, la richiesta SAML inviata dalla relying party deve essere firmata. I parametri "SigAlg" e "Signature" devono essere presenti nella richiesta.
• $rp. RequestSigningCertificate: certificato di firma usato per generare la firma nella richiesta SAML. Assicurarsi che il certificato sia valido e chiedere al proprietario dell'applicazione di corrispondere al certificato.

Controllare il certificato di crittografia

Se $rp.EncryptClaims restituisce Abilitato, la crittografia della relying party è abilitata. AD FS usa il certificato di crittografia per crittografare le attestazioni. Eseguire i controlli seguenti:

• $rp. EncryptionCertificate: usare questo comando per ottenere il certificato e verificare se è valido.
• $rp. EncryptionCertificateRevocationCheck: usare questo comando per verificare se il certificato soddisfa i requisiti del controllo di revoca.

I due metodi precedenti non funzionano

Per continuare la risoluzione dei problemi, vedere Usare l'app Token dump.

Non tutti gli utenti sono interessati dal problema e l'utente non può accedere ad alcuna relying party

In questo scenario, eseguire i controlli seguenti.

Controllare se l'utente è disabilitato

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

Controllare lo stato dell'utente con Windows PowerShell

1. Accedere a uno dei controller di dominio.

2. Apri Windows PowerShell.

3. Controllare lo stato dell'utente eseguendo il comando seguente:

   Get-ADUser -Identity <samaccountname of the user> | Select Enabled
   

   

Controllare lo stato dell'utente nell'interfaccia utente

1. Accedere a uno dei controller di dominio.

2. Aprire la console di gestione Utenti e computer di Active Directory.

3. Fare clic sul nodo Utenti , fare clic con il pulsante destro del mouse sull'utente nel riquadro destro e quindi scegliere Proprietà.

4. Fare clic sulla scheda Account.

5. In Opzioni account verificare se l'account è disabilitato è selezionato.

   

6. Se l'opzione è selezionata, deselezionarla.

Controllare se le proprietà utente sono state aggiornate di recente

Se una proprietà dell'utente viene aggiornata in Active Directory, viene apportata una modifica ai metadati dell'oggetto utente. Controllare l'oggetto metadati utente per vedere quali proprietà sono state aggiornate di recente. Se vengono trovate modifiche, assicurarsi che vengano prelevate dai servizi correlati. Per verificare se sono state apportate modifiche alle proprietà a un utente, seguire questa procedura:

1. Accedere a un controller di dominio.

2. Apri 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 Ora/Data per ogni attributo per qualsiasi indizio di una modifica. Nell'esempio seguente l'attributo userPrincipleName accetta una data più recente rispetto agli altri attributi che rappresenta una modifica ai metadati dell'oggetto utente.

   

Controllare l'attendibilità della foresta se l'utente appartiene a un'altra foresta

In un ambiente AD FS a più foreste è necessario un trust tra foreste bidirezionali tra la foresta in cui viene distribuito AD FS e le altre foreste che utilizzano la distribuzione di AD FS per l'autenticazione. Per verificare se l'attendibilità tra le foreste funziona come previsto, seguire questa procedura:

1. Accedere a un controller di dominio nella foresta in cui viene distribuito AD FS.

2. Aprire la console di gestione Dominio di Active Directory e Trusts.

3. Nella console di gestione fare clic con il pulsante destro del mouse sul dominio contenente l'attendibilità da verificare e quindi scegliere Proprietà.

4. Scegliere la scheda Trust.

5. In Domini considerati attendibili da questo dominio (trust in uscita) o domini che considerano attendibile il dominio (trust in ingresso) fare clic sul trust da verificare e quindi su Proprietà.

6. Fare clic su Convalida.
   Nella finestra di dialogo servizi Dominio di Active Directory selezionare una delle opzioni.

   • Se si seleziona No, è consigliabile ripetere la stessa procedura per il dominio reciproco.

   • Se si seleziona Sì, specificare le credenziali utente amministrative per il dominio reciproco. Non è necessario eseguire la stessa procedura per il dominio reciproco.

     

Se questi passaggi non consentono di risolvere il problema, continuare la risoluzione dei problemi con i passaggi descritti nella sezione Non tutti gli utenti sono interessati dal problema e l'utente può accedere ad alcune delle relying party sezione.

Non tutti gli utenti sono interessati dal problema e l'utente può accedere ad alcune relying party

In questo scenario verificare se questo problema si verifica in uno scenario Microsoft Entra. In tal caso, eseguire questi controlli per risolvere il problema. In caso contrario, vedere Usare l'app Dump Token per risolvere questo problema.

Controllare se l'utente è sincronizzato con Microsoft Entra ID

Se un utente sta tentando di accedere a Microsoft Entra ID, verrà reindirizzato ad AD FS per l'autenticazione per un dominio federato. Uno dei possibili motivi per cui un accesso non riuscito è che l'utente non è ancora sincronizzato con Microsoft Entra ID. È possibile che venga visualizzato un ciclo da Microsoft Entra ID ad Active Directory FS dopo il primo tentativo di autenticazione ad AD FS. Per determinare se l'utente è sincronizzato con Microsoft Entra ID, seguire questa procedura:

1. Scaricare e installare il modulo Azure AD PowerShell per Windows PowerShell.
2. Aprire Windows PowerShell con l'opzione "Esegui come amministratore".
3. Avviare una connessione a Microsoft Entra ID eseguendo il comando seguente:
   Connect-MsolService
4. Specificare le credenziali di amministratore globale per la connessione.
5. Ottenere l'elenco degli utenti nell'ID Microsoft Entra eseguendo il comando seguente:
   Get-MsolUser
6. Verificare se l'utente si trova nell'elenco.

Se l'utente non è presente nell'elenco, sincronizzare l'utente con Microsoft Entra ID.

Controllare immutableID e UPN nella regola attestazione di rilascio

Microsoft Entra ID richiede immutableID e l'UPN dell'utente per autenticare l'utente.

Note

immutableID è detto anche sourceAnchor negli strumenti seguenti:

• Azure AD Sync
• Sincronizzazione di Azure Active Directory (DirSync)

Gli amministratori possono usare Microsoft Entra Connect per la gestione automatica dell'attendibilità di AD FS con Microsoft Entra ID. Se non si gestisce l'attendibilità tramite Microsoft Entra Connect, è consigliabile scaricarla scaricando Microsoft Entra Connect Microsoft Entra Connect abilita la gestione automatica delle regole attestazioni in base alle impostazioni di sincronizzazione.

Per verificare se le regole attestazioni per immutableID e UPN in AD FS corrispondono a quanto usato dall'ID Microsoft Entra, seguire questa procedura:

1. Ottenere sourceAnchor e UPN in Microsoft Entra Connect.

   1. Aprire Microsoft Entra Connect.

   2. Fare clic su Visualizza configurazione corrente.

      

   3. Nella pagina Rivedi soluzione prendere nota dei valori di SOURCE ANCHOR e USER PRINCIPAL NAME.

2. Verificare i valori di immutableID (sourceAnchor) e UPN nella regola attestazione corrispondente configurata nel server AD FS.

   1. Nel server AD FS aprire la console di gestione di AD FS.

   2. Fare clic su Trust relying party.

   3. Fare clic con il pulsante destro del mouse sull'attendibilità della relying party con Microsoft Entra ID e quindi scegliere Modifica criterio di rilascio attestazioni.

   4. Aprire la regola attestazione per ID non modificabile e UPN.

   5. Verificare se le variabili sottoposte a query per i valori di immutableID e UPN sono uguali a quelle visualizzate in Microsoft Entra Connect.

      

3. Se esiste una differenza, usare uno dei metodi seguenti:

   • Se AD FS è gestito da Microsoft Entra Connect, reimpostare l'attendibilità della relying party tramite Microsoft Entra Connect.
   • Se AD FS non è gestito da Microsoft Entra Connect, correggere le attestazioni con gli attributi corretti.

Se questi controlli non consentono di risolvere il problema, vedere Usare l'app Token di dump per risolvere il problema.

Questo problema si verifica sul lato applicazione

Se il certificato di firma del token è stato rinnovato di recente da AD FS, verificare se il nuovo certificato viene prelevato dal partner federativo. Nel caso in cui AD FS usi anche un certificato di decrittografia di token rinnovato di recente, eseguire lo stesso controllo. Per verificare se il certificato di firma del token AD FS corrente in AD FS corrisponde a quello del partner federativo, seguire questa procedura:

1. Ottenere il certificato di firma del token corrente in AD FS eseguendo il comando seguente:

   Get-ADFSCertificate -CertificateType token-signing
   

2. Nell'elenco dei certificati restituiti trovare quello con IsPrimary = TRUE e prendere nota dell'identificazione personale.

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

4. Confrontare le identificazioni personali dei due certificati.

Eseguire lo stesso controllo se AD FS usa un certificato di decrittografia di token rinnovato, ad eccezione del fatto che il comando per ottenere il certificato di decrittografia del token in AD FS è il seguente:

Get-ADFSCertificate -CertificateType token-decrypting

Le identificazioni personali dei due certificati corrispondono

Se le identificazioni personali corrispondono, verificare che i partner usino i nuovi certificati AD FS.

In caso di mancata corrispondenza dei certificati, verificare che i partner usino i nuovi certificati. I certificati sono inclusi nei metadati della federazione pubblicati dal server AD FS.

Note

I partner fanno riferimento a tutti i partner dell'organizzazione delle risorse o dell'organizzazione account, rappresentati in AD FS tramite trust della relying party e trust del provider di attestazioni.

• I partner possono accedere ai metadati della federazione

  Se i partner possono accedere ai metadati della federazione, chiedere ai partner di usare i nuovi certificati.

• I partner non possono accedere ai metadati della federazione

  In questo caso, è necessario inviare manualmente ai partner le chiavi pubbliche dei nuovi certificati. A tale scopo, effettuare i passaggi seguenti:

  1. Esportare le chiavi pubbliche come file con estensione cert o come file con estensione p7b per includere l'intera catena di certificati.
  2. Inviare le chiavi pubbliche ai partner.
  3. Chiedere ai partner di usare i nuovi certificati.

Le identificazioni personali dei due certificati non corrispondono

Controllare quindi se è presente una mancata corrispondenza dell'algoritmo di firma del token. A tale scopo, effettuare i passaggi seguenti:

1. Determinare l'algoritmo usato dalla relying party 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 usato sul lato applicazione.

3. Controllare se i due algoritmi corrispondono.

Se i due algoritmi corrispondono, verificare se il formato id nome corrisponde a quello richiesto dall'applicazione.

1. Nel server AD FS eseguire il dump delle regole di trasformazione rilascio eseguendo il comando seguente:

   (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
   

2. Individuare la regola che rilascia l'attestazione NameIdentifier. Se tale regola non esiste, ignorare questo passaggio.

   Ecco 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 nella sintassi seguente:

   Properties["Property-type-URI"] = "ValueURI"

   I formati possibili sono elencati di seguito. 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 il formato NameIdentifier richiesto dall'applicazione.

4. Verificare se i due formati NameIdentifier corrispondono.

5. Se i formati non corrispondono, configurare l'attestazione NameIdentifier per usare il formato richiesto dall'applicazione. A tale scopo, effettuare i passaggi seguenti:

   1. Aprire la console di gestione di AD FS.
   2. Fare clic su Trust relying party, selezionare il partner federativo appropriato e quindi fare clic su Modifica criteri di rilascio delle attestazioni nel riquadro Azioni.
   3. Aggiungere una nuova regola se non esiste alcuna regola per rilasciare l'attestazione NameIdentifier o aggiornare una regola esistente. Selezionare ID nome per Tipo di attestazione in ingresso e quindi specificare il formato richiesto dall'applicazione.

   

Se i due algoritmi non corrispondono, aggiornare l'algoritmo di firma usato dal trust della relying party.

1. Aprire la console di gestione di AD FS.

2. Fare clic con il pulsante destro del mouse sull'attendibilità della relying party e quindi scegliere Proprietà.

3. Nella scheda Avanzate selezionare l'algoritmo in modo che corrisponda a quello richiesto dall'applicazione.

   

Informazioni sul rinnovo automatico dei certificati

Se il certificato di firma del token o il certificato di decrittografia dei token sono autofirmati, AutoCertificateRollover è abilitato per impostazione predefinita in questi certificati e AD FS gestisce il rinnovo automatico dei certificati quando sono prossimi alla scadenza.

Per determinare se si usano certificati autofirmato, seguire questa procedura:

1. Esegui questo comando:

   Get-ADFSCerticate -CertificateType "token-signing"
   

   

2. Esaminare gli attributi del certificato.

   Se gli attributi Subject e Issuer iniziano entrambi con "CN=ADFS Signing...", il certificato è autofirmato e gestito da AutoCertRollover.

Per verificare se i certificati vengono rinnovati automaticamente, seguire questa procedura:

1. Esegui questo comando:

   Get-ADFSProperties | FL AutoCertificateRollover
   

   

2. Esaminare l'attributo AutoCertificateRollover.

   • Se AutoCertificateRollover = TRUE, AD FS genera automaticamente nuovi certificati (30 giorni prima della scadenza per impostazione predefinita) e li imposta come certificati primari (25 giorni prima della scadenza).
   • Se AutoCertificateRollover = FALSE, è necessario sostituire manualmente i certificati.

Controllare i componenti e i servizi correlati ad ADFS

Questo articolo illustra come controllare i componenti e i servizi correlati ad ADFS. Questi passaggi possono essere utili per la risoluzione dei problemi di accesso (SSO) con Active Directory Federation Services (ADFS).

Controllare DNS

L'accesso ad ADFS deve puntare direttamente a uno dei server WAP (Proxy applicazione Web) o al servizio di bilanciamento del carico davanti ai server WAP. Eseguire i controlli seguenti:

• Effettuare il ping del nome del servizio federativo , ad esempio fs.contoso.com. Verificare se l'indirizzo IP risolto da Ping è uno dei server WAP o del servizio di bilanciamento del carico dei server WAP.
• Controllare se è presente un record A per il servizio federativo nel server DNS. Il record A deve puntare a uno dei server WAP o al servizio di bilanciamento del carico dei server WAP.

Se WAP non è implementato nello scenario per l'accesso esterno, verificare se l'accesso ad ADFS punta direttamente a uno dei server ADFS o al servizio di bilanciamento del carico davanti ai server ADFS:

• Effettuare il ping del nome del servizio federativo , ad esempio fs.contoso.com. Verificare se l'indirizzo IP che si ottiene viene risolto in uno dei server ADFS o nel servizio di bilanciamento del carico dei server ADFS.
• Controllare se è presente un record A per il servizio federativo nel server DNS. Il record A deve puntare a uno dei server ADFS o al servizio di bilanciamento del carico dei server ADFS.

Controllare il servizio di bilanciamento del carico se viene usato

Controllare se il firewall blocca il traffico tra:

• Il server ADFS e il servizio di bilanciamento del carico.
• Il server WAP (Web Application Proxy) e il servizio di bilanciamento del carico se viene usato WAP.

Se il probe è abilitato nel servizio di bilanciamento del carico, verificare quanto segue:

• Se si esegue Windows Server 2012 R2, assicurarsi che sia installato l'aggiornamento cumulativo di agosto 2014.
• Controllare se la porta 80 è abilitata nel firewall nei server WAP e nei server ADFS.
• Assicurarsi che il probe sia impostato per la porta 80 e per l'endpoint /adfs/probe.

Controllare le impostazioni del firewall

Controllare se il traffico in ingresso attraverso la porta TCP 443 è abilitato in:

• il firewall tra il server proxy applicazione Web e la server farm federativa.
• il firewall tra i client e il server proxy applicazione Web.

Controllare se il traffico in ingresso attraverso la porta TCP 49443 è abilitato nel firewall tra i client e il server proxy applicazione Web quando sono soddisfatte le condizioni seguenti:

• L'autenticazione client TLS con certificato X.509 è abilitata.
• Si usa ADFS in Windows Server 2012 R2.

Note

La configurazione non è necessaria nel firewall tra il server Proxy applicazione Web e i server federativi.

Controllare se l'endpoint è abilitato nel proxy

ADFS offre diversi endpoint per diverse funzionalità e scenari. Non tutti gli endpoint sono abilitati per impostazione predefinita. Per verificare se l'endpoint è abilitato nel proxy, seguire questa procedura:

1. Nel server ADFS aprire la Console di gestione ADFS.

2. Espandere Endpoint servizio>.

3. Individuare l'endpoint e verificare se lo stato è abilitato nella colonna Proxy Abilitato .

   

Controllare la relazione di trust proxy

Se il proxy applicazione Web (WAP) viene distribuito, la relazione di trust proxy deve essere stabilita tra il server WAP e il server AD FS. Controllare se la relazione di trust proxy viene stabilita o inizia a non riuscire in un determinato momento.

Note

Le informazioni contenute in questa pagina si applicano ad AD FS 2012 R2 e versioni successive.

Informazioni generali

La relazione di trust proxy è basata su certificato client. Quando si esegue la procedura guidata post-installazione del proxy applicazione Web, la procedura guidata genera un certificato client autofirmato usando le credenziali specificate nella procedura guidata. La procedura guidata inserisce quindi il certificato nel database di configurazione di AD FS e lo aggiunge all'archivio certificati AdfsTrustedDevices nel server AD FS.

Per qualsiasi comunicazione SSL, http.sys usa l'ordine di priorità seguente per le associazioni di certificati SSL in modo che corrispondano a un certificato:

Priorità	Nome	Parametri	Descrizione
1	IP	IP:port	Corrispondenza esatta di IP e porta
2	SNI	Hostname:port	Corrispondenza esatta del nome host (la connessione deve specificare SNI)
3	CCS	Porta	Richiamare l'archivio certificati centrale
4	Carattere jolly IPv6	Porta	Corrispondenza con caratteri jolly IPv6 (la connessione deve essere IPv6)
5	Carattere jolly IP	Porta	Corrispondenza con caratteri jolly IP (la connessione può essere IPv4 o IPv6)

AD FS 2012 R2 e versioni successive sono indipendenti da Internet Information Services (IIS) e vengono eseguiti come servizio su http.sys. le associazioni di certificati SSL hostname:port vengono usate da AD FS. Durante l'autenticazione del certificato client, AD FS invia un elenco di certificati attendibili (CTL) basato sui certificati nell'archivio AdfsTrustedDevices. Se un'associazione di certificati SSL per il server AD FS usa IP:port o l'archivio CTL non è AdfsTrustedDevices, la relazione di trust proxy potrebbe non essere stabilita.

Ottenere le associazioni di certificati SSL per AD FS

Nel server AD FS eseguire il comando seguente in Windows PowerShell:
netsh http show sslcert

Nell'elenco dei binding restituiti cercare quelli con ID applicazione 5d89a20c-beab-4389-9447-324788eb944a. Di seguito è riportato un esempio di associazione integra. Prendere nota della riga "Ctl Store Name".

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

Eseguire lo script per rilevare automaticamente i problemi

Per rilevare automaticamente i problemi relativi alla relazione di trust proxy, eseguire lo script seguente. In base al problema rilevato, eseguire l'azione di conseguenza.

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.")

Problema 1: Esiste un'associazione specifica ip

L'associazione può essere in conflitto con l'associazione di certificati AD FS sulla porta 443.

L'associazione IP:port ha la precedenza più alta. Se un'associazione IP:port si trova nelle associazioni di certificati SSL di AD FS, http.sys usa sempre il certificato per l'associazione per la comunicazione SSL. Per risolvere questo problema, usare i metodi seguenti.

1. Rimuovere l'associazione IP:port

   Tenere presente che l'associazione IP:port può tornare dopo averlo rimosso. Ad esempio, un'applicazione configurata con questa associazione IP:port può ricrearla automaticamente all'avvio successivo del servizio.

2. Usare un altro indirizzo IP per la comunicazione SSL di AD FS

   Se l'associazione IP:port è necessaria, risolvere il nome di dominio completo del servizio ADFS in un altro indirizzo IP non usato in alcuna associazione. In questo modo, http.sys userà l'associazione Hostname:port per la comunicazione SSL.

3. Impostare AdfsTrustedDevices come archivio CTL per l'associazione IP:port

   Questa è l'ultima risorsa se non è possibile usare i metodi precedenti. Ma è meglio comprendere le condizioni seguenti prima di modificare l'archivio CTL predefinito in AdfsTrustedDevices:

   • Perché è presente l'associazione IP:port.
   • Se l'associazione si basa sull'archivio CTL predefinito per l'autenticazione del certificato client.

Problema 2: L'associazione di certificati AD FS non ha il nome dell'archivio CTL impostato su AdfsTrustedDevices

Se Microsoft Entra Connect è installato, usare Microsoft Entra Connect per impostare il nome dell'archivio CTL su AdfsTrustedDevices per le associazioni di certificati SSL in tutti i server AD FS. Se Microsoft Entra Connect non è installato, rigenerare le associazioni di certificati AD FS eseguendo il comando seguente in tutti i server AD FS.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problema 3: Esiste un certificato non autofirmato nell'archivio certificati AdfsTrustedDevices

Se un certificato rilasciato da una CA si trova in un archivio certificati in cui in genere esistono solo i certificati autofirmati, il CTL generato dall'archivio conterrà solo il certificato emesso dalla CA. L'archivio certificati AdfsTrustedDevices è un archivio di questo tipo che dovrebbe avere solo certificati autofirmati. Questi certificati sono:

• MS-Organization-Access: certificato autofirmato usato per rilasciare certificati di aggiunta all'area di lavoro.
• Attendibilità proxy ADFS: certificati per ogni server proxy applicazione Web.

Eliminare pertanto qualsiasi certificato rilasciato dalla CA dall'archivio certificati AdfsTrustedDevices.

Problema 4: Installare KB2964735 o eseguire nuovamente lo script con -syncproxytrustcerts

Quando viene stabilita una relazione di trust proxy con un server AD FS, il certificato client viene scritto nel database di configurazione di AD FS e aggiunto all'archivio certificati AdfsTrustedDevices nel server AD FS. Per una distribuzione di farm AD FS, è previsto che il certificato client venga sincronizzato con gli altri server AD FS. Se la sincronizzazione non viene eseguita per qualche motivo, una relazione di trust proxy funzionerà solo con il server AD FS con cui è stato stabilito il trust, ma non con gli altri server AD FS.

Per risolvere questo problema, usare uno dei metodi seguenti.

Metodo 1

Installare l'aggiornamento documentato in KB 2964735 in tutti i server AD FS. Dopo l'installazione dell'aggiornamento, si prevede che venga eseguita automaticamente una sincronizzazione del certificato client.

Metodo 2

Eseguire lo script con l'opzione syncproxytrustcerts per sincronizzare manualmente i certificati client dal database di configurazione di AD FS all'archivio certificati AdfsTrustedDevices. Lo script deve essere eseguito in tutti i server AD FS della farm.

Note

Questa non è una soluzione permanente perché i certificati client verranno rinnovati regolarmente.

Problema 5: vengono superati tutti i controlli. Ma il problema persiste

Controllare se esiste una mancata corrispondenza del fuso orario o dell'ora. Se l'ora corrisponde ma il fuso orario non lo fa, anche la relazione di trust proxy non verrà stabilita.

Controllare se è presente una terminazione SSL tra il server AD FS e il server WAP

Se si verifica la terminazione SSL in un dispositivo di rete tra i server AD FS e il server WAP, la comunicazione tra AD FS e WAP si interrompe perché la comunicazione è basata sul certificato client.

Disabilitare la terminazione SSL nel dispositivo di rete tra i server AD FS e WAP.

Usare l'app Dump Token

L'app Token dump è utile durante il debug dei problemi con il servizio federativo e la convalida di regole attestazioni personalizzate. Non è una soluzione ufficiale, ma una buona soluzione di debug indipendente consigliata per la risoluzione dei problemi.

Prima di usare l'app Dump Token

Prima di usare l'app Dump Token, è necessario:

1. Ottenere le informazioni della relying party per l'applicazione a cui si vuole accedere. Se viene implementata l'autenticazione OAuth, ottenere anche le informazioni sul client OAuth.
2. Configurare l'app Dump Token.

Ottenere le informazioni sul client OAuth e sulla relying party

Se si usa una relying party convenzionale, seguire questa procedura:

1. Nel server AD FS aprire Windows PowerShell con l'opzione Esegui come amministratore .

2. Aggiungere il componente AD FS 2.0 a Windows PowerShell eseguendo il comando seguente:

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Ottenere le informazioni sulla relying party 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 usa la funzionalità Gruppo di applicazioni in Windows Server 2016, seguire questa procedura:

1. Nel server AD FS aprire Windows PowerShell con l'opzione Esegui come amministratore .

2. Ottenere le informazioni sulla relying party 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 OAuth è riservato, ottenere le informazioni sul client eseguendo il comando seguente:

   $client = Get-AdfsServerApplication ClientName
   

Configurare l'app Dump Token

Per configurare l'app Token dump, eseguire i comandi seguenti 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 ora con i metodi di risoluzione dei problemi seguenti. Alla fine di ogni metodo, verificare se il problema è stato risolto. In caso contrario, usare un altro metodo.

Metodi di risoluzione dei problemi

Controllare i criteri di autorizzazione per verificare se l'utente è interessato

In questo metodo si inizia ottenendo i dettagli dei criteri e quindi si usa l'app Dump Token per diagnosticare i criteri per verificare se l'utente è interessato.

Ottenere i dettagli dei criteri

$rp. IssuanceAuthorizationRules mostra le regole di autorizzazione della relying party.

In Windows Server 2016 e versioni successive è possibile usare $rp. AccessControlPolicyName per configurare i criteri di autenticazione e autorizzazione. Se $rp. AccessControlPolicyName ha valore, viene impostato un criterio di controllo di accesso che regola i criteri di autorizzazione. In tal caso, $rp. IssuanceAuthorizationRules è vuoto. Usare $rp. ResultantPolicy per informazioni dettagliate sui criteri di controllo di accesso.

Se $rp. ResultantPolicy non ha i dettagli sui criteri, esaminare le regole effettive dell'attestazione. Per ottenere le regole attestazioni, seguire questa procedura:

1. Impostare i criteri di controllo di accesso su $null eseguendo il comando seguente:
   Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
2. Ottenere le informazioni sulla relying party eseguendo il comando seguente:
   $rp = Get-AdfsRelyingPartyTrust RPName
3. Controllare $rp.IssuanceAuthorizationRules e $rp. AdditionalAuthenticationRules.

Usare l'app Dump Token per diagnosticare i criteri di autorizzazione

1. Impostare i criteri di autenticazione del token di dump come la relying party non riuscita.

2. Chiedere all'utente di aprire uno dei collegamenti seguenti a seconda dei criteri di autenticazione impostati.

   • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Forzare l'autenticazione a più fattori: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

3. Accedere alla pagina Di accesso.

Quello che si ottiene è il set di attestazioni dell'utente. Verificare se nel criterio di autorizzazione sono presenti elementi che negano esplicitamente o consentono all'utente in base a queste attestazioni.

Controllare se un'attestazione mancante o imprevista causa la negazione dell'accesso alla risorsa

1. Configurare le regole attestazioni nell'app Token dump in modo che corrispondano alle regole attestazioni della relying party non riuscita.

2. Configurare i criteri di autenticazione del token di dump in modo che corrispondano alla relying party non riuscita.

3. Chiedere all'utente di aprire uno dei collegamenti seguenti a seconda dei criteri di autenticazione impostati.

   • WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Forzare l'autenticazione a più fattori: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

4. Accedere alla pagina Di accesso.

Si tratta del set di attestazioni che la relying party otterrà per l'utente. Se sono presenti attestazioni mancanti o impreviste, esaminare i criteri di rilascio per individuare il motivo.

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

Controllare se è necessario uno stato del dispositivo

Se le regole di autorizzazione controllano le attestazioni del dispositivo, verificare se una di queste attestazioni del dispositivo non è presente nell'elenco delle attestazioni ottenute dall'app Token dump. Le attestazioni mancanti potrebbero bloccare l'autenticazione del dispositivo. Per ottenere le attestazioni dall'app Token dump, seguire la procedura descritta nella sezione Usare l'app Token dump per diagnosticare i criteri di autorizzazione nel criterio di autorizzazione Controllare se l'utente è stato interessato dal metodo.

Di seguito sono riportate le attestazioni del dispositivo. Le regole di autorizzazione possono usare alcune di esse.

• 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 è presente un'attestazione mancante, seguire la procedura descritta in Configurare l'accesso condizionale locale usando i dispositivi registrati per assicurarsi che l'ambiente sia configurato per l'autenticazione del dispositivo.

Se sono presenti tutte le attestazioni, verificare se i valori delle attestazioni dell'app Token dump corrispondono ai valori necessari nei criteri di autorizzazione.