Autenticazione a doppio hop kerberos senza vincoli con Microsoft Edge (Chromium)

Si applica a: Internet Information Services

Introduzione

La configurazione dell'autenticazione di Windows basata sul protocollo di autenticazione Kerberos può essere un'operazione complessa, soprattutto quando si gestiscono scenari come la delega dell'identità da un sito front-end a un servizio back-end nel contesto di IIS e ASP.NET. Seguire i passaggi di questo articolo per configurare la delega dei ticket di autenticazione e usare i servizi con un browser moderno, ad esempio Microsoft Edge versione 87 o successiva.

Questo articolo presuppone che si stia configurando un'architettura simile a quella rappresentata nel diagramma seguente:

• Il computer Workstation-Client1 fa parte della stessa directory attiva del server Web primario, denominato Primary-IIS-SRV e del server Web back-end, denominato Backend-Web-SRV.
• Gli utenti del computer Workstation-Client1 accederanno al computer usando l'account di Windows Active Directory.
• Verrà quindi avviato un browser (Microsoft Edge), si passerà a un sito Web che si trova in Web-Server, ovvero il nome alias usato per Primary-IIS-SRV, e si eseguirà l'autenticazione tramite autenticazione di Windows integrato tramite Kerberos.
• Il sito Web che si trova in Web-Server effettuerà chiamate HTTP usando le credenziali dell'utente autenticato per API-Server (alias per Backend-Web-SRV) per recuperare i dati dell'applicazione per conto degli utenti, usando la delega delle credenziali Kerberos.

La procedura seguente consente di risolvere questo scenario: la configurazione funziona con Internet Explorer, ma quando gli utenti adottano Microsoft Edge non possono più usare la funzionalità di delega delle credenziali. Per usare la delega delle credenziali Kerberos, vedere Risolvere prima gli errori Kerberos in Internet Explorer .

Delega vincolata o non vincolata

Nello scenario precedente, entrambe le configurazioni consentono agli utenti di delegare le credenziali dalla sessione utente nel computer Workstation-Client1 al server API back-end durante la connessione tramite il server Web front-end.

In una configurazione di delega Kerberos non vincolata, l'identità del pool di applicazioni viene eseguita in Web-Server ed è configurata in Active Directory come attendibile per la delega a qualsiasi servizio. L'account del pool di applicazioni in esecuzione in Web-Server può delegare le credenziali degli utenti autenticati del sito Web ospitato in tale server a qualsiasi altro servizio in Active Directory. Ad esempio, un server SMTP, un file server, un server di database, un altro server Web e così via. Questa operazione viene definita delega non vincolata perché l'account del pool di applicazioni dispone dell'autorizzazione (non vincolata) per delegare le credenziali a qualsiasi servizio che contatta.

In una configurazione di delega vincolata, l'account di Active Directory usato come identità del pool di applicazioni può delegare le credenziali degli utenti autenticati solo a un elenco di servizi autorizzati a delegare. Se l'applicazione Web che risiede nel server denominato Web-Server deve contattare anche un database e autenticarsi per conto dell'utente, è necessario aggiungere il nome dell'entità servizio (SPN) all'elenco dei servizi autorizzati.

La delega vincolata è più sicura rispetto alla delega non vincolata in base al principio dei privilegi minimi. A un'applicazione vengono concessi i diritti necessari per funzionare e nulla di più, mentre la delega non vincolata consente a un'applicazione di contattare le risorse che non deve contattare per conto dell'utente.

Come sapere se il ticket Kerberos ottenuto sul client da inviare al Web-Server usa la delega vincolata o non vincolata?

Usare lo strumento di comando klist presente in Windows per elencare la cache dei ticket Kerberos dal computer client (Workstation-Client1 nel diagramma precedente). Cercare un ticket denominato HTTP/<Nome del server> Web. Nota: <il nome del server> Web è il nome SPN del servizio a cui si vuole contattare e a cui si vuole eseguire l'autenticazione tramite Kerberos. Il ticket contiene anche alcuni flag. Due di essi sono di interesse: forwardable e ok_as_delegate.

• Il primo flag, forwardable, indica che il KDC (centro di distribuzione chiavi) può emettere un nuovo ticket con una nuova maschera di rete, se necessario. Ciò consente a un utente di accedere a un sistema remoto e al sistema remoto di ottenere un nuovo ticket per conto dell'utente per accedere a un altro sistema back-end come se l'utente avesse eseguito l'accesso al sistema remoto in locale.

• Il secondo flag ok_as_delegate indica che l'account del servizio in cui l'utente sta tentando di eseguire l'autenticazione (nel caso del diagramma precedente, l'account del pool di applicazioni del pool di applicazioni IIS che ospita l'applicazione Web) è considerato attendibile per la delega non vincolata.

Se questi servizi usano la delega non vincolata, i ticket nel computer client contengono i ok_as_delegate flag e forwardable . Nella maggior parte dei casi, quando viene configurata la delega vincolata, i ticket non contengono il ok_as_delegate flag ma contengono il forwardable flag .

Perché la delega non vincolata funziona in Internet Explorer e non in Microsoft Edge?

Quando si tenta di eseguire l'autenticazione a un sito Web usando l'autenticazione basata su Kerberos, il browser chiama un'API Di Windows per configurare il contesto di autenticazione. L'API in questione è InitializeSecurityContext. Questa API potrebbe ricevere una serie di flag per indicare se il browser consente il delegatable ticket ricevuto dall'utente. Il ticket è contrassegnato come delegatable perché il servizio a cui l'utente sta tentando di eseguire l'autenticazione ha il diritto di delegare le credenziali in modo non vincolato. Ciò non significa tuttavia che l'applicazione che tenta di eseguire l'autenticazione (in questo caso il browser) deve usare questa capacità.

Per impostazione predefinita, Internet Explorer passa il flag a InitializeSecurityContext, che indica che se il ticket può essere delegato, deve esserlo. Microsoft Edge della versione 87 e successive non passa il flag solo perché InitializeSecurityContext il ticket è contrassegnato con il ok_as_delegate flag . Non è consigliabile usare la delega non vincolata nelle applicazioni perché offre alle applicazioni più privilegi del necessario. Le applicazioni possono delegare l'identità dell'utente a qualsiasi altro servizio nel dominio e autenticarsi come utente, operazione non necessaria per la maggior parte delle applicazioni che usano la delega delle credenziali. Le applicazioni devono contattare solo i servizi nell'elenco specificato durante la configurazione della delega vincolata.

Per impostazione predefinita, Microsoft Edge funziona con la delega vincolata, in cui il sito Web IIS in esecuzione in Web-Server ha solo il diritto di contattare il sito API back-end ospitato in API-Server, come illustrato nella configurazione dell'account di identità del pool di applicazioni da Active Directory elencato di seguito:

Abilitare Edge-Chromium per l'uso con la delega non vincolata in Active Directory

Ai fini della compatibilità, se è necessario gestire un'applicazione usando la delega non vincolata tramite Kerberos, abilitare Microsoft Edge per consentire la delega dei ticket. I passaggi seguenti sono descritti in dettaglio nelle sezioni seguenti di questo articolo:

1. Installare i modelli amministrativi per Criteri di gruppo archivio centrale in Active Directory (se non è già presente).
2. Installare i modelli amministrativi di Microsoft Edge.
3. Creare un nuovo oggetto Criteri di gruppo.
4. Modificare la configurazione del Criteri di gruppo per consentire la delega non vincolata durante l'autenticazione ai server.
5. (Facoltativo) Controllare se Microsoft Edge usa i flag di delega corretti.

Passaggio 1: Installare i modelli amministrativi per Active Directory

1. Scaricare i modelli da Modelli amministrativi (admx) (per Windows Server 2019).

2. Scaricare il programma di installazione ed estrarre il contenuto in una cartella di propria scelta. È sufficiente estrarlo nel percorso predefinito specificato del pacchetto, ovvero C:\Programmi (x86)\Microsoft Criteri di gruppo\Aggiornamento di Windows 10 (ottobre 2018) (1809) v2\PolicyDefinitions.

3. Dopo aver decomprimeto il pacchetto, individuare la cartella Sysvol nel controller di dominio. Il percorso della cartella è C:\Windows\SYSVOL\sysvol\. All'interno della cartella Sysvol è presente una cartella con lo stesso nome del nome di Active Directory (nell'esempio qui Oddessy.local). Da qui passare alla cartella Criteri . Se non esiste, creare una cartella denominata Definizioni dei criteri, come illustrato di seguito:

   

4. Copiare il contenuto della cartella PolicyDefinitions (che è stata estratta dal programma di installazione nella cartella PolicyDefinitions ) creata all'interno del dominio nella cartella sysvol del controller di dominio.

   Nota

   Anche i file estratti dal programma di installazione contengono contenuto localizzato. Per risparmiare spazio, trasferire i file localizzati solo per le lingue desiderate. Ad esempio, la cartella denominata fr-FR contiene tutto il contenuto localizzato in francese.

5. Al termine del trasferimento, verificare che i modelli siano disponibili in Active Directory. A tale scopo, aprire lo snap-in Gestione Criteri di gruppo di Microsoft Management Console (premere Windows+R e quindi digitare gpmc.msc per avviare). All'interno di Gestione Criteri di gruppo individuare un oggetto Criteri di gruppo e modificarlo.

   

   Come illustrato nello screenshot precedente, nel nodo Configurazione computer sono presenti un nodo Criteri e un nodo Modelli amministrativi .

Passaggio 2: Installare i modelli amministrativi di Microsoft Edge

Anche se è possibile avere i modelli amministrativi dei criteri nel controller di dominio da cui iniziare, sarà comunque necessario installare i file dei criteri di Microsoft Edge per avere accesso ai criteri destinati all'abilitazione della delega non vincolata a doppio hop tramite questo browser. Per installare i file dei criteri di Microsoft Edge, seguire questa procedura:

1. Passare al sito di download di Microsoft Edge per le aziende.

2. Selezionare la versione da scaricare dall'elenco a discesa canale/versione . È consigliabile usare la versione stabile più recente.

3. Selezionare la compilazione desiderata dall'elenco a discesa compilazione e infine il sistema operativo di destinazione dall'elenco a discesa della piattaforma . Una volta effettuata la selezione, verranno visualizzati altri due pulsanti (un pulsante e un collegamento).

   

4. Fare clic su GET POLICY FILES e accettare il contratto di licenza per scaricare il file denominato MicrosoftEdgePolicyTemplates.cab. Questo file contiene i file di definizione dei criteri per Microsoft Edge.

5. Fare doppio clic sul file per esplorare il contenuto (archivio ZIP con lo stesso nome).

6. Estrarre il contenuto dell'archivio ZIP in una cartella del disco locale. Il contenuto estratto conterrà una cartella denominata Windows in cui si troverà una sottocartella denominata Admx. Questo conterrà i modelli amministrativi e le relative versioni localizzate (dovrebbero essere necessari in una lingua diversa dall'inglese).

   

7. Trasferire i file con estensione admx all'interno della stessa cartella nella directory Sysvol in cui sono stati trasferiti i modelli amministrativi del precedente (nell'esempio precedente: C:\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

8. Aprire il Criteri di gruppo Editor Active Directory e selezionare un oggetto Criteri di gruppo esistente per la modifica per verificare la presenza dei modelli di Microsoft Edge appena trasferiti. Questi si troveranno in una cartella denominata Microsoft Edge che si trova sotto la cartella Modelli amministrativi nella visualizzazione struttura ad albero:

   

Passaggio 3: Creare un nuovo oggetto Criteri di gruppo

Ecco come creare un nuovo oggetto Criteri di gruppo usando lo snap-in MMC di Active Directory Criteri di gruppo Manager:

1. Premere il tasto Windows+R per aprire il menu Esegui nel controller di dominio.
2. Digitare Gpmc.msc per aprire Microsoft Management Console e caricare lo snap-in Gestione Criteri di gruppo Active Directory.
3. Individuare il nodo oggetti Criteri di gruppo nella visualizzazione albero della console e fare clic con il pulsante destro del mouse sul nodo per aprire il menu di scelta rapida.
4. Selezionare la voce di menu Nuovo , immettere il nome dei criteri di gruppo da creare e quindi fare clic su OK.

Passaggio 4: Modificare la configurazione del Criteri di gruppo per consentire la delega non vincolata durante l'autenticazione ai server

Il passaggio finale consiste nell'abilitare i criteri che consentono al browser Microsoft Edge di passare il ok_as_delegate flag alla chiamata api InitializeSecurityContext quando si esegue l'autenticazione tramite Kerberos a un sito Web abilitato per Windows Integrato. Se non si sa se il browser Microsoft Edge usa Kerberos per l'autenticazione (e non NTLM), vedere Risolvere gli errori Kerberos in Internet Explorer.

Nella Criteri di gruppo Editor Di Active Directory selezionare l'oggetto Criteri di gruppo che verrà applicato ai computer all'interno di Active Directory da cui si intende consentire agli utenti finali di eseguire l'autenticazione tramite l'autenticazione Kerberos e delegare le credenziali ai servizi back-end tramite delega non vincolata. I criteri che abiliteranno la delega non vincolata da Microsoft Edge si trovano nella cartella di autenticazione Http dei modelli di Microsoft Edge , come illustrato di seguito:

Usare questa impostazione per configurare un elenco di server per i quali è consentita la delega dei ticket Kerberos.

Nota

È necessario specificare un elenco di server. Nell'esempio usato all'inizio di questo articolo è necessario aggiungere il nome del server Web-Server all'elenco per consentire all'applicazione Web Web-Server front-end di delegare le credenziali al server API back-end.

Dopo aver applicato l'oggetto Criteri di gruppo di modifica ai computer client all'interno del dominio, passare alla pagina di autenticazione test in Pagine di diagnostica per la risoluzione dei problemi dell'autenticazione integrata di Windows e scaricare la pagina whoami.aspx dal repository ASP.net Samples in GitHub. Verrà restituita un'impostazione ImpersonationLevel di Delegate anziché Impersonate per segnalare che la delega delle credenziali è ora consentita.

Per verificare se i criteri sono stati applicati correttamente nella workstation client, aprire una nuova scheda di Microsoft Edge e digitare edge://policy.

Il AuthNegotiateDelegateAllowlist criterio deve essere impostato per indicare i valori dei nomi di server per i quali Microsoft Edge è autorizzato a eseguire la delega dei ticket Kerberos. Se il criterio non viene visualizzato nell'elenco, non è stato distribuito o è stato distribuito nei computer sbagliati.

Passaggio 5 (facoltativo): verificare se Microsoft Edge usa i flag di delega corretti

Ecco il passaggio di risoluzione dei problemi/controllo facoltativo.

Dopo aver configurato e distribuito i criteri, è necessario eseguire i passaggi seguenti per verificare se Microsoft Edge sta passando i flag di delega corretti a IntializeSecurityContext. I passaggi usano strumenti già integrati in Microsoft Edge o disponibili come Servizi online.

1. Usare la funzionalità di registrazione disponibile in Microsoft Edge per registrare le operazioni eseguite dal browser quando si richiede un sito Web. Per abilitare la registrazione:

   1. Aprire una nuova finestra di Microsoft Edge e digitare edge://net-export/.

   2. Usare l'opzione Includi cookie e credenziali durante la traccia. Senza questa opzione, i dati a livello di traccia di autenticazione verranno omessi.

      

   3. Fare clic sul pulsante Avvia registrazione su disco e specificare il nome del file con cui si vuole salvare la traccia.

   4. Aprire un'altra scheda di Microsoft Edge, passare al sito Web in cui si desidera eseguire autenticazione di Windows integrate tramite Microsoft Edge.

   5. Dopo aver provato a eseguire l'autenticazione, tornare alla scheda precedente in cui è stata abilitata la traccia e fare clic sul pulsante Interrompi registrazione . L'interfaccia di traccia indicherà dove è stato scritto il file contenente la traccia.

2. Usare il file JSON contenente la traccia per visualizzare i parametri passati dal browser alla funzione durante il InitializeSecurityContext tentativo di autenticazione. Per analizzare la traccia, usare il netlog_viewer.

3. All'interno della traccia analizzata è presente un registro eventi simile al seguente:

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   Questo log mostra che:

   • AUTH_LIBRARY_INIT_SEC_CTX indica che il browser chiama la InitializeSecurityContext funzione.
   • "delegated":false significa che il ticket non deve essere delegato anche se il ticket è contrassegnato come delegatable.
   • "mutual":false significa che il client (browser) non richiede che il server esegua anche l'autenticazione al client e ne dimostri l'identità. Solo il client deve eseguire l'autenticazione nel server per dimostrare la propria identità.
   • HTTP/web-server.odessy.local è il nome SPN usato dal browser quando si effettua la chiamata di autenticazione.

Ulteriori informazioni

Pagine di diagnostica per la risoluzione dei problemi dell'autenticazione integrata di Windows