Usare Kerberos per l'accesso Single Sign-On (SSO) alle risorse con Microsoft Entra Private Access

Fornire l'accesso Single Sign-On per le risorse locali pubblicate tramite Accesso privato di Microsoft Entra. Accesso privato di Microsoft Entra usa Kerberos per supportare queste risorse. Opzionalmente, utilizzare la fiducia Kerberos nel cloud di Windows Hello for Business per consentire l'accesso Single Sign-On agli utenti.

Prerequisiti

Prima di iniziare a usare il Single Sign-On, assicurati che l'ambiente sia pronto.

• Una foresta di Active Directory. La guida utilizza un nome di dominio di un dominio forestale che può essere risolto pubblicamente. Tuttavia, un dominio disponibile pubblicamente non è un requisito.
• Hai abilitato il profilo di inoltro di Microsoft Entra Accesso privato.
• La versione più recente del connettore di Accesso privato di Microsoft Entra è installata su un server Windows con accesso ai controller di dominio.
• L'ultima versione del client di Accesso sicuro globale. Per ulteriori informazioni sul client, consultare Clienti di Global Secure Access.
• Per i server che eseguono Active Directory è installata una versione supportata di Windows Server.

Pubblicare risorse da usare con l'accesso Single Sign-On

Per testare l'accesso Single Sign-On, creare una nuova applicazione aziendale che pubblichi una condivisione di file. L'uso di un'applicazione aziendale per pubblicare la condivisione di file consente di assegnare criteri di accesso condizionale alla risorsa e di applicare controlli di sicurezza aggiuntivi, come l'autenticazione a più fattori.

1. Accedi a Microsoft Entra come almeno un Amministratore delle applicazioni .
2. Passare ad Accesso globale sicuro>Applicazioni>Applicazioni aziendali.
3. Selezionare Nuova applicazione.
4. Aggiungere un nuovo segmento di app con l'IP del file server usando la porta 445/TCP e successivamente selezionare Salva. Il protocollo SMB (Server Message Block) usa la porta.
5. Aprire l'applicazione aziendale creata e selezionare Utenti e gruppi per assegnare l'accesso alla risorsa.

Dispositivi aggiunti a Microsoft Entra ID: SSO basato su password

Non è richiesta alcuna configurazione aggiuntiva rispetto a quanto indicato in questa guida se gli utenti usano le password per accedere a Windows.

I dispositivi aggiunti a Microsoft Entra ID si basano sul dominio di Active Directory e sulle informazioni utente sincronizzate tramite Microsoft Entra ID Connect. Il localizzatore del controller di dominio di Windows individua i controller di dominio grazie alla sincronizzazione. Il User Principal Name (UPN) dell’utente e la password vengono usati per richiedere un ticket di concessione di ticket Kerberos (TGT). Per ulteriori informazioni, consultare Come funziona l'accesso Single Sign-On alle risorse locali nei dispositivi aggiunti a Microsoft Entra.

Dispositivi collegati a Microsoft Entra ID e dispositivi collegati in modo ibrido a Microsoft Entra ID: autentificazione Single Sign-On di Windows Hello for Business

È necessaria una configurazione aggiuntiva rispetto a questa guida per Windows Hello for Business.

Si raccomanda la distribuzione del trust Kerberos in un cloud ibrido con Microsoft Entra ID. I dispositivi che usano l'attendibilità Kerberos basata su cloud ottengono un ticket TGT usato per l'accesso singolo. Per ulteriori informazioni sull'attendibilità Kerberos cloud, consultare Abilitare l'accesso senza password con chiave di sicurezza alle risorse locali usando Microsoft Entra ID.

Per distribuire l'attendibilità cloud di Kerberos per Windows Hello for Business con Active Directory locale.

1. Crea l'oggetto server Kerberos di Microsoft Entra ID. Per informazioni su come creare l'oggetto, consultare Installare il modulo AzureADHybridAuthenticationManagement.
2. Abilitare l'attendibilità WHfB cloud sui dispositivi usando Intune o criteri di gruppo. Per informazioni su come abilitare WHfB, consultare la Guida alla distribuzione dell'attendibilità Kerberos Cloud.

Pubblicare i controller di dominio

I controller di dominio devono essere pubblicati per permettere ai client di ottenere i ticket Kerberos. I ticket sono necessari per l'accesso Single Sign-On alle risorse locali.

Come minimo, è necessario pubblicare tutti i controller di dominio configurati nel sito di Active Directory in cui sono installati i connettori di Accesso privato. Ad esempio, se i connettori di Accesso privato si trovano nel data center di Brisbane, è necessario pubblicare tutti i controller di dominio presenti nel data center di Brisbane.

Le porte del controller di dominio sono necessarie per abilitare l'accesso Single Sign-On alle risorse locali.

Porto	Protocollo	Scopo
88	Protocollo UDP (User Datagram Protocol) /Transmission Control Protocol (TCP)	Kerberos
123	UDP	NTP (Network Time Protocol)
135	UDP/TCP	Operazioni tra controller di dominio e operazioni da client a controller di dominio
389	UDP/TCP	LDAP Server
445	UDP/TCP	Replicazione, autenticazione utente e computer, Criteri di gruppo
464	UDP/TCP	Richiesta di modifica della password
636	TCP	LDAP con SSL
3268	TCP	Catalogo globale
3269	TCP	Catalogo globale sicuro
49152-65535	UDP/TCP	Porte effimere

Nota

La guida è incentrata sull'abilitazione dell'accesso Single Sign-On alle risorse locali ed esclude la configurazione necessaria per consentire ai client Windows aggiunti a un dominio di eseguire operazioni di dominio (modifica della password, Criteri di gruppo e così via). Per altre informazioni sui requisiti delle porte di rete di Windows, incluso il supporto per le versioni legacy di Windows Server, vedere Panoramica del servizio e requisiti delle porte di rete per Windows

1. Accedi a Microsoft Entra come almeno un Amministratore delle applicazioni .
2. Passare ad Accesso globale sicuro>Applicazioni>Applicazioni aziendali.
3. Selezionare Nuova applicazione per creare una nuova applicazione per pubblicare i controller di dominio.
4. Selezionare Aggiungi segmento di applicazione e quindi aggiungere tutti gli indirizzi IP dei controller di dominio o i nomi di dominio completi (FQDN) e le porte in base alla tabella. Devono essere pubblicati solo i controller di dominio nel sito di Active Directory in cui si trovano i connettori di accesso privato.

Nota

Assicurati di non utilizzare nomi di dominio completi (FQDN) con caratteri jolly per pubblicare i controller di dominio; invece, aggiungi gli indirizzi IP o i FQDN specifici.

Dopo aver creato l'applicazione aziendale, tornare all'app e selezionare Utenti e gruppi. Aggiungere tutti gli utenti sincronizzati da Active Directory.

Pubblicare suffissi DNS

Configurare il DNS privato in modo che i client di Accesso sicuro globale possano risolvere i nomi DNS privati. I nomi DNS privati sono necessari per l'accesso Single Sign-On. I client li usano per accedere alle risorse locali pubblicate. Per ulteriori informazioni su DNS privato con Accesso Rapido, vedere how-to-configure-quick-access.md#add-private-dns-suffixes.

1. Passa ad Accesso globale sicuro>Applicazioni>Accesso rapido.
2. Selezionare la scheda DNS privato e quindi selezionare Abilita DNS privato.
3. Selezionare Aggiungi suffisso DNS. Aggiungere almeno i suffissi di primo livello delle foreste di Active Directory che ospitano utenti sincronizzati con Microsoft Entra ID.
4. Seleziona Salva.

Come usare l'accesso Single Sign-On Kerberos per accedere a una condivisione file SMB

Questo diagramma illustra come funziona Accesso privato Microsoft Entra quando si tenta di accedere a una condivisione file SMB da un dispositivo Windows configurato con Windows Hello for Business + Cloud Trust. In questo esempio l'amministratore ha configurato l'accesso rapido DNS privato e due app aziendali, una per i controller di dominio e una per la condivisione file SMB.

Passo	Descrizione
Un	L'utente tenta di accedere alla condivisione file SMB tramite FQDN. Il client GSA intercetta il traffico e lo tunnela verso SSE Edge. I criteri di autorizzazione in Microsoft Entra ID vengono valutati e applicati, ad esempio se l'utente viene assegnato all'applicazione e all'accesso condizionale. Dopo che l'utente è stato autorizzato, Microsoft Entra ID rilascia un token per l'applicazione SMB Enterprise. Il traffico viene autorizzato per proseguire verso il servizio Accesso privato insieme al token di accesso dell'applicazione. Il servizio Accesso privato convalida il token di accesso e la connessione viene instradata verso il servizio backend di Accesso privato. La connessione viene quindi gestita dal Private Network Connector.
B	Il connettore di rete privata esegue una query DNS per identificare l'indirizzo IP del server di destinazione. Il servizio DNS nella rete privata invia la risposta. Il connettore di rete privata tenta di accedere alla condivisione file SMB di destinazione che richiede quindi l'autenticazione Kerberos.
C	Il client genera una query DNS SRV per individuare i controller di dominio. La fase A viene ripetuta, intercettando la query DNS e autorizzando l'utente per l'applicazione "Accesso Rapido". Il connettore di rete privata invia la query DNS SRV alla rete privata. Il servizio DNS invia la risposta DNS al client tramite il connettore di rete privata.
D	Il dispositivo Windows richiede un TGT parziale (detto anche Cloud TGT) da Microsoft Entra ID (se non ne ha già uno). Microsoft Entra ID rilascia un TGT parziale.
E	Windows avvia una connessione del localizzatore di controller di dominio sulla porta UDP 389 con ogni controller di dominio elencato nella risposta DNS dalla fase C. La fase A viene ripetuta, intercettando il traffico del localizzatore di controller di dominio e autorizzando l'utente per l'applicazione Enterprise che pubblica i controller di dominio locali. Il connettore di rete privata invia il traffico del DC locator a ogni controller di dominio. Le risposte vengono inoltrate al client. Windows seleziona e memorizza nella cache il controller di dominio con la risposta più veloce.
F	Il cliente scambia il TGT parziale per un TGT completo. Il TGT completo viene quindi usato per richiedere e ricevere un TGS per la condivisione file SMB.
G	Il client presenta il TGS alla condivisione file SMB. La condivisione file SMB convalida il TGS. Viene concesso l'accesso alla condivisione file.

Risoluzione dei problemi

I dispositivi aggiunti a Microsoft Entra ID che usano l'autenticazione della password si basano sugli attributi sincronizzati da Microsoft Entra ID Connect. Assicurarsi che gli attributi onPremisesDomainName, onPremisesUserPrincipalNamee onPremisesSamAccountName abbiano i valori corretti. Usare Graph Explorer e PowerShell per controllare i valori.

Se questi valori non sono presenti, controllare le impostazioni di sincronizzazione di Microsoft Entra ID Connect e verificare che questi attributi siano sincronizzati. Per altre informazioni sulla sincronizzazione degli attributi, vedere Sincronizzazione Microsoft Entra Connect: Attributi sincronizzati con Microsoft Entra ID.

Se si usa Windows Hello for Business per accedere, eseguire i comandi da un prompt dei comandi senza privilegi di amministratore. dsregcmd /status

Verificare che gli attributi abbiano YES come valori.

PRT deve essere presente. Per altre informazioni su PRT, vedere Risolvere i problemi dei token di aggiornamento primari nei dispositivi Windows.

OnPremTgt : SÌ indica che Entra Kerberos è configurato correttamente e all'utente è stato emesso un TGT parziale per l'SSO alle risorse locali. Per altre informazioni sulla configurazione dell'attendibilità Kerberos cloud, vedere Accesso tramite chiave di sicurezza senza password alle risorse locali.

Eseguire il comando klist.

klist cloud_debug

Verificare che il Cloud Primary (Hybrid logon) TGT available: campo abbia un valore pari a 1.

Eseguire il comando nltest.

nltest /dsgetdc:contoso /keylist /kdc

Verificare che il localizzatore di controller di dominio restituisca un controller di dominio che partecipa alle operazioni di trust Kerberos nel cloud. Il Controller di Dominio restituito deve avere il flag klist.

Come evitare la memorizzazione nella cache negativa Kerberos nei computer Windows

Kerberos è il metodo di autenticazione preferito per i servizi in Windows che verificano le identità utente o host. La memorizzazione nella cache negativa di Kerberos causa un ritardo nei ticket di Kerberos.

La memorizzazione nella cache negativa Kerberos si verifica nei dispositivi Windows in cui è installato il client Accesso sicuro globale. Il client GSA tenta di connettersi al controller di dominio più vicino per il ticket Kerberos, ma la richiesta ha esito negativo perché il client GSA non è ancora connesso o il controller di dominio non è raggiungibile in quel momento. Quando la richiesta ha esito negativo, il client non tenta di connettersi di nuovo al controller di dominio, immediatamente, perché FarKdcTimeout l'ora predefinita nel registro è impostata su 10 minuti. Anche se il client GSA può essere connesso prima di questo tempo predefinito di 10 minuti, il client GSA mantiene la voce di cache negativa e considera il processo di individuazione del controller di dominio come un fallimento. Una volta completato il tempo predefinito di 10 minuti, il client GSA esegue una query per il controller di dominio con il ticket Kerberos e la connessione ha esito positivo.

Per attenuare questo problema, è possibile modificare il tempo FarKdcTimeout predefinito nel registro o scaricare manualmente la cache Kerberos istantaneamente ogni volta che il client GSA viene riavviato.

Opzione 1: Modificare il tempo predefinito di FarKdcTimeout nel registro

Se si esegue Windows, è possibile modificare i parametri Kerberos per risolvere i problemi di autenticazione Kerberos o per testare il protocollo Kerberos.

Importante

In questa sezione, metodo o attività viene illustrata la procedura per modificare il Registro di sistema. Se, tuttavia, si modifica il Registro di sistema in modo errato, possono verificarsi gravi problemi. Pertanto, assicurarsi di osservare attentamente la procedura seguente. Per una maggiore protezione, eseguire il backup del Registro di sistema prima di modificarlo. Successivamente, è possibile ripristinare il Registro di sistema se si verifica un problema. Per ulteriori informazioni su come eseguire il backup e il ripristino del Registro di sistema, vedi Come eseguire il backup e il ripristino del Registro di sistema in Windows.

Voci di registro e valori nel registro sotto la chiave Parametri

Le voci di registro elencate in questa sezione devono essere aggiunte alla seguente sottochiave di registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Nota

Se la Parameters chiave non è elencata in Kerberos, è necessario crearla.

Modificare la seguenteFarKdcTimeout voce di registro

• Voce: FarKdcTimeout
• Tipo: REG_DWORD
• Valore predefinito: 0 (minutes)

Si tratta del valore di timeout usato per invalidare un controller di dominio da un sito diverso nella cache del controller di dominio.

Opzione 2: Rimuovere manualmente la cache Kerberos

Se si sceglie di rimuovere manualmente la cache Kerberos, questo passaggio dovrà essere completato ogni volta che il client GSA viene riavviato.

Aprire un prompt dei comandi come amministratore ed eseguire il seguente comando: KLIST PURGE_BIND

Passaggi successivi

• Client di accesso globale sicuro