Risolvere i problemi relativi alle configurazioni della delega vincolata Kerberos con il proxy dell'applicazione Microsoft Entra
I metodi di Single Sign-On variano da un'applicazione a un'altra. Il proxy dell'applicazione Microsoft Entra fornisce la delega vincolata Kerberos (KCD) per impostazione predefinita. Gli utenti eseguono l'autenticazione alle applicazioni private usando Kerberos.
Questo articolo fornisce un singolo punto di riferimento per risolvere i problemi più comuni. Illustra anche la diagnosi di problemi di implementazione più complessi.
In questo articolo vengono riportati i presupposti seguenti.
- Distribuzione del proxy delle applicazioni Microsoft Entra e accesso generale alle applicazioni non KCD. Per ulteriori informazioni, vedere Iniziare con il proxy dell'applicazione.
- L'applicazione pubblicata si basa su Internet Information Services (IIS) e sull'implementazione Microsoft di Kerberos.
- Gli host server e applicazioni si trovano in un singolo dominio Microsoft Entra. Per altre informazioni sugli scenari tra domini e foreste, vedere white paper KCD.
- L'applicazione viene pubblicata in un tenant di Microsoft Entra con la preautenticazione abilitata. È previsto che gli utenti eseguano l'autenticazione utilizzando l'autenticazione basata su moduli. Gli scenari di autenticazione client avanzati non sono trattati in questo articolo.
Prerequisiti
Semplici errori di configurazione o errori generali causano la maggior parte dei problemi. Controllare tutti i prerequisiti in Utilizzo di Single Sign-On KCD con il proxy dell'applicazione prima di risolvere i problemi.
Gli host del connettore non sono limitati a comunicare esclusivamente con un controller di dominio specifico del sito locale. Controllare quale controller di dominio è in uso, poiché potrebbe cambiare.
Gli scenari tra domini si basano su segnalazioni che indirizzano un host del connettore a DC che potrebbero essere al di fuori del perimetro della rete locale. In questi casi, è altrettanto importante inoltrare traffico altresì ai domain controller, che rappresentano i rispettivi altri domini. In caso contrario, la delega fallisce.
Evitare dispositivi IPS (Intrusion Prevention System) o IDS (Sistema di rilevamento delle intrusioni) attivi tra host del connettore e controller di dominio. Questi dispositivi sono troppo intrusivi e interferiscono con il traffico RPC (Remote Procedure Call) principale.
Testare la delega in scenari semplici. Più variabili si introducono, più potrebbe essere necessario affrontare. Per risparmiare tempo, limitare il test a un singolo connettore. Aggiungere altri connettori dopo la risoluzione del problema.
Alcuni fattori ambientali potrebbero contribuire anche a un problema. Per evitare questi fattori, ridurre al minimo l'architettura possibile durante i test. Ad esempio, gli elenchi di controllo di accesso interni del firewall (ACL) configurati in modo errato sono comuni. Se possibile, inviare tutto il traffico da un connettore direttamente ai controller di dominio e all'applicazione back-end.
Il posto migliore per posizionare i connettori è il più vicino possibile alle loro destinazioni. Un firewall che è in linea durante i test aggiunge complessità non necessarie e può prolungare le indagini.
Che cosa mostra un problema KCD? Esistono diverse indicazioni comuni che il Single Sign-On di KCD sta fallendo. I primi segni di un problema vengono visualizzati nel browser.
Entrambe le immagini mostrano lo stesso sintomo: errore di Single Sign-On. L'accesso utente all'applicazione viene negato.
Risoluzione dei problemi
Separare la risoluzione dei problemi nelle tre fasi.
Autenticazione preliminare del client
L'utente esterno che esegue l'autenticazione tramite un browser. Per il funzionamento dell'accesso Single Sign-On (SSO) KCD, è necessario pre-autenticarsi su Microsoft Entra ID. Testare e affrontare questa capacità in caso di problemi. La fase di pre-autenticazione non è correlata a Kerberos con delega vincolata (KCD) o all'applicazione pubblicata. È facile correggere eventuali discrepanze controllando che l'account soggetto esista in Microsoft Entra ID. Verificare che l'applicazione non sia disabilitata o bloccata. La risposta di errore nel browser è sufficientemente descrittiva da spiegare la causa.
Servizio di delega
Connettore di rete privato che ottiene un ticket di servizio Kerberos per gli utenti da un Centro distribuzione chiavi Kerberos.
Le comunicazioni esterne tra il client e il front-end di Azure non hanno alcun effetto su KCD. Queste comunicazioni assicurano solo il funzionamento di KCD. Il servizio proxy dell'applicazione riceve un ID utente valido, usato per ottenere un ticket Kerberos. Senza questo ID, il KCD non è possibile e fallisce.
I messaggi di errore del browser forniscono alcuni indizi utili sul motivo per cui si verifica un errore. Registrare i campi activity ID e timestamp nella risposta. Le informazioni consentono di correlare il comportamento agli eventi effettivi nel registro eventi del proxy dell'applicazione.
esempio di 
Le voci corrispondenti visualizzate nel registro eventi vengono visualizzate come eventi 13019 o 12027. Trova i registri eventi del connettore nei Registri Applicazioni e Servizi>Microsoft>Microsoft Entra private network>Connector>Admin.
- Usare un record nel DNS (Domain Name System) interno per l'indirizzo dell'applicazione, non un
CName. - Assicurarsi che l'host del connettore sia autorizzato a delegare al Nome Principale del Servizio (SPN) dell'account specificato di destinazione. Riconfermare che è selezionata l'opzione Usa qualsiasi di protocollo di autenticazione. Per ulteriori informazioni, vedere l'articolo sulla configurazione SSO.
- Verificare che esista solo un'istanza di SPN in Microsoft Entra ID. Emmettere il comando
setspn -xda un prompt dei comandi su un qualsiasi host membro di un dominio. - Verificare che venga applicato un criterio di dominio che limita le dimensioni massime dei token Kerberos rilasciati. Il criterio impedisce al connettore di ottenere un token se è eccessivo.
Una traccia di rete che acquisisce scambi tra l'host del connettore e un controller di dominio con delega vincolata Kerberos (KDC) è il passaggio successivo migliore per ottenere maggiori dettagli di basso livello sui problemi. Per ulteriori informazioni, consultare il documento di approfondimento sulla risoluzione dei problemi .
Se il ticketing è corretto, nei log viene visualizzato un evento che informa che l'autenticazione non è riuscita perché l'applicazione ha restituito un valore 401. Questo evento indica che l'applicazione di destinazione ha rifiutato il ticket. Passare alla fase successiva.
Applicazione di destinazione
Il consumatore del ticket di Kerberos fornito dal connettore. In questa fase, si prevede che il connettore invia un ticket di servizio Kerberos al back-end. Il ticket è un'intestazione nella richiesta iniziale dell'applicazione.
Usando l'URL interno dell'applicazione definito nel portale, verificare che l'applicazione sia accessibile direttamente dal browser nell'host del connettore. Puoi quindi accedere con successo. I dettagli sono disponibili nella pagina del connettore Risoluzione Problemi.
Verificare che l'autenticazione tra il browser e l'applicazione usi Kerberos.
Eseguire DevTools (F12) in Internet Explorer oppure usare Fiddler dall'host del connettore. Passare all'applicazione usando l'URL interno. Per assicurarsi che Negotiate o Kerberos siano presenti, esaminare le intestazioni di autorizzazione Web fornite e restituite nella risposta dall'applicazione.
Il BLOB Kerberos successivo restituito nella risposta dal browser all'applicazione inizia con YII. Queste lettere stanno a indicare che Kerberos è in esecuzione. Microsoft NT LAN Manager (NTLM), d'altra parte, inizia sempre con TlRMTVNTUAAB, che legge NTLM Security Support Provider (NTLMSSP) quando decodificato da Base64. Se appare TlRMTVNTUAAB all'inizio del blob, Kerberos non è disponibile. Se non viene visualizzato TlRMTVNTUAAB, è probabile che Kerberos sia disponibile.
Nota
Se si usa Fiddler, questo metodo richiede di disabilitare temporaneamente la protezione estesa nella configurazione dell'applicazione in IIS.
Il blob in questa figura non inizia con TIRMTVNTUAAB. In questo esempio Kerberos è quindi disponibile e il BLOB Kerberos non inizia con YII.
Rimuovere temporaneamente NTLM dall'elenco dei provider nel sito IIS. Accedere all'app direttamente da Internet Explorer nell'host del connettore. NTLM non è più incluso nell'elenco dei provider. È possibile accedere all'applicazione solo usando Kerberos. Se l'accesso non riesce, potrebbe verificarsi un problema con la configurazione dell'applicazione. L'autenticazione Kerberos non funziona.
Se Kerberos non è disponibile, controllare le impostazioni di autenticazione dell'applicazione in IIS. Assicurati che Negotiate sia in cima all'elenco, con NTLM subito sotto. Se viene visualizzato Not Negotiate, Kerberos o Negotiateo PKU2U, continuare solo se Kerberos è funzionale.
Con Kerberos e NTLM sul posto, disabilitare temporaneamente la preautenticazione per l'applicazione nel portale. Provare ad accedervi da Internet usando l'URL esterno. Viene richiesto di eseguire l'autenticazione. È possibile farlo con lo stesso account usato nel passaggio precedente. In caso contrario, si è verificato un problema con l'applicazione back-end, non con KCD.
Riabilitare la preautenticazione nel portale. Eseguire l'autenticazione tramite Azure tentando di connettersi all'applicazione tramite l'URL esterno. Se l'accesso Single Sign-On non riesce, viene visualizzato un messaggio di errore non consentito nel browser e nell'evento 13022 nel log:
connettore di rete privata Microsoft Entra non è in grado di autenticare l'utente perché il server back-end risponde ai tentativi di autenticazione Kerberos con un errore HTTP 401.
Controllare l'applicazione IIS. Assicurarsi che il pool di applicazioni configurato e lo SPN siano configurati per l'uso dello stesso account in Microsoft Entra ID. Spostarsi in IIS come illustrato nella figura seguente.
Dopo aver identificato l'identità, assicurati che questo account sia configurato con l'SPN in questione. Un esempio è
setspn –q http/spn.wacketywack.com. Immettere il testo seguente nel prompt dei comandi.
Controllare il nome SPN definito in base alle impostazioni dell'applicazione nel portale. Assicurarsi che lo stesso SPN configurato per il account Microsoft Entra di destinazione venga utilizzato dal pool di applicazioni.
Passare a IIS e selezionare l'opzione Editor di configurazione per l'applicazione. Passare a system.webServer/security/authentication/windowsAuthentication. Assicurati che il valore UseAppPoolCredentials sia True.
Modificare il valore in True. Rimuovere tutti i ticket Kerberos memorizzati nella cache dal server back-end eseguendo il comando .
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
Se si lascia abilitata la modalità kernel, migliora le prestazioni delle operazioni Kerberos. Ma fa anche in modo che il ticket per il servizio richiesto venga decrittografato usando l'account del computer. Questo account viene chiamato anche sistema locale. Impostare questo valore su True per risolvere KCD quando l'applicazione è ospitata su più server in una farm.
Come ulteriore verifica, disabilitare anche la protezione estesa . In alcuni scenari, la protezione estesa ha interrotto KCD quando era abilitata in configurazioni specifiche. In questi casi, un'applicazione è stata pubblicata come sottocartella del sito Web predefinito. Questa applicazione è configurata solo per l'autenticazione anonima. Tutte le finestre di dialogo sono grigie, il che suggerisce che gli oggetti figlio non erediteranno impostazioni attive. È consigliabile eseguire il test, ma non dimenticare di ripristinare questo valore in abilitato, se possibile.
Questo controllo aggiuntivo consente di tenere traccia dell'uso dell'applicazione pubblicata. È possibile attivare più connettori configurati anche per delegare. Per ulteriori informazioni, consultare la più approfondita procedura dettagliata tecnica, Risoluzione dei problemi relativi al proxy dell'applicazione Microsoft Entra.
Se non è ancora possibile fare progressi, il supporto Tecnico Microsoft può aiutarti. Creare un ticket di supporto direttamente nel portale.
Altri scenari
Microsoft Entra application proxy richiede un ticket Kerberos prima di inviare la richiesta a un'applicazione. Alcune applicazioni non amano questo metodo di autenticazione. Queste applicazioni si aspettano che si esegino i negoziati più convenzionali. La prima richiesta è anonima, che consente all'applicazione di rispondere con i tipi di autenticazione supportati tramite 401. Questo tipo di negoziazione Kerberos può essere abilitato usando i passaggi descritti in questo documento: Delega Vincolata Kerberos per il Single Sign-On.
L'autenticazione multi-hop viene comunemente usata negli scenari in cui un'applicazione è modulare. I livelli includono un back-end e un front-end. Entrambi i livelli richiedono l'autenticazione. Ad esempio, SQL Server Reporting Services. Per altre informazioni, vedere Come configurare la delega vincolata Kerberos per le pagine proxy di registrazione Web.