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

  • Articolo

Questo articolo consente di 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 NTLM o basata su moduli

Durante la risoluzione dei problemi relativi all'accesso Single Sign-On (SSO) con Active Directory Federation Services (AD FS), se gli utenti hanno ricevuto una richiesta di autenticazione NTLM o basata su moduli imprevista, seguire la procedura descritta in questo articolo per risolvere il problema.

Controllare le impostazioni dell'autenticazione integrata di Windows

Per risolvere questo problema, controllare le impostazioni dell'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 Sicurezza>Siti>Intranet> localiAvanzate, assicurarsi che l'URL di AD FS sia incluso nell'elenco dei siti Web.
  • Dopo Sicurezza > Intranet > locale Livello personalizzato verificare che sia selezionata l'impostazione Accesso automatico solo nell'area Intranet .

Se si usa Firefox, Chrome o Safari, verificare che le impostazioni equivalenti in questi browser siano abilitate.

Controllare le impostazioni di AD FS

Controlla l'impostazione WindowsIntegratedFallback

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

  2. Ottenere i criteri di autenticazione globale 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 supporto del browser.

Se il valore è False, dovrebbe essere 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 delle stringhe dell'agente utente restituite dal comando.

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

  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 di 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 ad AD FS.

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

Nota

I moduli di PowerShell di Azure AD e MSOnline sono deprecati a partire dal 30 marzo 2024. Per altre informazioni, vedere l'aggiornamento della deprecazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza per la migrazione a Microsoft Graph PowerShell SDK e alle correzioni per la 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 frequenti sulla migrazione, vedere Domande frequenti sulla migrazione. Nota: Le versioni 1.0.x di MSOnline potrebbero verificarsi interruzioni dopo il 30 giugno 2024.

Se l'applicazione è Microsoft Online Services, l'esperienza può essere controllata dall'impostazione PromptLoginBehavior dall'oggetto area di autenticazione attendibile. Questa impostazione controlla se Microsoft Entra tenant 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 anziché prompt=login. Ciò comporta 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 Active Directory Federation Services supporto del parametro prompt=login.

scenario Microsoft Entra

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

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

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

Scenario non Microsoft Entra

I parametri di richiesta come WAUTH e RequestedAuthNContext nelle richieste di autenticazione possono avere metodi di autenticazione specificati. Verificare se altri parametri della richiesta applicano la richiesta di autenticazione imprevista. In tal caso, modificare il parametro della richiesta in modo da usare il metodo di autenticazione previsto.

Controllare se l'accesso SSO è disabilitato

Se l'accesso 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 ripetutamente richiesta, 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:

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

    Nota

    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=…]
  • L'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 non 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 che risponde non passi all'applicazione le attestazioni di autenticazione a più fattori. Per verificare se le attestazioni di autenticazione vengono passate, seguire questa procedura:

  1. Eseguire il comando indicato di seguito 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 di 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 ad AD FS.

Verificare 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 di federazione del dominio SupportsMFA corrente 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 SSO è disabilitato

Se l'accesso 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 ad AD FS o sul lato applicazione.

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

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 i passaggi descritti nella sezione seguente in base alla posizione in cui si verifica questo problema.

Questo problema si verifica nella pagina di accesso ad 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 a nessuna delle 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 se 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 ADFS è in esecuzione.

  1. Nel server AD FS aprire Server Manager.
  2. Nella Server Manager fare clic su Strumenti>di Servizi.
  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 se 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 la procedura descritta in Tutti gli utenti interessati dal problema e l'utente può accedere ad alcune delle relying party.

L'accesso non riesce

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. Nella Server Manager fare clic su Strumenti>di Servizi.
  3. Controllare se lo stato di Active Directory Federation Services è In esecuzione.

Controllare se gli endpoint sono abilitati. AD FS offre vari endpoint per funzionalità e scenari diversi. 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. EspandereEndpointservizio>.

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

    Controllare lo stato di tutti gli endpoint A D F S abilitati.

Verificare quindi se Microsoft Entra Connect è installato. È 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 che il certificato SSL soddisfi i requisiti AD FS seguenti:

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

    AD FS richiede che i certificati SSL provenivano da un'autorità di certificazione radice attendibile. Se si accede ad AD FS da computer non appartenenti 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 del soggetto del certificato è valido.

    Il nome del soggetto deve corrispondere al nome del servizio federativo, non al nome del server AD FS o a 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 presenza di revoche di 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 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 è incluso nell'elenco.
Verificare se è in uso il certificato SSL corretto

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. Questa operazione non viene eseguita automaticamente. Per verificare se è impostato il certificato corretto, seguire questa procedura:

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

Se è elencato il certificato errato, impostare il certificato corretto e quindi concedere al servizio AD FS l'autorizzazione lettura per il certificato. A tal fine, attenersi alla seguente procedura:

  1. Impostare il certificato corretto:

    1. Fare clic con il pulsante destro del mouse su Certificati e 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 del computer locale a Microsoft Management Console (MMC).
    2. Espandere Certificati (computer locale)>Certificati personali>.
    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 Nomi di gruppo e utenti 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 contoso.com UPN e fabrikam.com, il certificato deve avere enterpriseregistration.contoso.com e enterpriseregistration.fabrikma.com come nomi alternativi soggetto (SAN).

Per verificare se il certificato SSL dispone dei nomi SAN corretti, seguire questa procedura:

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

    Get-AdfsDeviceRegistratrionUpnSuffix

  2. Verificare se nel certificato SSL sono configurati i nomi SAN necessari.

  3. Se il certificato SSL non ha i nomi DRS corretti come nomi SAN, ottenere un nuovo certificato SSL con i nomi SAN corretti per DRS e quindi 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 le associazioni di fallback negli ID applicazione seguenti:

    • {5d89a20c-beab-4389-9447-324788eb944a}: ID applicazione per AD FS.
    • {f955c070-e044-456c-ac00-e9e4275b3f04}: ID applicazione per Application Proxy 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

Per prima cosa, si ottengono le informazioni del client OAuth e della relying party. 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 del 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 ancora verificarsi una mancata corrispondenza tra ciò che il proprietario fornisce e ciò che sono configurati in AD FS. Ad esempio, una mancata corrispondenza potrebbe essere causata da un errore di digitazione. Controllare se le impostazioni fornite dal proprietario corrispondono a quelle configurate in AD FS. I passaggi nella pagina precedente consentono di ottenere le impostazioni configurate 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 Un prefisso o una corrispondenza con caratteri 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 nella tabella corrispondono, verificare inoltre se queste impostazioni corrispondono a quelle visualizzate nella richiesta di autenticazione inviata ad AD FS e a quelle configurate in AD FS. Provare a riprodurre il problema durante il quale si acquisisce una traccia di Fiddler nella 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 della 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 di 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 di prefisso o 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 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 di AD FS viene inviata agli URL corrispondenti configurati negli endpoint. Un endpoint SAML può usare binding di reindirizzamento, post o artefatto per la trasmissione dei 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 di controllo delle revoche.
I due metodi precedenti non funzionano

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

Non tutti gli utenti sono interessati dal problema e l'utente non può accedere a nessuna delle 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 qualsiasi dei 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

    Usare il comando Get-ADUser per controllare lo stato abilitato dall'utente.

Controllare lo stato dell'utente nell'interfaccia utente

  1. Accedere a uno qualsiasi 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 .

    Controllare se l'opzione Account è disabilitata.

  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, comporta una modifica dei 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. 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 Ora/Data per ogni attributo per individuare eventuali indizi 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.

    Output del comando repadmin showobjmeta.

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 usano la distribuzione 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 Domini e trust di Active Directory .

  3. Nella console di gestione fare clic con il pulsante destro del mouse sul dominio che contiene il trust che si vuole verificare e quindi scegliere Proprietà.

  4. Fare clic sulla scheda Attendibilità .

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

  6. Fare clic su Convalida.
    Nella finestra di dialogo Active Directory Domain Services 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.

      Convalidare l'attendibilità in ingresso nella finestra di dialogo Active Directory Domain Services.

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 .

Non tutti gli utenti sono interessati dal problema e l'utente può accedere ad alcune delle 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 token di dump per risolvere questo problema.

Verificare 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 di un accesso non riuscito è che l'utente non è ancora sincronizzato con Microsoft Entra ID. Potrebbe essere visualizzato un ciclo da Microsoft Entra ID ad Active Directory FS dopo il primo tentativo di autenticazione in 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 di utenti nel Microsoft Entra ID eseguendo il comando seguente:
    Get-MsolUser
  6. Verificare se l'utente è incluso nell'elenco.

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

Controllare l'ID non modificabile e l'UPN nella regola attestazioni di rilascio

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

Nota

immutableID è anche chiamato 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 eseguire questa operazione 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 quelle usate Microsoft Entra ID, seguire questa procedura:

  1. Ottenere sourceAnchor e UPN in Microsoft Entra Connect.

    1. Aprire Microsoft Entra Connect.

    2. Fare clic su Visualizza configurazione corrente.

      Selezionare la pagina Visualizza configurazione corrente nella pagina Connetti attività aggiuntive Microsoft Entra.

    3. Nella pagina Rivedi la soluzione prendere nota dei valori 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 Attendibilità 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 l'ID non modificabile e l'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.

      Verificare i valori di immutableID e UPN nella regola attestazione corrispondente configurata nel server A D F S.

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

    • Se AD FS è gestito da Microsoft Entra Connect, reimpostare l'attendibilità della relying party usando 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 un certificato di decrittografia del token che è stato 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 nel 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.

  4. Confrontare le identificazioni personali dei due certificati.

Eseguire lo stesso controllo se AD FS usa un certificato di decrittografia del 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, assicurarsi che i partner usno i nuovi certificati AD FS.

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

Nota

I partner fanno riferimento a tutti i partner dell'organizzazione delle risorse o dell'organizzazione dell'account, rappresentati in AD FS da attendibilità 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 di federazione

    In questo caso, è necessario inviare manualmente ai partner le chiavi pubbliche dei nuovi certificati. A tal fine, attenersi alla seguente procedura:

    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 esiste una mancata corrispondenza dell'algoritmo di firma del token. A tal fine, attenersi alla seguente procedura:

  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. Verificare con il proprietario dell'applicazione l'algoritmo usato sul lato applicazione.

  3. Controllare se i due algoritmi corrispondono.

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

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

    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules

  2. Individuare la regola che genera 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 tal fine, attenersi alla seguente procedura:

    1. Aprire la console di gestione AD FS.
    2. Fare clic su Attendibilità relying party, selezionare il partner federativo appropriato e quindi fare clic su Modifica criteri di rilascio attestazioni nel riquadro Azioni .
    3. Aggiungere una nuova regola se non è presente 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.

    Aggiungere una regola di trasformazione attestazione se non è presente alcuna regola per rilasciare l'attestazione NameIdentifier o aggiornare una regola esistente.

Se i due algoritmi non corrispondono, aggiornare l'algoritmo di firma usato dall'attendibilità della relying party.

  1. Aprire la console di gestione 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 base alle esigenze dell'applicazione.

    Selezionare l'algoritmo in modo che corrisponda a quanto richiesto dall'applicazione nella scheda Avanzate della finestra di dialogo Impostazione proprietà.

Informazioni sul rinnovo automatico del certificato

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

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

  1. Eseguire il comando riportato di seguito:

    Get-ADFSCerticate -CertificateType "token-signing"

    Eseguire il cmdlet Get-ADFSCerticate, Certificate Type token-signing.Run the Get-ADFSCerticate cmdlet, Certificate Type token-signing.

  2. Esaminare gli attributi del certificato.

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

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

  1. Eseguire il comando riportato di seguito:

    Get-ADFSProperties | FL AutoCertificateRollover

    Eseguire il cmdlet Get-ADFSProperties per verificare se i certificati vengono rinnovati automaticamente.

  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 prima della scadenza (25 giorni prima della scadenza).
    • Se AutoCertificateRollover = FALSE, è necessario sostituire manualmente i certificati.

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 (Web Application Proxy) o al servizio di bilanciamento del carico davanti ai server WAP. Eseguire i controlli seguenti:

  • Eseguire il ping del nome del servizio federativo , ad esempio fs.contoso.com. Verificare se l'indirizzo IP in cui viene risolto il ping è di 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:

  • Eseguire il ping del nome del servizio federativo , ad esempio fs.contoso.com. Verificare se l'indirizzo IP ottenuto 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 probe è abilitato nel servizio di bilanciamento del carico, controllare quanto segue:

  • Se si esegue Windows Server 2012 R2, assicurarsi che l'aggiornamento cumulativo di agosto 2014 sia installato.
  • 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

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

  • il firewall tra il server Application Proxy Web e la server farm federativa.
  • il firewall tra i client e il server Application Proxy Web.

Verificare se il traffico in ingresso attraverso la porta TCP 49443 è abilitato nel firewall tra i client e il server Application Proxy Web quando si verificano le condizioni seguenti:

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

Nota

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

Controllare se l'endpoint è abilitato nel proxy

ADFS offre vari endpoint per funzionalità e scenari diversi. 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. EspandereEndpointservizio>.

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

    Verificare lo stato degli endpoint A D F S visualizzato nella colonna Proxy Abilitato.

Controllare la relazione di trust proxy

Se viene distribuito web Application Proxy (WAP), è necessario stabilire la relazione di trust proxy tra il server WAP e il server AD FS. Verificare se la relazione di trust proxy viene stabilita o inizia a non riuscire in un determinato momento.

Nota

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

Informazioni complementari

La relazione di trust proxy è basata su certificati client. Quando si esegue la procedura guidata di post-installazione Application Proxy Web, la procedura guidata genera un certificato client autofirmate 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:porta Corrispondenza esatta tra IP e porta
2 SNI Nome host:porta 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) ed eseguiti come servizio oltre a http.sys. nome host:associazioni di certificati SSL di porta vengono usate da AD FS. Durante l'autenticazione del certificato client, AD FS invia un elenco di attendibilità del certificato (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 delle associazioni restituite cercare quelle con ID applicazione 5d89a20c-beab-4389-9447-324788eb944a. Di seguito è riportato un esempio di associazione integra. Si noti la 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 dell'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 le comunicazioni SSL. Per risolvere questo problema, usare i metodi seguenti.

  1. Rimuovere l'associazione IP:port

    Tenere presente che l'associazione IP:port potrebbe tornare dopo essere stata rimossa. Ad esempio, un'applicazione configurata con questo binding IP:port può ricrearla automaticamente all'avvio del servizio successivo.

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

    Se è necessaria l'associazione IP:port, 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 CTL Store Name impostato su AdfsTrustedDevices

Se Microsoft Entra Connect è installato, usare Microsoft Entra Connect per impostare CTL Store Name 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 certificati autofirmati, l'elenco CTL generato dall'archivio conterrà solo il certificato emesso dalla CA. L'archivio certificati AdfsTrustedDevices è un archivio che dovrebbe avere solo certificati autofirmati. Questi certificati sono:

  • MS-Organization-Access: certificato autofirmati usato per il rilascio di certificati di aggiunta all'area di lavoro.
  • Attendibilità proxy ADFS: certificati per ogni server Application Proxy Web.

Certificati per ogni server Application Proxy Web.

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

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

Quando viene stabilita una relazione di trust proxy con un server ADFS, 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 della farm AD FS, si prevede 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 la sincronizzazione del certificato client venga eseguita automaticamente.

Metodo 2

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

Nota

Questa non è una soluzione permanente perché i certificati client verranno rinnovati a intervalli regolari.

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

Controllare se non è presente una mancata corrispondenza di fuso orario o 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 la terminazione SSL si verifica in un dispositivo di rete tra i server AD FS e il server WAP, la comunicazione tra AD FS e WAP si interromperà 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 Token di dump

L'app Token dump è utile per il debug di problemi con il servizio federativo e per la convalida delle regole attestazioni personalizzate. Non si tratta di una soluzione ufficiale, ma di una buona soluzione di debug indipendente consigliata ai fini della 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 del client OAuth.
  2. Configurare l'app Token dump.

Ottenere le informazioni del client OAuth e della 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 del 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 Dump Token, eseguire i comandi seguenti nella finestra 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 recuperando i dettagli dei criteri e quindi si usa l'app Token dump 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, sono in vigore criteri di controllo di accesso che regolano i criteri di autorizzazione. In tal caso, $rp. IssuanceAuthorizationRules è vuoto. Usare $rp. ResultantPolicy per trovare i dettagli sui criteri di controllo di accesso.

Se $rp. ResultantPolicy non ha i dettagli sui criteri, esaminare le regole di attestazione effettive. 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 token di dump per diagnosticare i criteri di autorizzazione

  1. Impostare i criteri di autenticazione del token di dump uguali a quello della relying party non riuscita.

  2. Fare in modo che l'utente apra 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 Sign-In.

Ciò che si ottiene è il set di attestazioni dell'utente. Verificare se nei criteri di autorizzazione sono presenti elementi che negano in modo esplicito o consentono all'utente in base a queste attestazioni.

Verificare 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. Fare in modo che l'utente apra 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 Sign-In.

Si tratta del set di attestazioni che la relying party otterrà per l'utente. Se le attestazioni sono 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 verificano la presenza di attestazioni del dispositivo, verificare che nessuna di queste attestazioni del dispositivo sia mancante nell'elenco di attestazioni otterrà dall'app Token di dump. Le attestazioni mancanti potrebbero bloccare l'autenticazione del dispositivo. Per ottenere le attestazioni dall'app Token di dump, seguire la procedura descritta nella sezione Usare l'app token di dump per diagnosticare i criteri di autorizzazione nel controllo dei criteri di autorizzazione 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 richiesti nei criteri di autorizzazione.