Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra come risolvere i problemi di errore di autenticazione Kerberos quando un utente appartiene a molti gruppi.
Numero KB originale: 327825
Sintomi
Un utente che appartiene a un numero elevato di gruppi di sicurezza presenta problemi di autenticazione. Durante l'autenticazione, l'utente potrebbe visualizzare un messaggio come HTTP 400 - Richiesta non valida (intestazione richiesta troppo lunga) . L'utente presenta anche problemi di accesso alle risorse e le impostazioni di Criteri di gruppo dell'utente potrebbero non essere aggiornate correttamente.
Per altre informazioni sul contesto dell'errore, vedere Risposte HTTP 400 Bad Request (Request Header too long) alle richieste HTTP.
Note
In condizioni simili, l'autenticazione di Windows NTLM funziona come previsto. È possibile che il problema di autenticazione Kerberos non venga visualizzato a meno che non si analizzi il comportamento di Windows. In questi scenari, tuttavia, Windows potrebbe non essere in grado di aggiornare le impostazioni di Criteri di gruppo.
Questo comportamento si verifica in una delle versioni di Windows attualmente supportate. Per informazioni sulle versioni attualmente supportate di Windows, vedere la scheda dei fatti del ciclo di vita di Windows.
Causa
L'utente non può eseguire l'autenticazione perché il ticket compilato da Kerberos per rappresentare l'utente non è sufficientemente grande da contenere tutte le appartenenze ai gruppi dell'utente.
Come parte di Exchange del servizio di autenticazione, Windows compila un token per rappresentare l'utente ai fini dell'autorizzazione. Questo token (detto anche contesto di autorizzazione) include gli identificatori di sicurezza (SID) dell'utente e i SID di tutti i gruppi a cui appartiene l'utente. Include anche tutti i SID archiviati nell'attributo dell'account sIDHistory
utente. Kerberos archivia questo token nella struttura di dati Certificato attributo privilegio (PAC) nel Ticket-Getting Ticket (TGT) Kerberos. A partire da Windows Server 2012, Kerberos archivia anche il token nella struttura dei dati delle attestazioni di Active Directory (Dynamic Controllo di accesso) nel ticket Kerberos. Se l'utente è membro di un numero elevato di gruppi e se sono presenti molte attestazioni per l'utente o il dispositivo in uso, questi campi possono occupare molti spazi nel ticket.
Il token ha una dimensione massima fissa (MaxTokenSize
). I protocolli di trasporto, ad esempio RPC (Remote Procedure Call) e HTTP si basano sul MaxTokenSize
valore quando allocano buffer per le operazioni di autenticazione. MaxTokenSize
ha il valore predefinito seguente, a seconda della versione di Windows che compila il token:
- Windows Server 2008 R2 e versioni precedenti e Windows 7 e versioni precedenti: 12.000 byte
- Windows Server 2012 e versioni successive e Windows 8 e versioni successive: 48.000 byte
In genere, se l'utente appartiene a più di 120 gruppi universali, il valore predefinito MaxTokenSize
non crea un buffer sufficientemente grande per contenere le informazioni. L'utente non può eseguire l'autenticazione e può ricevere un messaggio di memoria insufficiente. Inoltre, Windows potrebbe non essere in grado di applicare le impostazioni di Criteri di gruppo per l'utente.
Note
Altri fattori influiscono anche sul numero massimo di gruppi. Ad esempio, i SID per i gruppi globali e locali di dominio hanno requisiti di spazio inferiori. Windows Server 2012 e versioni successive aggiungono informazioni sull'attestazione al ticket Kerberos e comprimono anche i SID delle risorse. Entrambe le funzionalità modificano i requisiti di spazio.
Risoluzione
Per risolvere questo problema, aggiornare il Registro di sistema in ogni computer che partecipa al processo di autenticazione Kerberos, inclusi i computer client. È consigliabile aggiornare tutti i sistemi basati su Windows, soprattutto se gli utenti devono accedere a più domini o foreste.
Importante
Se le modifiche al Registro di sistema vengono apportate in modo non corretto, possono verificarsi problemi gravi. Prima di modificarlo, eseguire il backup del Registro di sistema per il ripristino, in caso di problemi.
In ognuno di questi computer impostare la voce del MaxTokenSize
Registro di sistema su un valore maggiore. È possibile trovare questa voce nella HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
sottochiave. I computer devono essere riavviati dopo aver apportato questa modifica.
Per altre informazioni sulla determinazione di un nuovo valore per MaxTokenSize
, vedere la sezione Calcolo delle dimensioni massime del token di questo articolo.
Si consideri, ad esempio, un utente che usa un'applicazione Web che si basa su un client di SQL Server. Come parte del processo di autenticazione, il client SQL Server passa il token dell'utente a un database SQL Server back-end. In questo caso, è necessario configurare la MaxTokenSize
voce del Registro di sistema in ognuno dei computer seguenti:
- Computer client che esegue Internet Explorer
- Server Web che esegue IIS
- Computer client di SQL Server
- Computer di database di SQL Server
In Windows Server 2012 (e versioni successive), Windows può registrare un evento (ID evento 31) se la dimensione del token supera una determinata soglia. Per abilitare questo comportamento, è necessario configurare l'impostazione di Criteri di gruppo Configurazione computer\Modelli amministrativi\System\KDC\Warning per i ticket Kerberos di grandi dimensioni.
Calcolo delle dimensioni massime del token
Usare la formula seguente per calcolare le dimensioni del token generato da Windows per un determinato utente. Questo calcolo consente di determinare se è necessario modificare MaxTokenSize
.
TokenSize = 1200 + 40d + 8s
Per Windows Server 2012 (e versioni successive), questa formula definisce i relativi componenti come indicato di seguito:
- 1200. Valore di overhead stimato per un ticket Kerberos. Questo valore può variare, a seconda di fattori quali la lunghezza del nome di dominio DNS e la lunghezza del nome client.
- d. Somma dei valori seguenti:
- Numero di appartenenze a gruppi universali esterni al dominio dell'account dell'utente.
- Numero di SID archiviati nell'attributo dell'account
sIDHistory
. Questo valore conta le appartenenze ai gruppi e i SID utente.
- s. Somma dei valori seguenti:
- Numero di appartenenze a gruppi universali all'interno del dominio dell'account dell'utente.
- Numero di appartenenze nei gruppi locali di dominio.
- Numero di appartenenze nei gruppi globali.
Windows Server 2008 R2 e versioni precedenti usano la stessa formula. Tuttavia, queste versioni considerano il numero di appartenenze a gruppi locali di dominio come parte del valore d anziché del valore s .
Se si ha un MaxTokenSize
valore di 0x0000FFFF (64K), è possibile memorizzare nel buffer circa 1600 SID di classe d o circa 8000 SID di classe s. Tuttavia, un certo numero di altri fattori influisce sul valore che è possibile usare in modo sicuro per MaxTokenSize
, tra cui quanto segue:
Se si usa trusted per gli account di delega , ogni SID richiede il doppio dello spazio.
Se si dispone di più trust, configurare i trust per filtrare i SID. Questa configurazione riduce l'impatto delle dimensioni del ticket Kerberos.
Se si usa Windows Server 2012 o versione successiva, i fattori seguenti influiscono anche sui requisiti di spazio SID:
- È disponibile un nuovo schema per comprimere i SID nel PAC. Per altre informazioni, vedere Compressione SID della risorsa KDC. Questa funzionalità riduce le dimensioni necessarie per i SID nel ticket.
- Il Controllo di accesso dinamico aggiunge attestazioni di Active Directory al ticket, aumentando i requisiti di dimensione. Tuttavia, dopo aver distribuito le attestazioni con i file server Windows Server 2012, è possibile prevedere di eliminare gradualmente un numero significativo di gruppi che controllano l'accesso ai file. Questa riduzione può a sua volta ridurre le dimensioni necessarie nel ticket. Per altre informazioni, vedere Dynamic Controllo di accesso: Scenario Overview.For more information, see Dynamic Controllo di accesso: Scenario Overview.
Se Kerberos è stato configurato per l'uso della delega non vincolata, è necessario raddoppiare il
TokenSize
valore della formula per ottenere una stima valida diMaxTokenSize
.Importante
Nel 2019 Microsoft ha fornito aggiornamenti a Windows che hanno modificato la configurazione predefinita della delega non vincolata per Kerberos disabilitata. Per altre informazioni, vedere Aggiornamenti alla delega TGT tra trust in ingresso in Windows Server.
Poiché la compressione SID delle risorse è ampiamente usata e la delega non vincolata è deprecata,
MaxTokenSize
48000 o più grandi dovrebbero diventare sufficienti per tutti gli scenari.
Problemi noti che influiscono su MaxTokenSize
Il MaxTokenSize
valore di 48.000 byte deve essere sufficiente per la maggior parte delle implementazioni. Questo è il valore predefinito in Windows Server 2012 e versioni successive. Tuttavia, se si decide di usare un valore maggiore, esaminare i problemi noti in questa sezione.
Limite di dimensioni pari a 1.010 SID di gruppo per il token di accesso LSA
Questo problema è simile al fatto che un utente con troppe appartenenze a gruppi non può eseguire l'autenticazione, ma i calcoli e le condizioni che regolano il problema sono diversi. Ad esempio, l'utente può riscontrare questo problema durante l'uso dell'autenticazione Kerberos o dell'autenticazione NTLM di Windows. Per altre informazioni, vedere Accesso a un account utente membro di più di 1.010 gruppi potrebbe non riuscire in un computer basato su Windows Server.
Problema noto quando si usano valori di MaxTokenSize maggiori di 48.000
Per attenuare un vettore di attacco Denial of Service, Internet Information Server (IIS) usa una dimensione limitata del buffer delle richieste HTTP di 64 KB. Un ticket Kerberos che fa parte di una richiesta HTTP viene codificato come Base64 (6 bit espansi a 8 bit). Pertanto, il ticket Kerberos usa il 133% delle dimensioni originali. Pertanto, quando la dimensione massima del buffer è di 64 KB in IIS, il ticket Kerberos può usare 48.000 byte.
Se si imposta la
MaxTokenSize
voce del Registro di sistema su un valore maggiore di 48000 byte e lo spazio del buffer viene utilizzato per i SID, potrebbe verificarsi un errore IIS. Tuttavia, se si imposta la voce delMaxTokenSize
Registro di sistema su 48.000 byte e si usa lo spazio per SID e attestazioni, si verifica un errore Kerberos.Per altre informazioni sulle dimensioni del buffer IIS, vedere Come limitare le dimensioni dell'intestazione della trasmissione HTTP accettata da un client in Windows 2000.
Problemi noti quando si usano valori di MaxTokenSize maggiori di 65.535
Le versioni precedenti di questo articolo hanno illustrato i valori fino a 100.000 byte per
MaxTokenSize
. Tuttavia, è stato rilevato che le versioni di SMS Administrator presentano problemi quando ilMaxTokenSize
valore è di 100.000 byte o superiore.È stato inoltre rilevato che il protocollo IKE IPSEC non consente a un BLOB di sicurezza di diventare più grande di 66.536 byte e che si verifica un errore anche quando
MaxTokenSize
viene impostato su un valore maggiore.