Usare Kerberos per l'accesso Single Sign-On (SSO) alle risorse con Accesso privato di Microsoft Entra
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. Facoltativamente, usare l'attendibilità Kerberos cloud di Windows Hello for Business per abilitare l'accesso Single Sign-On per gli utenti.
Prerequisiti
Prima di iniziare a usare l'accesso Single Sign-On, assicurarsi che l'ambiente sia pronto.
- Una foresta di Active Directory. La guida usa un nome di dominio della foresta che può essere disponibile pubblicamente. Tuttavia, un dominio disponibile pubblicamente non è un requisito.
- È stato abilitato il profilo di inoltro di Accesso privato di Microsoft Entra.
- 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 Client di Accesso sicuro globale.
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.
- Accedi a Microsoft Entra come almeno un Amministratore delle applicazioni .
- Passare ad Accesso globale sicuro>Applicazioni>Applicazioni aziendali.
- Selezionare Nuova applicazione.
- Aggiungere un nuovo segmento di app con l'IP del file server usando la porta
445/TCPe successivamente selezionare Salva. Il protocollo SMB (Server Message Block) usa la porta. - 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 nome dell'entità utente (UPN) e la password vengono usati per richiedere un ticket di concessione Kerberos aggiornato (TGT). Per ulteriori informazioni, consultare Come funziona l'accesso Single Sign-On alle risorse locali nei dispositivi aggiunti a Microsoft Entra.
Dispositivi aggiunti a Microsoft Entra ID e dispositivi aggiunti a Microsoft Entra ID ibrido: accesso Single Sign-On di Windows Hello for Business
È necessaria una configurazione aggiuntiva rispetto a questa guida per Windows Hello for Business.
È consigliata la distribuzione di attendibilità Kerberos del cloud ibrido con Microsoft Entra ID. I dispositivi che usano l'attendibilità Kerberos cloud ottengono un ticket TGT usato per l'accesso Single Sign-On. 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à Kerberos cloud di Windows Hello for Business con Active Directory locale.
- Creare l'oggetto server Kerberos di Microsoft Entra ID. Per informazioni su come creare l'oggetto, consultare Installare il modulo AzureADHybridAuthenticationManagement.
- Abilitare l'attendibilità WHfB cloud sui dispositivi usando criteri di gruppo o Intune. Per informazioni su come abilitare WHfB, consultare Guida alla distribuzione dell'attendibilità Kerberos cloud.
Pubblicare controller di dominio
I controller di dominio devono essere pubblicati affinché i client possano 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.
| Porta | Protocollo | Scopo |
|---|---|---|
| 88 | User Datagram Protocol (UDP) / Transmission Control Protocol (TCP) | Kerberos |
| 389 | UDP | DC locator |
| 464 | UDP/TCP | Richiesta di modifica della password |
| 123 | UDP | Sincronizzazione dell'ora |
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).
- Accedere a Microsoft Entra come almeno un Amministratore delle Applicazioni.
- Passare ad Accesso globale sicuro>Applicazioni>Applicazioni aziendali.
- Selezionare Nuova applicazione per creare una nuova applicazione per pubblicare i controller di dominio.
- 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
Assicurarsi di non usare FQDN con caratteri jolly per pubblicare i controller di dominio, ma aggiungere gli indirizzi IP o i nomi di dominio completi 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 altre informazioni su DNS privato con Accesso rapido, vedere how-to-configure-quick-access.md#add-private-dns-suffixes.
- Passa ad Accesso globale sicuro>Applicazioni>Accesso rapido.
- Selezionare la scheda DNS privato e quindi selezionare Abilita DNS privato.
- Selezionare Aggiungi suffisso DNS. Aggiungere almeno i suffissi di primo livello delle foreste di Active Directory che ospitano utenti sincronizzati con Microsoft Entra ID.
- 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.
| Procedi | Descrizione |
|---|---|
| A | 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 rilasciato per continuare con il servizio Accesso privato insieme al token di accesso dell'applicazione. Il servizio Accesso privato convalida il token di accesso e la connessione viene negoziata al servizio back-end accesso privato. La connessione viene quindi negoziata al connettore di rete privata. |
| G | 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. |
| A | 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 genera 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 del 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 localizzatore del controller di dominio 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 client 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 non specificato.
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 l'utente ha emesso un TGT parziale per l'accesso 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 è un partecipante delle operazioni di attendibilità Kerberos 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 Kerberos causa un ritardo nei ticket 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 ritiene che il processo di individuazione del controller di dominio sia un errore. 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 e valori di registro nella 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