Crescita del token Kerberos: MaxTokenSize e gruppi

Che cos'è la crescita del token Kerberos?

La diagnosi della crescita del token Kerberos e di MaxTokenSize parte da una distinzione: il numero di persone in un gruppo è diverso dal numero di SID di gruppo trasportati per una persona. La proliferazione dei gruppi può diventare un problema di disponibilità dell'autenticazione, ma una segnalazione di gruppo numeroso, da sola, non permette di diagnosticarlo. Un'indagine utile collega l'identità interessata, il servizio che non funziona, il contesto di autorizzazione e i limiti lungo il percorso di autenticazione di quel servizio.

Una pulizia di emergenza introduce un secondo problema. Rimuovere le appartenenze finché un'applicazione torna a funzionare modifica l'accesso senza stabilire quali autorizzazioni o restrizioni siano state rimosse. Alcune rimozioni riducono privilegi superflui; altre interrompono attività necessarie. Una rimozione può anche indebolire un controllo se l'appartenenza forniva una restrizione. L'esito di sicurezza dipende dal ruolo effettivo del gruppo, non dall'accorciamento dell'elenco delle appartenenze.

Questa guida considera la nidificazione circolare e i gruppi predefiniti modificati come segnali da esaminare nell'ambito dell'indagine. Non presenta un'interruzione osservata o un incidente di sicurezza misurato. L'obiettivo è una correzione che ripristini il flusso di lavoro interessato preservando gli accessi e i dinieghi approvati.

Come funziona: PAC, MaxTokenSize e limiti distinti

Il TGT Kerberos trasporta dati di autorizzazione nel proprio Privilege Attribute Certificate (PAC): SID dell'utente, dei gruppi e di sIDHistory. Anche le attestazioni e la compressione dei SID influiscono sullo spazio richiesto. Contano i byte risultanti; il numero di membri diretti è una misura diversa. Microsoft KB327825 spiega questo meccanismo.

KB837361 documenta l'impostazione del Registro di sistema MaxTokenSize:

La sezione dei problemi noti di KB327825 identifica separatamente un limite del token di accesso LSA di 1 010 SID di gruppo, che riguarda Kerberos o NTLM. Aumentare MaxTokenSize non elimina questo limite distinto. KB327825, problemi noti.

KB938118 indica 65 535 byte come valore massimo consentito, ma sconsiglia valori superiori a 48 000 perché la codifica HTTP Base64 espande i dati di autenticazione. Considerate il massimo consentito e un'impostazione operativa adeguata come decisioni separate. Aumentare un valore del Registro di sistema non elimina tutti i vincoli a valle.

La nidificazione circolare è un problema di grafi

Supponiamo che il gruppo A contenga il gruppo B e che il gruppo B contenga il gruppo A. Un attraversamento personalizzato che rivisita i nodi senza tenerne traccia può entrare in un ciclo o contare visite ripetute. È una conseguenza algoritmica, non un'affermazione su un comportamento osservato del KDC o di PowerShell. Tornare allo stesso gruppo non crea un nuovo SID univoco a ogni visita.

Conservate le relazioni dirette tra gruppi durante l'indagine su un ciclo. Una componente fortemente connessa (SCC) identifica un insieme di gruppi che possono raggiungersi reciprocamente; la topologia aiuta il revisore a scegliere la relazione da rimuovere. Una segnalazione di ciclo non dimostra che il PAC di un utente superi MaxTokenSize. Il ciclo e le appartenenze effettive eccessive possono coesistere, ma richiedono prove distinte.

La nidificazione pericolosa dei gruppi in Active Directory spiega come l'ereditarietà nascosta crei un percorso verso Tier 0 e perché la correzione debba identificare la relazione di gruppo che concede quel privilegio. Applicate questa revisione dei percorsi quando semplificate le appartenenze, affinché una correzione della disponibilità preservi anche il confine di privilegio previsto.

Sintomi per servizio e scenario di modifica di emergenza

Microsoft documenta HTTP 400 con un'intestazione di richiesta troppo grande, errori di accesso alle risorse e problemi di aggiornamento dei criteri di gruppo dell'utente. Il suo esempio client/IIS/SQL mostra la rilevanza delle macchine partecipanti per la diagnosi. KB327825, sintomi e risoluzione.

Usate la tabella seguente come piano d'indagine. Sono domande da verificare, non ulteriori firme di errore o prove che Kerberos non funzioni in modo casuale.

Se lo stesso utente riesce a usare un servizio ma non un altro, conservate entrambi i casi. Confrontate i percorsi effettivi prima di modificare i gruppi. Il caso riuscito è una prova diagnostica utile, ma non identifica quale limite si applichi al caso non riuscito. Evitate di sostituire questo confronto con un'affermazione generica di crescita intermittente del token.

Come rimuovere un gruppo può rimuovere una restrizione

Considerate un esempio condizionale su una workstation Windows 10/11 coperta dalla documentazione Microsoft sul diniego di accesso al computer dalla rete. Un gruppo di sicurezza dedicato fornisce SeDenyNetworkLogonRight. L'impostazione si trova in Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Microsoft documenta che questo diniego Deny prevale sulla corrispondente autorizzazione Allow di accesso alla rete e che le modifiche alle assegnazioni si applicano all'accesso successivo.

Supponiamo ora che un operatore rimuova l'utente da quel gruppo soltanto per ridurre le appartenenze. Se questo era l'unico percorso dell'utente verso Deny e rimane un Allow, il contesto di autorizzazione successivo perde quella restrizione. È un'inferenza condizionale dal comportamento documentato dei criteri, non un rapporto su un incidente. Non dimostra che ogni condivisione o file sia ora accessibile: occorre ancora controllare le altre ACL e i dinieghi. Verificate l'applicabilità prima di estendere questo esempio di workstation ad altri sistemi.

La documentazione Microsoft sui gruppi di sicurezza spiega che i gruppi possono fornire diritti utente oltre alle autorizzazioni sulle risorse. Prima di rimuovere una relazione o un membro, registrate entrambi i ruoli. Il nome di un gruppo, da solo, non basta per decidere se la rimozione riduca il privilegio, interrompa un accesso necessario o elimini una restrizione.

La deriva degli accessi privilegiati in Active Directory spiega come le eccezioni temporanee senza responsabili, scadenza e riconvalida possano ricreare diritti tramite gruppi e ACL. Usate la stessa disciplina di riferimento per le correzioni urgenti, soprattutto quando un flusso di lavoro non funzionante induce a concedere un accesso compensativo.

Rilevamento: raccogliere appartenenze, percorsi e contesto degli avvisi

Passaggio 1: creare un registro per ogni servizio interessato

Registrate l'utente, le versioni client e server, il servizio/SPN, il MaxTokenSize effettivo di ogni partecipante, la popolazione di gruppi/SID, sIDHistory, le attestazioni o il contesto di delega, l'errore esatto e qualsiasi avviso pertinente. Conservate le prove prima di modificare. Distinguete un errore osservato da una stima, una segnalazione sullo stato della directory e una nuova verifica riuscita.

L'Event ID 31 può segnalare una soglia configurata per ticket grandi su Windows Server 2012 e successivi. Abilitatelo tramite Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets. Non è una prova del superamento di MaxTokenSize; correlatelo al servizio che non funziona. KB327825, risoluzione.

Registrate la soglia effettiva dell'avviso e se quel criterio è abilitato. Il passaggio della fonte non fornisce una soglia numerica universale. L'assenza dell'avviso non è un risultato che convalida l'account.

Passaggio 2: inventariare i gruppi dell'entità di sicurezza

Il comando seguente è l'esempio 2 di Get-ADPrincipalGroupMembership, citato come comando documentato. Questi comandi non sono stati eseguiti in un ambiente AD per questo articolo; sostituite l'identità di esempio con un account risolto nel vostro ambito.

Get-ADPrincipalGroupMembership -Identity Administrator

Il cmdlet richiede un catalogo globale. Microsoft documenta ResourceContextServer per cercare gruppi locali in un altro dominio. Controllate il contesto della risorsa invece di presumere che il dominio dell'account descriva tutto il percorso del servizio. Gli oggetti gruppo restituiti supportano un inventario; non misurano i byte del ticket.

Passaggio 3: preservare le relazioni dirette prima di appiattire i risultati

Questa query di appartenenza diretta usa i parametri documentati di Get-ADGroupMember:

Get-ADGroupMember -Identity "Enterprise Admins"

Per confronto, l'esempio 4 di Microsoft include membri raggiunti tramite gruppi figlio:

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

Microsoft descrive l'output ricorsivo come i membri terminali della gerarchia. Conservate separatamente le relazioni dirette per spiegare un percorso o un ciclo. Un output appiattito non può spiegare da solo quale relazione fornisca un diritto. La documentazione identifica anche una limitazione per i membri in un'altra foresta senza Active Directory Web Service.

Per una vista transitiva mirata dei SID, Microsoft documenta l'attributo calcolato tokenGroups (attributo Token-Groups), recuperato con una query LDAP con ambito BASE sull'entità di sicurezza e un catalogo globale disponibile. È un'operazione costosa per i controller di dominio. Partite dagli account interessati invece di eseguire query estese e ripetute. La sua popolazione di SID è una prova utile, ma non è comunque un contatore di byte del PAC.

Correzione: semplificare i gruppi senza perdere i controlli approvati (Remediation)

Passaggio 1: stabilire il riferimento e il ripristino

Salvate le appartenenze dirette, le relazioni tra gruppi e la popolazione transitiva degli account interessati. Registrate i responsabili dei gruppi, gli usi delle risorse, i diritti utente, le restrizioni approvate, le impostazioni dei buffer e le applicazioni coinvolte. Documentate la modifica prevista e un piano di ripristino prima di rimuovere le appartenenze. I precedenti comandi di sola lettura supportano questo inventario; non autorizzano una cancellazione.

Esaminate i gruppi predefiniti rispetto a un riferimento organizzativo mantenuto. Microsoft documenta funzioni legittime per gruppi come Event Log Readers anche quando l'appartenenza predefinita è vuota. Un nuovo membro può essere intenzionale. In assenza di un riferimento mantenuto, esaminate la giustificazione del responsabile invece di considerare dannosa l'aggiunta in sé.

Passaggio 2: rimuovere le dipendenze superflue e interrompere i cicli errati

Identificate la relazione precisa che crea un ciclo o una dipendenza obsoleta. Confermatene gli usi con il responsabile, rimuovete solo la relazione approvata e preservate le autorizzazioni e i dinieghi necessari. Appiattire significa semplificare l'architettura dei gruppi; non significa assegnare ogni utente direttamente nell'ACL di ogni risorsa.

Separate i ruoli aziendali dai gruppi di risorse e assegnate a entrambi responsabili e date di revisione. Controllate se il nuovo progetto riduca davvero le appartenenze effettive superflue. Riorganizzare i nomi dei gruppi o la nidificazione senza ridurre la popolazione di SID pertinente non dimostra che il contesto di autenticazione sia diventato più piccolo.

Passaggio 3: usare MaxTokenSize come misura provvisoria circoscritta

Se l'indagine dimostra un limite del buffer, valutate una modifica controllata della configurazione insieme alla pulizia strutturale. KB938118 documenta il criterio in Computer Configuration\Policies\Administrative Templates\System\Kerberos, denominato Set maximum Kerberos SSPI context token buffer size. Specifica di abilitare il criterio e immettere 48000. Per la procedura di preferenza del Registro di sistema, scegliete REG_DWORD e l'immissione decimale.

Confrontate prima quel valore con la configurazione effettiva. Impostare 48 000 su una macchina che usa già 48 000 non aumenta la capacità. Seguite i requisiti documentati di riavvio dopo l'applicazione, mantenete un piano di ripristino ed esaminate i vincoli HTTP. Non considerate 65 535 la raccomandazione predefinita e non presumete che una modifica solo sul controller di dominio risolva un percorso con più partecipanti.

Passaggio 4: verificare gli accessi e i dinieghi necessari

Riconnettete gli account pilota e verificate nuovamente ogni servizio interessato. Controllate le azioni aziendali approvate, le restrizioni che devono rimanere e le eventuali concessioni compensative introdotte durante l'interruzione. Confrontate le appartenenze e le relazioni dirette prima e dopo. Osservate nuovamente l'errore effettivo e il contesto dell'avviso.

La scomparsa di una segnalazione di dimensione o di ciclo è una prova utile sullo stato della directory, ma non è un test completo di accettazione del servizio. Chiudete la correzione quando il flusso di lavoro interessato e il modello di accesso corrispondono entrambi all'obiettivo documentato. Conservate le eccezioni con responsabili e date di revisione, per confrontare le modifiche successive con lo stesso riferimento.

Come EtcSec rileva questo problema

L'etc-collector di EtcSec fornisce sei controlli pertinenti sullo stato della directory. I loro predicati esatti sono riportati di seguito. I quattro controlli di dimensione contano i membri diretti, non la dimensione del token. Nessuno dei sei controlli conta i SID dei gruppi transitivi di un utente, misura i byte del PAC, legge MaxTokenSize o dimostra un errore di autenticazione.

Il suffisso CRITICAL corrisponde alla gravità effettiva High, mentre HIGH corrisponde alla gravità effettiva Medium. Queste soglie di membri diretti sono regole del collector, non limiti di autenticazione Microsoft. I predicati di dimensione non filtrano esplicitamente i gruppi di sicurezza rispetto a quelli di distribuzione.

Le loro popolazioni si sovrappongono: GROUP_EXCESSIVE_MEMBERS copre sia le popolazioni di 101–500 sia quelle di >500 membri; OVERSIZED_GROUP_HIGH è un sottoinsieme di OVERSIZED_GROUP. Non sommate i conteggi come gruppi distinti e non descrivete quattro rischi di crescita del token dimostrati indipendentemente. Visualizzare soltanto i cinque gruppi più grandi nei dettagli dei membri eccessivi non limita il conteggio totale delle segnalazioni.

Il controllo circolare conta i gruppi coinvolti, non i cicli o gli utenti con errori. Il suo grafo conserva soltanto i gruppi noti raccolti e normalizza i nomi distinti. Un ciclo che passa per un dominio non raccolto può sfuggire al controllo. Il risultato individua relazioni da esaminare, non la causa di un errore Kerberos.

Cosa significa davvero il riferimento dei gruppi predefiniti

BUILTIN_MODIFIED usa ricerche esatte del sAMAccountName in inglese. Le sue liste non vuote accettano Administrator, Domain Admins ed Enterprise Admins per Administrators; Domain Users, Authenticated Users e INTERACTIVE per Users; Guest e Domain Guests per Guests.

Le sue nove liste vuote coprono Remote Desktop Users, Network Configuration Operators, Performance Monitor Users, Performance Log Users, Distributed COM Users, IIS_IUSRS, Cryptographic Operators, Event Log Readers e Certificate Service DCOM Access. Un CN estratto in uno di questi gruppi può attivare il controllo anche quando l'aggiunta supporta un'attività legittima.

Il confronto accetta un'uguaglianza senza distinzione tra maiuscole e minuscole o una corrispondenza di sottostringa con un nome atteso. Ignora i DN dei membri senza un CN estratto e non verifica il SID o il contenitore del gruppo. I nomi localizzati, le rinomine, i gruppi omonimi e i CN contenenti un nome atteso limitano l'interpretazione. Non rileva membri attesi mancanti, non esamina modifiche alle ACL e non confronta la cronologia delle modifiche di un'organizzazione.

Usate questa segnalazione per richiedere un responsabile, una giustificazione e un confronto con il riferimento locale. La risposta corretta è una decisione di appartenenza sottoposta a revisione, non una rimozione automatica generalizzata. Combinate tutte e sei le segnalazioni con le prove di servizio raccolte in precedenza per decidere cosa modificare e come convalidarlo.