Introduzione a Microsoft Entra Kerberos

Microsoft Entra Kerberos è un protocollo di autenticazione nativo del cloud che collega scenari di identità ibrida abilitando l'accesso sicuro alle risorse cloud e locali. Estende le funzionalità Kerberos tradizionali nell'ecosistema Microsoft Entra, in modo che le organizzazioni possano modernizzare l'infrastruttura di gestione delle identità senza sacrificare la compatibilità con i sistemi legacy. Consente anche l'accesso Single Sign-On (SSO) facile alle risorse locali per gli utenti autenticati con credenziali moderne, ad esempio le chiavi di sicurezza Windows Hello for Business o FIDO2.

Microsoft Entra Kerberos è stato introdotto nel 2021 per colmare il divario tra i protocolli di autenticazione locali legacy e l'identità cloud moderna. In pratica, Microsoft Entra Kerberos trasforma Microsoft Entra ID in un Centro distribuzione chiavi basato sul cloud (KDC) per l'autenticazione Kerberos. A questa funzionalità consente a Microsoft Entra ID di emettere ticket Kerberos per gli utenti, estendendo l'autenticazione Kerberos tradizionale oltre i confini dell'Active Directory on-premises.

In uno scenario ibrido, in cui esistono account in Active Directory Domain Services locali e tali utenti vengono sincronizzati con Microsoft Entra ID, Microsoft Entra Kerberos svolge un ruolo fondamentale. Consente a questi utenti ibridi di eseguire l'autenticazione alle risorse cloud e locali usando Kerberos senza dover visualizzare direttamente i controller di dominio. Ad esempio, se un Microsoft Entra ID aggiunto Windows client accede a una condivisione file o a un'applicazione tramite Internet, Microsoft Entra ID può emettere i ticket Kerberos necessari per conto dell'ambiente Active Directory locale.

Per altre informazioni su Kerberos in Windows, vedere panoramica dell'autenticazione di Kerberos in Windows Server.

Microsoft Entra Kerberos funziona con identità ibride e identità solo cloud quando il servizio lo supporta.

Identità ibrida

Un'identità ibrida fa riferimento a un'identità utente esistente sia in Active Directory Domain Services locale che in Microsoft Entra ID. Queste identità vengono sincronizzate tramite strumenti come Microsoft Entra Connect, in modo che gli utenti possano accedere alle risorse locali e basate sul cloud usando un unico set di credenziali.

Questa configurazione consente di eseguire facilmente l'autenticazione e l'accesso Single Sign-On tra ambienti diversi. È ideale per le organizzazioni che vogliono passare al cloud mantenendo l'infrastruttura legacy.

Identità solo cloud (versione preliminare)

Un'identità esclusiva del cloud si riferisce a un account utente esistente solo in Microsoft Entra ID (in precedenza Azure AD) e che non ha un account corrispondente in un Active Directory locale.

Caratteristiche e vantaggi principali

Autenticazione ibrida senza problemi: Microsoft Entra Kerberos consente agli utenti i cui account risiedono in Servizi di dominio Active Directory locali e vengono sincronizzati con Microsoft Entra ID per l'autenticazione tra risorse cloud e locali. Riduce (e in alcuni casi elimina) la necessità di connettività diretta ai controller di dominio.

Ad esempio, quando un client Windows associato a Microsoft Entra ID accede a una condivisione di file o a un'applicazione attraverso Internet, Microsoft Entra ID può emettere i ticket Kerberos necessari come KDC associato alla risorsa.

Supporto delle identità solo cloud (anteprima): le identità solo cloud possono ora usare l'autenticazione Kerberos per carichi di lavoro come File di Azure senza richiedere Servizi di dominio Active Directory locali. Questa funzionalità è abilitata da Entra Kerberos, che funge da KDC basato sul cloud.

Enhanced security with modern credentials support: gli utenti possono eseguire l'accesso usando metodi senza password, ad esempio Windows Hello for Business o chiavi di sicurezza FIDO2, ma accedono ancora alle risorse locali con protezioni Kerberos. Questa capacità consente l'autenticazione a più fattori (MFA) e l'autenticazione senza password per ridurre i rischi associati al furto di password e agli attacchi di phishing.

Scambio sicuro di ticket: Microsoft Entra Kerberos utilizza un modello di scambio del Ticket Granting Ticket (TGT) per una sicurezza avanzata.

Scalable group memberships: Microsoft Entra Kerberos risolve le limitazioni di Kerberos tradizionali con appartenenze a gruppi di grandi dimensioni o dinamiche per migliorare l'affidabilità e l'esperienza utente. Negli scenari che coinvolgono gruppi di utenti di grandi dimensioni, le prestazioni vengono ottimizzate tramite la distribuzione automatica del carico in tutti i controller di dominio all'interno di un sito. Per le distribuzioni in ambienti Desktop virtuale Azure, è consigliabile assicurarsi che i controller di dominio sufficienti siano disponibili e geograficamente vicini all'ambiente, per mantenere la velocità di risposta.

Funzionamento di Microsoft Entra Kerberos

Negli scenari ibridi, Microsoft Entra Kerberos consente al tenant di Microsoft Entra ID di operare come area di autenticazione Kerberos dedicata insieme all'area di autenticazione Active Directory locale esistente. Quando un utente accede a un dispositivo Windows registrato a Microsoft Entra ID o in modalità ibrida, il dispositivo si autentica con Microsoft Entra ID e riceve un Primary Refresh Token (PRT).

Oltre al PRT, Microsoft Entra ID rilascia un TGT cloud per il realm KERBEROS.MICROSOFTONLINE.COM, usato per l'autenticazione alle risorse cloud. Viene rilasciato un TGT parziale separato per l'accesso alle risorse locali, come descritto più avanti in questo documento. In questo modello, Microsoft Entra ID funge da KDC per facilitare l'autenticazione senza problemi.

Scenari di identità solo cloud (anteprima)

Il supporto delle identità solo cloud per Entra Kerberos richiede un tenant di Microsoft Entra ID con Entra Kerberos abilitato e un dispositivo Windows 10/11 unito a Microsoft Entra.

Il supporto per Microsoft Entra ID con Entra Kerberos per le identità esclusivamente cloud consente agli host di sessione collegati a Entra di autenticarsi e accedere alle risorse cloud, come le condivisioni file di Azure, senza basarsi sull'infrastruttura di Active Directory tradizionale. Questa funzionalità è essenziale per le organizzazioni che adottano una strategia solo cloud, in quanto rimuove la necessità di controller di dominio mantenendo al tempo stesso la sicurezza di livello aziendale, il controllo di accesso e la crittografia.

Attualmente i carichi di lavoro supportati sono File di Azure, Desktop virtuale Azure e l'accesso di autenticazione Windows ad Istanza gestita di SQL di Azure.

Flusso di autenticazione

1. Autenticazione utente

L'utente accede a un dispositivo Windows che è unito a Microsoft Entra o ibrido.

L'autorità di sicurezza locale usa Cloud Authentication Provider (CloudAP) per eseguire l'autenticazione tramite OAuth per Microsoft Entra ID.

2. Rilascio di token

Al termine dell'autenticazione, Microsoft Entra ID genera un token di aggiornamento primario (PRT) contenente informazioni sull'utente e sul dispositivo. Insieme al PRT, Microsoft Entra ID rilascia un TGT cloud per il realm KERBEROS.MICROSOFTONLINE.COM.

Microsoft Entra ID genera anche un TGT (OnPremTgt) che contiene l'identificatore di sicurezza (SID) dell'utente, ma non dichiarazioni di gruppo. Questo TGT parziale non è sufficiente per l'accesso diretto alle risorse locali.

Rilascio del TGT nel cloud

Microsoft Entra ID funge da KDC per le risorse cloud rilasciando un TGT cloud al client quando appropriato. Il client riconosce il tenant Microsoft Entra ID come area di autenticazione Kerberos separata per le risorse cloud e il TGT viene archiviato nella cache dei ticket Kerberos del client. Il TGT cloud viene memorizzato nella cache in locale e può essere verificato usando il comando di PowerShell "klist cloud_debug".

TGT cloud che Microsoft Entra ID problemi:

• È per l'ambito KERBEROS.MICROSOFTONLINE.COM.
• Consente l'accesso a risorse basate sul cloud, ad esempio File di Azure, Azure SQL e altri servizi integrati con Microsoft Entra Kerberos.
• Contiene i dati di autorizzazione specifici per i servizi cloud e vengono usati direttamente per richiedere ticket di servizio Kerberos per le risorse cloud.
• Viene sempre generato quando un utente accede a un dispositivo Windows usando credenziali supportate, ad esempio Windows Hello for Business o FIDO2.
• Non ha alcuna dipendenza dai controller di dominio locali.

Rilascio OnPremTgt per l'accesso in sede

Questi prerequisiti si applicano:

• Gli utenti devono essere sincronizzati da Active Directory locale a Microsoft Entra ID tramite Microsoft Entra Connect.
• Un oggetto server Kerberos deve esistere in Active Directory locale e essere sincronizzato con Microsoft Entra ID. Questo oggetto consente a Microsoft Entra ID di emettere OnPremTgt che i controller di dominio locali possono riscattare.
• I dispositivi devono eseguire Windows 10 (2004 o versione successiva) o Windows 11.
• I dispositivi devono essere connessi a Microsoft Entra o aggiunti in modalità ibrida.
• È consigliabile Windows Hello for Business o metodi di autenticazione FIDO2 per un'integrazione ottimale.
• È necessario applicare patch ai controller di dominio locali per supportare Kerberos Cloud Trust.
• Verificare la linea di visuale tra i dispositivi client e i controller di dominio per lo scambio di ticket.

Se l'utente accede utilizzando un metodo senza password (ad esempio FIDO2 o Windows Hello for Business) su dispositivi con Windows 10 (2004 o versione successiva) o Windows 11, Microsoft Entra ID genera un OnPremTgt per l'utente nel dominio di Active Directory locale. Questo OnPremTgt contiene il SID dell'utente, ma non i dati di autorizzazione.

OnPremTgt che Microsoft Entra ID emette:

• Consente l'accesso alle risorse locali fungendo da ponte tra Microsoft Entra ID e Active Directory.
• Contiene dati limitati(ad esempio, SID dell'utente) e nessuna attestazione di gruppo. Non è sufficiente da solo per accedere alle risorse locali.
• Viene generato solo se l'ambiente è configurato per supportarlo. Ad esempio, si dispone di una configurazione ibrida delle identità e di un oggetto server Kerberos Microsoft Entra in Active Directory.
• Deve essere scambiato con un controller di dominio Active Directory locale per un TGT completo che include il SID dell'utente, il PAC completo (tutte le appartenenze ai gruppi), la chiave di sessione e altri dati di controllo di accesso. Il TGT completo viene quindi usato per accedere a risorse come condivisioni SMB (Server Message Block) o server SQL.

Il dsregcmd /status comando mostrerà il risultato per entrambi i TGT. Per altre informazioni, vedere Risolvere i problemi dei dispositivi usando il comando dsregcmd.

• OnPremTgt: impostare lo stato su SÌ se un ticket Kerberos cloud per accedere alle risorse locali è presente nel dispositivo per l'utente connesso.
• CloudTgt: impostare lo stato su SÌ se un ticket Kerberos cloud per accedere alle risorse cloud è presente nel dispositivo per l'utente connesso.

Microsoft Entra Kerberos TGT e controllo di accesso di Active Directory

Il possesso di un TGT Kerberos Microsoft Entra per il dominio Active Directory on-premises di un utente non concede automaticamente l'accesso a un TGT completo di Active Directory.

Microsoft Entra Kerberos utilizza la lista di autorizzazione e la lista di blocco dell'oggetto controller di dominio di sola lettura per controllare quali utenti possono ricevere TGT parziali da Microsoft Entra ID per l'accesso alle risorse on-premises. Questo meccanismo è fondamentale per limitare l'esposizione e l'applicazione dei limiti di sicurezza. Questo meccanismo è particolarmente critico negli ambienti ibridi in cui Microsoft Entra ID rilascia TGT parziali che devono essere riscattati con controller di dominio Active Directory locale per un TGT completo.

Per completare lo scambio, l'utente deve essere elencato nell'elenco di elementi consentiti nell'oggetto RODC e non nell'elenco di blocchi.

Durante il processo di scambio, un TGT parziale Microsoft Entra Kerberos viene convertito in un TGT completo di Active Directory. Microsoft Entra ID valuta gli elenchi per determinare l'idoneità all'accesso. Se l'utente si trova nell'elenco elementi consentiti, Microsoft Entra ID rilascia il TGT completo. Se l'utente si trova nell'elenco di blocchi, Microsoft Entra ID rifiuta la richiesta e l'autenticazione ha esito negativo.

Come procedura consigliata, impostare la configurazione predefinita su Nega. Concedere autorizzazioni esplicite Allow solo ai gruppi autorizzati a usare Microsoft Entra Kerberos.

Mapping del dominio

Il mapping degli ambiti è il meccanismo che consente ai client Windows di determinare quale ambito Kerberos contattare quando un utente accede a una risorsa. Questo meccanismo è particolarmente importante quando un'organizzazione usa sia Active Directory locale che Microsoft Entra ID nello stesso ambiente.

Windows usa lo spazio dei nomi del servizio (ad esempio, *.file.core.windows.net) per decidere se contattare Active Directory o Microsoft Entra ID per un ticket Kerberos. Poiché sia i servizi cloud che locali possono condividere lo stesso spazio dei nomi, Windows non possono distinguerli automaticamente.

Per risolvere questa situazione, gli amministratori configurano i mapping del nome host al reame Kerberos tramite:

• Criteri di gruppo: Configurazione del computer>Modelli amministrativi>Sistema>Kerberos>Definire i mapping dell'area di autenticazione da nome host a Kerberos
• Provider di servizi di configurazione dei criteri di Intune (CSP): Kerberos/HostToRealm

Una mappatura di esempio per contoso.com è .file.core.windows.net a KERBEROS.MICROSOFTONLINE.COM. Questo mapping indica a Windows di usare Microsoft Entra Kerberos per istanze di File di Azure specifiche, mentre per impostazione predefinita imposta gli altri su Active Directory on-premises.

Informazioni del tenant di Azure in Microsoft Entra Kerberos

Microsoft Entra ID funge da KDC per le risorse cloud. Gestisce configurazioni specifiche del tenant che guidano il modo in cui vengono emessi e convalidati i ticket Kerberos:

• Cloud TGT: Microsoft Entra ID emette questo TGT per il dominio KERBEROS.MICROSOFTONLINE.COM. Viene archiviato nella cache dei ticket Kerberos del client e usato per l'accesso alle risorse cloud.
• proxy KDC: questo protocollo instrada il traffico Kerberos in modo sicuro tramite Internet a Microsoft Entra ID. Questo routing consente ai client di ottenere ticket senza connettività diretta ai controller di dominio.
• Riconoscimento tenant di Azure: lo stack Kerberos usa il mapping del realm e l'ID tenant per convalidare il Cloud TGT ed emettere ticket di servizio.

3. Richiesta e rilascio di ticket di servizio

Per l'accesso client alle risorse locali (scenario ibrido):

1. Microsoft Entra ID genera un TGT parziale.
2. Il cliente contatta un controller di dominio Active Directory in sede per sostituire il TGT parziale con un TGT completo.
3. Il TGT completo viene usato per accedere a risorse locali come condivisioni SMB o server SQL.

Il client usa il TGT cloud per richiedere ticket di servizio per le risorse cloud. Non è necessaria alcuna interazione con Active Directory locale. Per l'accesso client alle risorse cloud:

1. Quando l'utente accede a un servizio (ad esempio, File di Azure), il client richiede un ticket di servizio da Microsoft Entra ID presentando il TGT.
2. Il client invia una richiesta di servizio di concessione ticket (TGS-REQ) a Microsoft Entra ID.
3. Kerberos identifica il servizio ( ad esempio , cifs/mystuff.file.core.windows.net) ed esegue il mapping del dominio a KERBEROS.MICROSOFTONLINE.COM. Il protocollo proxy KDC abilita la comunicazione Kerberos tramite Internet.
4. Microsoft Entra ID verifica il TGT cloud e l'identità dell'utente. Cerca anche il nome principale del servizio (SPN) richiesto per la risorsa File di Azure registrata in Microsoft Entra ID.
5. Microsoft Entra ID genera un ticket di servizio e lo crittografa usando la chiave dell'entità servizio. Microsoft Entra ID restituisce il ticket al client in una risposta al servizio di rilascio ticket (TGS-REP).
6. Lo stack Kerberos elabora il TGS-REP, estrae il ticket e genera una richiesta di applicazione (AP-REQ).
7. Il AP-REQ viene fornito a SMB, che lo include nella richiesta di File di Azure.
8. File di Azure decrittografa il ticket e concede l'accesso. FSLogix può ora leggere il profilo utente da File di Azure e caricare la sessione di Desktop virtuale Azure.

Per l'accesso client alle risorse cloud:

1. L'utente con identità solo cloud accede a una risorsa cloud, ad esempio, la condivisione di File di Azure.
2. Il client SMB richiede un ticket di servizio Kerberos per l'SPN della risorsa, ad esempio cifs/<storageaccount>.file.core.windows.net.
3. Entra Kerberos emette il ticket di servizio in base al TGT cloud. Il ticket include l'identità dell'utente Entra ID e le attestazioni di gruppo.
4. File di Azure convalida il ticket Kerberos rispetto a Entra ID. L'autorizzazione viene applicata usando i ruoli RBAC di Azure (ad esempio, Collaboratore per la condivisione SMB dei dati del file di archiviazione).
5. L'utente ottiene l'accesso alla risorsa se vengono soddisfatte le autorizzazioni RBAC. Non sono coinvolti ACL AD o NTFS locali. L'autorizzazione è completamente basata sul cloud.

Differenze principali rispetto a Kerberos tradizionale:

• Nessun KDC locale o Active Directory DS.
• Nessuna applicazione ACL NTFS; usa Azure RBAC.
• Ticket Kerberos emessi da Entra Kerberos nel cloud.

Riassunto

Scenarios

Usare Microsoft Entra Kerberos per l'autenticazione di Windows per accedere a Istanza gestita di SQL di Azure

L'autenticazione Kerberos per Microsoft Entra ID consente l'accesso a istanze gestite di Azure SQL tramite autenticazione di Windows. autenticazione di Windows per le istanze gestite consente ai clienti di spostare i servizi esistenti nel cloud mantenendo al tempo stesso un'esperienza utente senza problemi. Questa capacità fornisce la base per la modernizzazione dell'infrastruttura.

Per informazioni dettagliate, vedere Cos'è l'Autenticazione Windows per i principali di Microsoft Entra su Istanza gestita di SQL di Azure?.

Usare l'accesso SSO per accedere alle risorse locali usando le chiavi FIDO2

Microsoft Entra gli utenti Kerberos possono accedere a Windows usando credenziali moderne, ad esempio chiavi di sicurezza FIDO2, e quindi accedere alle risorse tradizionali basate su Active Directory.

Per informazioni dettagliate, vedere Abilitare l'accesso senza password con chiave di sicurezza alle risorse locali utilizzando Microsoft Entra ID.

Abilitare il Single Sign-On Kerberos per le risorse Kerberos di Active Directory locale e Microsoft Entra ID in Platform SSO

Insieme al Platform SSO PRT, Microsoft Entra emette TGT Kerberos sia locali che basati sul cloud. Questi TGT vengono quindi condivisi con lo stack Kerberos nativo in macOS attraverso il mapping TGT in Platform SSO.

Per informazioni dettagliate, consultare Abilitazione di Kerberos SSO per Active Directory locale e risorse Kerberos di Microsoft Entra ID in Platform SSO.

Archiviare i contenitori di profili con FSLogix per Desktop virtuale Azure

Per ospitare profili utente per desktop virtuali, è possibile archiviare i profili in una condivisione file Azure a cui si accede tramite Microsoft Entra Kerberos. Microsoft Entra Kerberos consente a Microsoft Entra ID di rilasciare i ticket Kerberos necessari per accedere alla condivisione file tramite il protocollo SMB standard del settore.

Per informazioni dettagliate, vedere Store FSLogix contenitori di profili in File di Azure usando Microsoft Entra ID in uno scenario ibrido.

Abilitare l'autenticazione di Kerberos di Microsoft Entra nei file di Azure

L'autenticazione Kerberos di Microsoft Entra consente alle identità ibride e alle identità cloud di accedere alle condivisioni file di Azure tramite l'autenticazione Kerberos. Questo scenario usa Microsoft Entra ID per rilasciare i ticket Kerberos necessari per accedere alla condivisione file tramite il protocollo SMB.

Per informazioni dettagliate, vedere Abilitare l'autenticazione Kerberos di Microsoft Entra per le identità ibride in File di Azure.

Considerazioni sulla sicurezza

• Microsoft Entra Kerberos non rilascia TGT parziali alle identità non sincronizzate con Microsoft Entra ID.
• Microsoft Entra Kerberos usa un modello di scambio TGT sicuro tramite il proxy KDC. Questo modello riduce al minimo l'esposizione ai controller di dominio e riduce la superficie di attacco.
• Gli amministratori possono configurare criteri di risoluzione dei gruppi per limitare i gruppi inclusi nei ticket Kerberos. Questi controlli sono essenziali per la gestione delle dimensioni dei ticket e la riduzione dell'esposizione ai dati di gruppo non necessari.
• È consigliabile mantenere una chiara separazione tra gli ambienti cloud e locali e non sincronizzare l'account sensibile krbtgt_AzureAD per evitare rischi di escalation dei privilegi. L'account krbtgt_AzureAD deve esistere solo in Entra ID, creato e gestito automaticamente dai servizi cloud di Microsoft.
• Usare l'elenco di autorizzazione e di blocco dell'oggetto RODC per controllare quali utenti possono ottenere TGT parziali da Microsoft Entra ID per l'accesso alle risorse locali.

Limitazioni e altre considerazioni

Supporto per le identità utente basate esclusivamente sul cloud (Anteprima)

Gli account utente esclusivamente cloud, gestiti in Microsoft Entra ID, sono supportati per l'autenticazione Kerberos da carichi di lavoro come File di Azure, Desktop virtuale Azure e l'autenticazione Windows per l'accesso a Istanza gestita di SQL di Azure.

Restrizioni del sistema operativo e dei dispositivi

Microsoft Entra Kerberos è supportato nei dispositivi Windows 10 (2004 o versione successiva) con registrazione a Microsoft Entra o con registrazione ibrida e nei dispositivi Windows 11. Alcune funzionalità dipendono da versioni e patch specifiche di Windows.

Requisiti di connettività di rete per la configurazione ACL

Gli utenti possono accedere alle condivisioni file di Azure tramite Internet senza una connettività diretta ai controller di dominio. Tuttavia, la configurazione degli elenchi di controllo di accesso (ACL) di Windows o delle autorizzazioni a livello file per le identità ibride richiede l'accesso alla rete senza impedimenti ai controller di dominio locali.

Nessun supporto multi-tenant o utenti esterni

Gli utenti guest business-to-business (B2B) o gli utenti di altri tenant Microsoft Entra non possono attualmente autenticarsi tramite Microsoft Entra Kerberos.

Scadenza password

Le password delle credenziali di servizio per gli account di archiviazione scadono ogni sei mesi e devono essere aggiornate per mantenere l'accesso.

Limiti di appartenenza ai gruppi

I ticket Kerberos hanno un vincolo di dimensione che limita il numero di SID di gruppo che è possibile includere. Il limite predefinito è 1.010 gruppi per ticket. Se si supera tale limite, vengono inclusi solo i primi 1.010. L'esclusione del resto può causare errori di accesso per gli utenti di grandi organizzazioni.

Incompatibilità MFA per l'autenticazione File di Azure

Microsoft Entra autenticazione Kerberos per le condivisioni file di Azure non supporta MFA. Le politiche di accesso condizionale di Microsoft Entra che applicano l'autenticazione a più fattori devono escludere l'applicazione del "storage account", altrimenti gli utenti riscontreranno errori di autenticazione.

Escludere File di Azure dai criteri di accesso condizionale che richiedono l'autenticazione a più fattori. È possibile eseguire questa attività definendo l'ambito dei criteri per escludere l'account di archiviazione o l'applicazione specifica che accede File di Azure.

Requisiti di sincronizzazione degli attributi

La corretta sincronizzazione degli attributi chiave degli utenti di Active Directory on-premises è essenziale per il corretto funzionamento di Kerberos di Microsoft Entra. Questi attributi includono onPremisesDomainName, onPremisesUserPrincipalNamee onPremisesSamAccountName.

Metodo Active Directory singolo per account Archiviazione di Azure

Per File di Azure'autenticazione basata sull'identità, è possibile abilitare un solo metodo Active Directory alla volta per ogni account di archiviazione. Questi metodi includono Microsoft Entra Kerberos, Active Directory Domain Services locale e Microsoft Entra Domain Services. Per passare da un metodo all'altro, è prima necessario disabilitare il metodo corrente.

Impostazioni di crittografia Kerberos

La crittografia dei ticket Kerberos con Microsoft Entra Kerberos usa esclusivamente AES-256. È possibile configurare separatamente la crittografia del canale SMB in base alle esigenze.

Introduzione a Microsoft Entra Kerberos

1. Per autenticare le identità ibride, è prima necessario configurare Microsoft Entra Connetti per sincronizzare gli utenti di Active Directory Domain Services locali con Microsoft Entra ID. Per informazioni dettagliate, vedere la guida all'installazione di Microsoft Entra Connect.

2. Configurare File di Azure o altri servizi per l'uso dell'autenticazione Kerberos di Microsoft Entra. Per istruzioni, vedere Abilitare l'autenticazione Kerberos di Microsoft Entra.

3. Assicurarsi che Windows client siano aggiornati e configurati per Microsoft Entra Kerberos.

4. Monitorare e ruotare le password dell'entità servizio in base alle esigenze.

5. Usare Microsoft Entra ID report e strumenti di monitoraggio per tenere traccia degli eventi di autenticazione.

Limite del SID di gruppo in Entra Kerberos (in anteprima)

I ticket Kerberos possono includere un massimo di 1.010 identificatori di sicurezza (SID) per i gruppi. Si tratta di un limite di specifiche Windows. Ora che Entra Kerberos supporta le identità solo cloud (oltre a supportare anche quelle ibride), i ticket devono includere sia i SID del gruppo locale sia i SID del gruppo cloud. Le aziende di grandi dimensioni hanno spesso utenti in centinaia o migliaia di gruppi, incluse le appartenenze annidate e dinamiche. Se i SID del gruppo combinato superano 1.010, il ticket Kerberos non può essere emesso e l'autenticazione non riesce. Ciò è particolarmente problematico per gli scenari di accesso SMB come File di Azure, in cui i controlli ACL NTFS dipendono dall'appartenenza completa al gruppo nel ticket.

Come soluzione a breve termine, le app che usano Entra Kerberos per le identità solo cloud possono aggiungere un tag nel manifesto applicativo. Quando il servizio Kerberos vede questo tag, riconosce che la richiesta coinvolge identità esclusivamente cloud. L'accesso e il rilascio del token PRT hanno successo; tuttavia, gli errori possono verificarsi al momento del ticket di servizio quando l'utente accede a una risorsa protetta da Kerberos e supera il limite di 1010 SID del gruppo.

Errori tipici dell'utente finale

Windows SMB/File di Azure - I tentativi di mapping/montaggio potrebbero non riuscire con errori SMB generici (ad esempio, l'errore di sistema 86 o 1327 può essere visualizzato in altri conflitti di criteri come MFA). - L'accesso può avere esito positivo per gli utenti di gruppi più piccoli, ma potrebbe avere esito intermittente per gli utenti fortemente raggruppati nello stesso tenant poiché l'utente ha superato il limite di 1010 SID per il gruppo.

Accesso all'account vs. accesso alle risorse - L'accesso e l'emissione del PRT hanno esito positivo; gli errori si verificano al momento del ticket di servizio (quando l'utente accede a una risorsa protetta Kerberos).

Voce del registro di accesso di Entra Sign-in - Errore 140011 - KerberosUsersGroupNumberExceeded nel registro di accesso di Entra Sign-in indica che il processo di emissione del ticket Kerberos non è riuscito perché l'appartenenza effettiva ai gruppi dell'utente ha superato il numero massimo consentito di Security Identifiers (SID) in un ticket Kerberos. L'amministratore deve ridurre le appartenenze ai gruppi per gli utenti interessati (in particolare i gruppi annidati/dinamici).

Come aggiornare l'attributo Tags nel file manifesto dell'applicazione

Opzione 1: Aggiornare i tag nel portale di amministrazione di Entra

1. Accedere a Interfaccia di amministrazione di Microsoft Entra o al ruolo di amministratore dell'applicazione cloud.
2. Passare a:
   • Entra ID → Registrazioni app → Selezionare l'applicazione.
3. Sotto Gestisci, fai clic su Manifest.
   • Nell'editor JSON individuare la proprietà tags e aggiungere "kdc_enable_cloud_group_sids".
4. Fare clic su Salva per applicare le modifiche.

Option 2: Aggiornare i tag con Microsoft API Graph (autorizzazioni: Application.ReadWrite.All)

Testo della richiesta

PATCH https://graph.microsoft.com/v1.0/applications/{applicationObjectId}
Content-Type: application/json
{
   "tags": [
           "kdc_enable_cloud_group_sids"
    ]
}

Opzione 3: Aggiornare i tag usando i cmdlet di PowerShell

1. Avviare PowerShell con privilegi di amministratore.

2. Installare e importare il SDK PowerShell di Microsoft Graph.

   Install-Module Microsoft.Graph -Scope CurrentUser
   Import-Module Microsoft.Graph.Authentication
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
   

3. Connettersi al tenant e accettare tutto.

   Connect-MGGraph -Scopes "Application.ReadWrite.All" -TenantId <tenantId>
   

4. Elencare l'attributo certificateUserIds di un determinato utente.

   Update-MgApplication -ApplicationId "<AppObjectId>" -Tags @("kdc_enable_cloud_group_sids")
   

Contenuti correlati

• Creare l'oggetto dominio attendibile
• Configurare i client per recuperare i ticket Kerberos
• Configurare l'oggetto Criteri di gruppo per Istanza gestita di SQL di Azure