Condividi tramite

Delega vincolata Kerberos per l'accesso Single Sign-On alle app tramite proxy applicativo

È possibile fornire l'accesso Single Sign-On per le applicazioni locali pubblicate mediante application proxy che sono protette con l'autenticazione integrata di Windows. Queste applicazioni richiedono un ticket Kerberos per l'accesso. Application proxy usa la delega vincolata Kerberos (KCD) per supportare queste applicazioni.

Per altre informazioni sull'accesso Single Sign-On (SSO), vedere Informazioni sull'accesso Single Sign-On.

È possibile abilitare l'accesso Single Sign-On alle applicazioni tramite l'autenticazione integrata di Windows (IWA) concedendo ai connettori di rete privata l'autorizzazione per rappresentare gli utenti in Active Directory. I connettori usano questa autorizzazione per inviare e ricevere token per loro conto.

Funzionamento di Single Sign-On con KCD

Il diagramma illustra il flusso quando un utente tenta di accedere a un'applicazione locale che usa LWA.

Diagramma del flusso di autenticazione di Microsoft Entra

  1. L'utente immette l'URL per accedere all'applicazione locale tramite application proxy.
  2. Il proxy di applicazione reindirizza la richiesta ai servizi di autenticazione di Microsoft Entra per la preautenticazione. A questo punto, Microsoft Entra ID applica tutti i criteri di autenticazione e autorizzazione applicabili, ad esempio l'autenticazione a più fattori. Se l'utente viene convalidato, Microsoft Entra ID crea un token e lo invia all'utente.
  3. L'utente passa il token ad application proxy.
  4. Il proxy dell'applicazione convalida il token e recupera il nome principale utente (UPN) da esso, quindi il connettore preleva l'UPN e il nome principale del servizio (SPN) tramite un canale sicuro con doppia autenticazione.
  5. Il Connettore esegue la negoziazione della delega vincolata Kerberos (KCD) con l'Active Directory locale, assumendo l'identità dell'utente per ottenere un token Kerberos per l'applicazione.
  6. Active Directory invia il token Kerberos per l'applicazione al connettore.
  7. Il connettore invia la richiesta originale al server dell'applicazione, usando il token Kerberos ricevuto da Active Directory.
  8. L'applicazione invia la risposta al connettore che viene quindi restituita al servizio application proxy e infine all'utente.

Prerequisiti

Prima di iniziare a usare SSO per le applicazioni IWA, verificare che l'ambiente sia pronto con le impostazioni e configurazioni seguenti:

Configurare Active Directory

La configurazione di Active Directory varia a seconda del fatto che la rete privata di applicazione e il server dell'applicazione si trovino nello stesso dominio o meno.

Connettore e server applicazione nello stesso dominio

  1. In Active Directory passare a Strumenti>Utenti e computer.

  2. Selezionare il server che esegue il connettore.

  3. Fare clic con il pulsante destro del mouse su Proprietà>Delega.

  4. Selezionare Computer attendibile per la delega solo ai servizi specificati.

  5. Selezionare Usa un qualsiasi protocollo di autenticazione.

  6. In Servizi ai quali l'account può presentare credenziali delegate aggiungere il valore per l'identità SPN del server applicazioni. L'impostazione consente al connettore di rete privata di rappresentare gli utenti in AD rispetto alle applicazioni definite nell'elenco.

    Schermata della finestra delle proprietà per Connector-SVR

Connettore e server di applicazione in domini diversi

  1. Per un elenco dei prerequisiti necessari per usare la delega vincolata Kerberos tra domini, vedere Delega vincolata Kerberos tra domini.

  2. Per abilitare la delega di autenticazione Kerberos dal proxy dell'applicazione (connettore), usare la PrincipalsAllowedToDelegateTo proprietà dell'account di servizio per l'applicazione web (webserviceaccount). Il server delle applicazioni viene eseguito in webserviceaccount, e il server di delega è connectorcomputeraccount. Eseguire i comandi seguenti in un controller di dominio (Windows Server 2012 R2 o versione successiva) nello stesso dominio di webserviceaccount. Usare nomi flat (non UPN) per entrambi gli account.

    Se il webserviceaccount è un account computer, usare questi comandi:

    $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com

Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount

    Se webserviceaccount è un account utente, usare questi comandi:

    $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com

Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount

Configurare il Single Sign-On

  1. Pubblicare l'applicazione seguendo le istruzioni contenute in Pubblicare le applicazioni con Application Proxy. Assicurarsi di selezionare Microsoft Entra ID come Metodo di autenticazione preliminare.

  2. Dopo che l'applicazione viene visualizzata nell'elenco delle applicazioni aziendali, selezionarla e selezionare Single Sign-On.

  3. Impostare la modalità Single Sign-On su Autenticazione integrata di Windows.

  4. Immettere l’ SPN dell'applicazione interna del server dell'applicazione. In questo esempio l'SPN per l'applicazione pubblicata è http/www.contoso.com. Il nome SPN deve trovarsi nell'elenco dei servizi a cui il connettore può presentare credenziali delegate.

  5. Scegliere l'identità di accesso delegato che il connettore userà per conto degli utenti. Per ulteriori informazioni, vedere Lavorare con identità locali e cloud diverse.

    Configurazione dell'applicazione avanzata

SSO per app non-Windows

Il flusso di delega Kerberos nell'application proxy di Microsoft Entra inizia quando Microsoft Entra autentica l'utente nel cloud. Quando la richiesta arriva in locale, il connettore della rete privata di Microsoft Entra rilascia un ticket Kerberos per conto dell'utente tramite l'interazione con Active Directory locale. Il processo viene definito Delegazione vincolata Kerberos (KCD).

Nella fase successiva, viene inviata una richiesta all'applicazione back-end con il ticket Kerberos.

Esistono diversi meccanismi che definiscono come inviare il ticket Kerberos in tali richieste. La maggior parte dei server non Windows prevede di riceverla sotto forma di token SPNEGO. Il meccanismo è supportato nel proxy dell'applicazione Microsoft Entra, ma è disabilitato per impostazione predefinita. Un connettore può essere configurato per SPNEGO o token Kerberos standard, ma non per entrambi.

Se si configura una macchina di connettori per SPNEGO, assicurarsi che tutti gli altri connettori in tale gruppo siano configurati anche con SPNEGO. Le applicazioni che prevedono un token Kerberos standard devono essere instradate tramite altri connettori non configurati per SPNEGO. Alcune applicazioni Web accettano entrambi i formati senza richiedere alcuna modifica alla configurazione.

Per abilitare SPNEGO:

  1. Aprire un prompt dei comandi come amministratore.

  2. Eseguire i comandi seguenti nei server del connettore che necessitano di SPNEGO.

    REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft Entra private network connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
net stop WAPCSvc & net start WAPCSvc

Le app non Windows usano generalmente nomi utente o nomi account SAM invece di indirizzi e-mail di dominio. Se questa situazione si applica alle applicazioni, è necessario configurare il campo identità di accesso delegato per connettere le identità cloud alle identità dell'applicazione.

Lavorare con diverse identità locali e cloud

Il proxy di applicazione presuppone che gli utenti abbiano la stessa identità nel cloud e in locale. Tuttavia, alcune organizzazioni devono usare ID alternativi per l'accesso a causa di criteri aziendali o requisiti dell'applicazione. È comunque possibile abilitare KCD per l'accesso Single Sign-On configurando un'identità di accesso delegato per ogni applicazione. Questa impostazione specifica l'identità da usare per l'accesso Single Sign-On.

Questa funzionalità consente alle organizzazioni di abilitare l'accesso SSO dal cloud alle app locali senza richiedere agli utenti di gestire nomi utente e password diversi. Gli scenari comuni includono:

  • Uso di più domini interni (ad esempio, joe@us.contoso.com, joe@eu.contoso.com) con un singolo dominio cloud (ad esempio, joe@contoso.com).
  • Presenza di nomi di dominio interni non indirizzabili (ad esempio, joe@contoso.usa) durante l'uso di nomi di dominio validi nel cloud.
  • Funzionamento senza nomi di dominio interni (ad esempio, joe).
  • Assegnazione di alias diversi per gli utenti in sede e nel cloud (ad esempio, joe-johns@contoso.com rispetto a joej@contoso.com).

Con il proxy dell'applicazione è possibile scegliere l'identità usata per ottenere il ticket Kerberos. Questa impostazione è configurata per applicazione e supporta i sistemi che richiedono formati non di posta elettronica o metodi di accesso alternativi.

Schermata del parametro dell'identità di accesso delegata

Se viene usata l'identità di accesso delegata, il valore potrebbe non essere univoco in tutti i domini o le foreste dell'organizzazione. Per evitare questo problema, pubblicare queste applicazioni due volte usando due gruppi di connettori diversi. Poiché ogni applicazione dispone di un pubblico di utenti diversi, è possibile unire i connettori a un altro dominio.

Se per l'identità di accesso viene usato il nome dell'account SAM locale , il computer che ospita il connettore deve essere aggiunto al dominio in cui si trova l'account utente.

Configurare Single Sign-On per diverse identità

  1. Configurare le impostazioni di Microsoft Entra Connect in modo che l'identità principale sia l'indirizzo e-mail (posta elettronica). La configurazione viene eseguita come parte del processo di personalizzazione modificando il campo Nome entità utente nelle impostazioni di sincronizzazione. Queste impostazioni determinano anche il modo in cui gli utenti accedono a Microsoft 365, ai computer Windows e a altre applicazioni che usano Microsoft Entra ID come archivio delle identità.
    Schermata di identificazione degli utenti - Elenco a discesa Nome principale utente

  2. Nelle impostazioni di configurazione dell'applicazione che si desidera modificare, selezionare l' Identità di accesso delegata da usare:

    • Nome principale utente (ad esempio joe@contoso.com)
    • Nome utente principale alternativo (ad esempio joed@contoso.local)
    • Parte del nome utente del nome principale utente (ad esempio joe)
    • Parte del nome utente dell'Alternate User Principal Name (ad esempio joed)
    • Nome account SAM locale (dipende dalla configurazione del controller di dominio)

Risoluzione dei problemi di accesso Single Sign-On per diverse identità

Se l'applicazione back-end risponde con risposte HTTP impreviste, avviare la risoluzione dei problemi controllando l'evento 24029 nell'evento di accesso alla sessione del proxy applicativo nella macchina del connettore. Il campo "utente" nei dettagli dell'evento mostra l'identità usata per la delega. Per abilitare i log di sessione, passare al Visualizzatore eventi, aprire il menu Visualizza e selezionare Mostra log analitici e di debug.

Passaggi successivi