Condividi tramite

Delega vincolata Kerberos per l'accesso Single Sign-On alle app con application proxy

  • Articolo

È 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

Questo diagramma illustra il flusso quando un utente tenta di accedere a un'applicazione locale che usa l'autenticazione integrata di Windows (IWA).

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. Application proxy convalida il token e recupera il nome dell'entità utente (UPN) da esso, quindi il connettore esegue il pull dell'UPN e il nome dell'entità servizio (SPN) tramite un canale sicuro con doppia autenticazione.
  5. Il connettore esegue la negoziazione della delega vincolata Kerberos con AD locale, rappresentando l'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. In questo modo il connettore di rete privata può rappresentare gli utenti in AD nei confronti delle applicazioni definite nell'elenco.

    Schermata della finestra delle proprietà per Connector-SVR

Connettore e server applicazione in domini differenti

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

  2. Usare la proprietà principalsallowedtodelegateto dell'account del servizio (computer o account utente di dominio dedicato) dell'applicazione Web per abilitare la delega di autenticazione Kerberos da application proxy (connettore). Il server dell'applicazione è in esecuzione nel contesto di webserviceaccount e il server delegante è connectorcomputeraccount. Eseguire i comandi seguenti in un controller di dominio (che esegue Windows Server 2012 R2 o versione successiva) nel 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 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. Quando l'applicazione viene visualizzata nell'elenco delle applicazioni aziendali, selezionarla e fare clic su 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. Questo nome SPN deve essere 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 altre informazioni, vedere Utilizzo dell'accesso Single Sign-On quando le identità cloud e locali non sono identiche.

    Configurazione dell'applicazione avanzata

Accesso Single Sign-On 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. Questo processo è definito come delega vincolata Kerberos.

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. Questo meccanismo è supportato in application proxy di 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 il token Kerberos standard devono essere indirizzate attraverso gli altri connettori che non sono 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. Dal prompt dei comandi, eseguire i comandi seguenti nei server del connettore che richiedono 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 dell'identità di accesso delegata in modo che connetta le identità del cloud alle identità delle applicazioni.

Utilizzo dell'accesso Single Sign-On quando le identità cloud e locali non sono identiche

Application proxy presuppone che gli utenti dispongano della stessa identità nel cloud e in locale. Tuttavia, in alcuni ambienti, a causa di criteri aziendali o delle dipendenze dell'applicazione, le organizzazioni potrebbero dover usare ID alternativi per l'accesso. In questi casi è comunque possibile usare la delega vincolata Kerberos per Single Sign-On. Configurare un'identità di accesso delegata per ogni applicazione in modo da specificare le identità da usare durante l'esecuzione del Single Sign-On.

Questa funzionalità consente a molte organizzazioni con diverse identità locali e cloud di disporre dell'accesso Single Sign-On dal cloud ad applicazioni locali senza richiedere agli utenti di immettere nomi utente e password diversi. Sono incluse organizzazioni che:

  • Hanno più domini internamente (joe@us.contoso.com, joe@eu.contoso.com) e un singolo dominio nel cloud (joe@contoso.com).
  • Hanno un nome di dominio non instradabile internamente (joe@contoso.usa) e un dominio valido nel cloud.
  • Non usano nomi di dominio internamente (joe).
  • Usano diversi alias locali e nel cloud. Ad esempio, joe-johns@contoso.com e joej@contoso.com

Con application proxy è possibile selezionare l'identità da usare per ottenere il ticket Kerberos. Questa impostazione viene configurata per ogni applicazione. Alcune di queste opzioni sono appropriate per i sistemi che non accettano il formato di indirizzo di posta elettronica, altre sono concepite per l'accesso alternativo.

Schermata del parametro dell'identità di accesso delegata

Se si usa l'identità di accesso delegata, il valore potrebbe non essere univoco per tutti i domini o tutte 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 il nome dell'account SAM locale viene usato per l'identità di accesso, 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). Ciò avviene come parte del processo di personalizzazione, modificando il campo Nome dell'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 dell'entità utente

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

    • Nome dell'entità utente (ad esempio joe@contoso.com)
    • Nome alternativo dell'entità utente (ad esempio joed@contoso.local)
    • Parte del nome utente del nome dell'entità utente (ad esempio joe)
    • Parte del nome utente del nome alternativo dell'entità utente (ad esempio joed)
    • Nome account SAM locale: in base alla configurazione del controller di dominio locale

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

Se si verifica un errore nel processo di accesso Single Sign-On, l'errore viene visualizzato nel log eventi del computer connettore, come illustrato in Risoluzione dei problemi. In alcuni casi, tuttavia, la richiesta viene inviata correttamente all'applicazione back-end mentre l'applicazione risponde in numerose altre risposte HTTP. Per la risoluzione di problemi di questo tipo, è consigliabile iniziare esaminando il numero di eventi 24029 sul computer connettore nel registro eventi di sessione di application proxy. L'identità utente usata per la delega viene visualizzata nel campo "utente" dei dettagli dell'evento. Per attivare il log della sessione, scegliere Visualizza registri analitici e di debug dal menu di visualizzazione del Visualizzatore eventi.

Passaggi successivi