Risolvere i problemi delle configurazioni della Delega vincolata Kerberos (KCD) 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 Delega vincolata Kerberos (KCD) per impostazione predefinita. Gli utenti eseguono l'autenticazione alle applicazioni private usando Kerberos.

Questo articolo offre un punto di riferimento unico per risolvere e correggere i problemi più comuni. Spiega anche come diagnosticare problemi relativi a implementazioni più complesse.

L'articolo presuppone quanto segue.

• Distribuzione del proxy dell’applicazione Microsoft Entra e dell'accesso generale alle applicazioni non KCD. Per ulteriori informazioni, vedere Introduzione al proxy dell’applicazione.
• L'applicazione pubblicata è basata su Internet Information Services (IIS) e sull'implementazione Microsoft di Kerberos.
• Gli host del server e dell'applicazione si trovano in un unico dominio di Microsoft Entra. Per ulteriori informazioni sugli scenari con diversi domini e foreste di domini, vedere il white paper sulla delega vincolata Kerberos.
• L'applicazione è pubblicata in un tenant di Microsoft Entra con preautenticazione abilitata. Gli utenti devono eseguire l'autenticazione tramite l'autenticazione basata su moduli. Gli scenari di autenticazione dei rich client non sono trattati in questo articolo,

Prerequisiti

ma a semplici errori di configurazione o a errori generici. Prima di risolvere i problemi, controllare tutti i prerequisiti in Uso dell'accesso Single Sign-On KCD con il proxy dell'applicazione.

Gli host del connettore non sono limitati alla comunicazione con specifici controller di dominio di siti locali. Controllare il controller di dominio in uso, in quanto potrebbe cambiare.

Gli scenari tra domini si affidano ai riferimenti che indirizzano un host del connettore ai controller di dominio che possono trovarsi all'esterno del perimetro della rete locale. In questi casi, è altrettanto importante consentire il traffico verso i controller di dominio che rappresentano altri rispettivi domini. In caso contrario, la delega avrà esito negativo.

Evitare dispositivi IPS (Intrusion Prevention System) attivi o IDS (Sistema di rilevamento delle intrusioni) tra gli host del connettore e i controller di dominio. Questi dispositivi sono altamente intrusivi e interferiscono con il traffico RPC (Remote Procedure Call) di base.

È consigliabile testare la delega negli scenari più semplici. Il numero di variabili introdotte è infatti direttamente proporzionale ai problemi da risolvere. Ad esempio, limitare i test a un singolo connettore permette di risparmiare tempo prezioso Aggiungere altri connettori dopo aver risolto il problema.

I problemi possono essere legati anche ad alcuni fattori ambientali. Per evitare questi fattori, ridurre al minimo l'architettura durante i test. Ad esempio, spesso si verificano errori di configurazione negli elenchi di controllo di accesso (ACL) del firewall interno. Se possibile, quindi, consentire tutto il traffico di un connettore direttamente verso i controller di dominio e l'applicazione back-end.

È consigliabile posizionare i connettori il più vicino possibile alle destinazioni. La presenza di un firewall inline durante il test aggiunge complessità superflua e può prolungare l'analisi.

Che cosa costituisce un problema di delega vincolata Kerberos? Ci sono diverse indicazioni tipiche di problemi con l'accesso Single Sign-On della delega vincolata Kerberos. I primi segnali si manifestano in genere nel browser.

Entrambe le immagini mostrano lo stesso sintomo: errore di Single Sign-On. L'accesso dell'utente all'applicazione viene negato.

Risoluzione dei problemi

Separare la risoluzione dei problemi nelle tre fasi.

Preautenticazione del client

L’utente esterno esegue l’autenticazione tramite un browser. Per garantire il funzionamento dell'accesso Single Sign-On della delega vincolata Kerberos, è essenziale poter eseguire la preautenticazione in Microsoft Entra ID. È consigliabile eseguire test e risolvere gli eventuali problemi. La fase di preautenticazione non è in alcun modo correlata alla delega vincolata Kerberos o all'applicazione pubblicata. È semplice risolvere eventuali discrepanze verificando che l'account sia presente in Microsoft Entra ID. Verificare che l'applicazione non sia disabilitata o bloccata. La risposta di errore nel browser è in genere sufficientemente descrittiva per comprendere la causa.

Servizio di delega

Il connettore di rete privata che ottiene un ticket di servizio Kerberos da un Centro distribuzione chiavi Kerberos (KCD) per gli utenti.

Le comunicazioni esterne tra il client e il front-end di Azure non dovrebbero avere comunque alcuna rilevanza sulla delega vincolata Kerberos, se non per garantirne il funzionamento. In questo modo il servizio proxy dell’applicazione può ricevere un ID utente valido usato per ottenere un ticket Kerberos. Senza di questo, la delega vincolata Kerberos non sarebbe possibile e l'operazione avrebbe esito negativo.

I messaggi di errore del browser offrono in genere alcune indicazioni valide sul motivo per cui si verificano errori. Registrare i campi activity ID e timestamp nella risposta. Queste informazioni consentono di associare il comportamento a eventi correnti nel registro eventi del servizio proxy dell’applicazione.

Le voci corrispondenti visualizzate nel log eventi vengono mostrate come eventi 13019 o 12027. I log eventi dei connettori sono disponibili in Registri applicazioni e servizi>Microsoft>Rete privata Microsoft Entra>Connettore>Amministratore.

1. Usare un record A nel Domain Name System (DNS) interno per l'indirizzo dell'applicazione, e non un CName.
2. Verificare nuovamente che all'host del connettore siano stati concessi i diritti di delega al Nome dell'entità servizio (SPN) dell'account di destinazione designato. e che l'opzione Usa un qualsiasi protocollo di autenticazione sia selezionata. Per altre informazioni, vedere l'articolo sulla configurazione dell'accesso SSO.
3. Verificare che in Microsoft Entra ID sia presente solo un'istanza del nome dell'entità servizio. eseguendo il comando setspn -x da un prompt dei comandi di qualsiasi host membro di dominio.
4. Verificare che sia applicato un criterio di dominio che limita la dimensione massima dei token Kerberos pubblicati. Questo criterio impedisce che il connettore riceva un token se il valore della dimensione è eccessivo.

Una traccia di rete che acquisisca gli scambi tra l'host del connettore e una delega vincolata Kerberos del dominio rappresenta quindi il successivo passaggio ideale per ottenere un livello maggiore di dettaglio sui problemi. Per altre informazioni, vedere il white paper di approfondimento sulla risoluzione dei problemi.

Se la creazione di ticket non presenta problemi, verrà visualizzato un evento nei log a indicare che l'autenticazione ha avuto esito negativo a causa di un codice 401 restituito dall'applicazione. Questo evento indica che l'applicazione di destinazione ha rifiutato il ticket. Passare alla fase successiva.

Applicazione di destinazione

Il consumer del ticket Kerberos fornito dal connettore. In questa fase si prevede che il connettore abbia inviato un ticket di servizio Kerberos al back-end, sotto forma di intestazione nella prima richiesta dell'applicazione.

1. Tramite l'URL interno dell'applicazione definito nel portale, confermare che l'applicazione sia accessibile direttamente dal browser nell'host del connettore. A questo punto sarà possibile eseguire l'accesso. I dettagli a questo proposito sono disponibili nella pagina di risoluzione dei problemi del connettore.

2. Verificare che l'autenticazione tra il browser e l'applicazione usi Kerberos.

3. Eseguire Strumenti di sviluppo (F12) in Internet Explorer oppure usare Fiddler dall'host del connettore. Passare all'applicazione usando l'URL interno. Ispezionare le intestazioni dell’autorizzazione offerta restituite nella risposta dell’applicazione per assicurarsi che siano presenti negotiate o Kerberos.

   • Il successivo BLOB Kerberos restituito nella risposta dal browser all'applicazione inizia con YII, e questa è una buona indicazione del fatto che Kerberos è in esecuzione. Microsoft NT LAN Manager (NTLM), d'altro canto, inizia sempre con TlRMTVNTUAAB, ovvero NTLM Security Support Provider (NTLMSSP) in caso di decodifica da Base64. Se TlRMTVNTUAAB è presente all'inizio del BLOB, Kerberos non è disponibile. Se TlRMTVNTUAABnon è visibile, Kerberos dovrebbe essere disponibile.

     Nota

     Se si usa Fiddler, questo metodo richiede la disabilitazione temporanea della protezione estesa sulla configurazione dell'applicazione in IIS.

     

   • Il BLOB nell'immagine non inizia con TIRMTVNTUAAB. In questo esempio pertanto Kerberos è disponibile, e il BLOB Kerberos non inizia con YII.

4. Rimuovere temporaneamente NTLM dall'elenco di provider nel sito di IIS. Accedere all'app direttamente da Internet Explorer nell'host del connettore. NTLM non è più presente nell'elenco dei provider, ed è possibile accedere all'applicazione solo tramite Kerberos. Se l'accesso non riesce, potrebbe esserci 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. Verificare che l'opzione Negotiate sia elencata nella parte superiore, con NTLM immediatamente sotto. Se viene visualizzata l'opzione Not Negotiate, Kerberos o Negotiate, o PKU2U, procedere solo se Kerberos funziona.

     

   • Con Kerberos e NTLM disponibili, disabilitare temporaneamente la preautenticazione per l'applicazione nel portale. Verificare che sia possibile accedervi da Internet tramite l'URL esterno. Viene richiesto di eseguire l'autenticazione. A tal fine, usare lo stesso account usato nel passaggio precedente. In caso contrario, si è verificato un problema con l'applicazione back-end e non con la delega vincolata Kerberos.

   • Riabilitare la preautenticazione nel portale. ed eseguire l'autenticazione tramite Azure cercando di connettersi all'applicazione tramite l'URL esterno. Se l'accesso SSO ha esito negativo, viene visualizzato un messaggio di errore non consentito nel browser e l'evento 13022 nel log:

     Il connettore di rete privata Microsoft Entra non riesce ad autenticare l'utente perché il server back-end risponde ai tentativi di autenticazione Kerberos con un errore HTTP 401.

     

   • Controllare l'applicazione IIS. Verificare che il pool di applicazioni sia configurato per l'uso dello stesso account con cui è stato configurato il nome dell'entità servizio in Microsoft Entra ID. Passare a IIS come mostrato nella figura seguente.

     

     Dopo aver stabilito l'identità, verificare che questo account venga configurato con il nome dell'entità servizio in questione. Un esempio è setspn –q http/spn.wacketywack.com. Nel prompt dei comandi immettere il testo seguente.

     

   • Controllare il nome dell'entità servizio definito in base alle impostazioni dell'applicazione nel portale. Verificare che lo stesso nome dell'entità servizio configurato nell'account Microsoft Entra di destinazione sia usato dal pool di applicazioni dell'applicazione.

   • Passare a IIS e selezionare l'opzione Editor di configurazione per l'applicazione. Passare a system.webServer/security/authentication/windowsAuthentication. Verificare che il valore UseAppPoolCredentials sia True.

     

     Modificare il valore in Vero. Rimuovere tutti i ticket Kerberos memorizzati nella cache dal server back-end usando il comando.

     Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
     

Oltre a risultare utile per migliorare le prestazioni delle operazioni Kerberos, l'abilitazione della modalità Kernel determina la decrittografia del ticket per il servizio richiesto con l'account del computer. Questo è anche noto come sistema locale, pertanto la sua impostazione su True interrompe la delega vincolata Kerberos quando l'applicazione è ospitata in più server in una farm.

• Come verifica aggiuntiva, disabilitare anche la protezione estesa. In alcune situazioni, la protezione estesa interrompe la delega vincolata Kerberos se abilitata in configurazioni specifiche, in cui un'applicazione viene pubblicata come sottocartella del sito Web predefinito. Tale applicazione è configurata soltanto per l'autenticazione anonima, lasciando le finestre di dialogo disattivate a indicare che gli oggetti figlio non erediteranno impostazioni attive. È consigliabile eseguire il test e quindi ripristinare questo valore su abilitata, laddove possibile.

  Questi controlli aggiuntivi dovrebbero consentire di iniziare a usare correttamente l'applicazione pubblicata. È possibile avviare i connettori aggiuntivi che sono anch'essi configurati per la delega. Per altre informazioni, leggere la procedura tecnica dettagliata relativa nella Guida completa alla risoluzione dei problemi del proxy dell’applicazione Microsoft Entra.

Se il problema persiste, contattare il supporto tecnico Microsoft creando un ticket direttamente nel portale

Altri scenari

Il proxy dell'applicazione Microsoft Entra richiede un ticket Kerberos prima dell'invio della richiesta a un'applicazione. Alcune applicazioni non apprezzano questo metodo di autenticazione. preferendo l'approccio più tradizionale delle negoziazioni. La prima richiesta è anonima, consentendo all'applicazione di rispondere con i tipi di autenticazione supportati tramite un codice 401. Questo tipo di negoziazione Kerberos può essere abilitato usando i passaggi descritti in questo documento: Delega vincolata Kerberos per l'accesso Single Sign-On.

L'autenticazione multi hop viene comunemente usata negli scenari in cui un'applicazione è a livelli. I livelli includono un back-end e un front-end. Nessuno dei due livelli richiede l'autenticazione. Ad esempio, SQL Server Reporting Services. Per ulteriori informazioni, vedere Come configurare la Delega vincolata Kerberos per le pagine proxy di registrazione Web.

Passaggi successivi

Configurare la delega vincolata Kerberos in un dominio gestito.