Delega vincolata Kerberos per l'accesso Single Sign-On (SSO) alle app con il proxy dell'applicazione

  • Articolo

È possibile fornire l'accesso Single Sign-On per le applicazioni locali pubblicate tramite proxy di applicazione protette con autenticazione di Windows integrate. Queste applicazioni richiedono un ticket Kerberos per l'accesso. Il proxy dell'applicazione usa la delega vincolata Kerberos (KCD) per supportare queste applicazioni.

Per altre informazioni sull'accesso Single Sign-On (SSO), vedere Che cos'è l'accesso Single Sign-On?.

È possibile abilitare l'accesso Single Sign-On alle applicazioni usando autenticazione di Windows integrata (IWA) concedendo ai connettori di rete privati in Active Directory l'autorizzazione per rappresentare gli utenti. 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 LWA.

Diagramma del flusso di autenticazione di Microsoft Entra

  1. L'utente immette l'URL per accedere all'applicazione locale tramite il proxy dell'applicazione.
  2. Il proxy dell'applicazione reindirizza la richiesta ai servizi di autenticazione Di Microsoft Entra per preautenticare. 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 al proxy dell'applicazione.
  4. Il proxy dell'applicazione convalida il token e recupera il nome dell'entità utente (UPN) da esso, quindi il Connessione or esegue il pull dell'UPN e il nome dell'entità servizio (SPN) tramite un canale protetto autenticato dualmente.
  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 Connessione or, che viene quindi restituita al servizio proxy dell'applicazione 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 che il connettore di rete privata e il server applicazioni 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 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. Ciò 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 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 principalsallowedtodelegateto proprietà dell'account del servizio (computer o account utente di dominio dedicato) dell'applicazione Web per abilitare la delega dell'autenticazione Kerberos dal proxy dell'applicazione (connettore). Il server applicazioni è in esecuzione nel contesto di webserviceaccount e il server di delega è 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.

    webserviceaccount Se è 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

    webserviceaccount Se è 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 in base alle istruzioni descritte in Pubblicare applicazioni con il proxy dell'applicazione. Assicurarsi di selezionare Microsoft Entra ID come metodo di preautenticazione.

  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 Integrated autenticazione di Windows.

  4. Immettere l’ SPN dell'applicazione interna del server dell'applicazione. In questo esempio, il nome 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 Uso di identità locali e cloud diverse.

    Configurazione dell'applicazione avanzata

Accesso Single Sign-On per app non Windows

Il flusso di delega Kerberos nel proxy dell'applicazione Microsoft Entra viene avviato quando Microsoft Entra autentica l'utente nel cloud. Quando la richiesta arriva in locale, il connettore di rete privata Microsoft Entra emette un ticket Kerberos per conto dell'utente interagendo con l'istanza locale di Active Directory. 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 nel proxy dell'applicazione Microsoft Entra, ma è disabilitato per impostazione predefinita. Un connettore può essere configurato per SPNEGO o token Kerberos standard, ma non 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 eseguito 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

Il proxy di applicazione presuppone che gli utenti abbiano esattamente la stessa identità nel cloud e in locale. In alcuni ambienti, tuttavia, a causa di criteri aziendali o dipendenze dell'applicazione, le organizzazioni potrebbero dover usare ID alternativi per l'accesso. In questi casi, è comunque possibile usare KCD per l'accesso 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).
  • Usare alias diversi in locale e nel cloud. Ad esempio, joe-johns@contoso.com e joej@contoso.com

Con il proxy dell'applicazione è 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 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 Connessione in modo che l'identità principale sia l'indirizzo di posta elettronica (posta). 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, computer Windows e 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 nome utente del nome dell'entità utente alternativo (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 risolvere questi casi, è consigliabile iniziare esaminando il numero di evento 24029 nel computer connettore nel registro eventi della sessione del proxy di applicazione. 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