L'accesso a un account utente membro di più di 1.010 gruppi potrebbe non riuscire in un computer basato su Windows Server

Questo articolo risolve un problema per cui l'accesso a un account utente membro di più di 1.010 gruppi ha esito negativo.

Si applica a: Windows Server 2008 R2 Service Pack 1
Numero KB originale: 328889

Sintomi

Quando un utente tenta di accedere a un computer usando un account computer locale o un account utente di dominio, la richiesta di accesso potrebbe non riuscire. Viene visualizzato il messaggio di errore seguente:

Messaggio di accesso: il sistema non può accedere a causa dell'errore seguente: durante un tentativo di accesso, il contesto di sicurezza dell'utente ha accumulato troppi ID di sicurezza. Riprovare o consultare l'amministratore di sistema.

Il problema si verifica quando l'utente di accesso è un membro esplicito o transitivo di circa 1.010 o più gruppi di sicurezza.

Le applicazioni e l'ID del registro eventi di sicurezza 4625 possono visualizzare questo codice di errore:

0xc000015a

L'errore è STATUS_TOO_MANY_CONTEXT_IDS.

Causa

Quando un utente accede a un computer, l'autorità di sicurezza locale (LSA, una parte del sottosistema dell'autorità di sicurezza locale) genera un token di accesso. Il token rappresenta il contesto di sicurezza dell'utente. Il token di accesso è costituito da identificatori di sicurezza univoci (SID) per ogni gruppo di cui l'utente è membro. Questi SID includono gruppi transitivi e valori SID da SIDHistory dell'utente e degli account di gruppo.

La matrice che contiene i SID delle appartenenze ai gruppi dell'utente nel token di accesso non può contenere più di 1.024 SID. LSA non può eliminare alcun SID dal token. Pertanto, se sono presenti più SID, LSA non riesce a creare il token di accesso e l'utente non sarà in grado di accedere.

Quando viene compilato l'elenco di SID, l'LSA inserisce anche diversi SID generici e noti oltre ai SID per le appartenenze ai gruppi dell'utente (valutati in modo transitivo). Pertanto, se un utente è membro di più di circa 1.010 gruppi di sicurezza personalizzati, il numero totale di SID può superare il limite di 1.024 SID.

Importante

  • I token per gli account amministratore e non amministratore sono soggetti al limite.
  • Il numero esatto di SID personalizzati varia in base al tipo di accesso (ad esempio, interattivo, servizio, rete) e alla versione del sistema operativo del controller di dominio e del computer che crea il token.
  • L'uso di Kerberos o NTLM come protocollo di autenticazione non influisce sul limite del token di accesso.
  • L'impostazione del client Kerberos MaxTokenSize è illustrata in Problemi con l'autenticazione Kerberos quando un utente appartiene a molti gruppi. Token nel contesto Kerberos fa riferimento al buffer per i ticket ricevuti da un host Kerberos Windows. A seconda delle dimensioni del ticket, del tipo di SID e dell'abilitazione della compressione SID, il buffer può contenere meno o più SID rispetto a quelli che rientrano nel token di accesso.

L'elenco dei SID personalizzati includerà:

  • I SID primari dell'utente/computer e i gruppi di sicurezza di cui è membro l'account.
  • SID nell'attributo SIDHistory dei gruppi nell'ambito dell'accesso.

Poiché l'attributo SIDHistory può contenere più valori, è possibile raggiungere rapidamente il limite di 1.024 SID se gli account vengono migrati più volte. Il numero di SID nel token di accesso sarà inferiore al numero totale di gruppi di cui l'utente è membro nella situazione seguente:

  • L'utente proviene da un dominio attendibile in cui SIDHistory e SID vengono filtrati.
  • L'utente proviene da un dominio attendibile in un trust in cui i SID vengono messi in quarantena. Vengono quindi inclusi solo i SID dello stesso dominio dell'utente.
  • Sono inclusi solo i SID del gruppo locale di dominio del dominio della risorsa.
  • Sono inclusi solo i SID del gruppo locale del server di risorse.

A causa di queste differenze, è possibile che l'utente possa accedere a un computer in un dominio, ma non a un computer in un altro dominio. L'utente potrebbe anche essere in grado di accedere a un server in un dominio, ma non a un altro server nello stesso dominio.

È possibile trovare informazioni sulle appartenenze ai gruppi di dominio di un utente interessato con NTDSUTIL. Dispone di uno strumento di valutazione dell'appartenenza al gruppo che funziona anche oltre i limiti delle foreste. Lo strumento funziona anche per gli utenti seguenti:

  • utenti che sono ben al di sopra del limite di 1.024 SID
  • utenti che si trovano in un numero così elevato di gruppi che Kerberos non riesce a recuperare i ticket anche con 65.535 byte del buffer

attenersi alla seguente procedura:

  1. Aprire un prompt dei comandi in un computer che dispone di Strumenti di gestione di Active Directory (controller di dominio o computer con RSAT).

  2. Passare allo gro mem eva strumento e quindi ottenere i comandi disponibili come screenshot seguente:

    Screenshot dell'output dopo l'esecuzione del comando gro mem eva.

  3. Connettersi ai controller di dominio necessari per la valutazione:

    • Set Account DC %s - DC del dominio dell'utente
    • Impostare il catalogo globale %s - Gc della foresta dell'utente
    • Impostare il controller di dominio risorsa %s - Controller di dominio del dominio della risorsa
    • Impostare le credenziali in base alle esigenze o i log dettagliati quando i risultati sembrano errati o la raccolta ha esito negativo.
  4. Eseguire la valutazione nel modo seguente, ad esempio per Amministrazione in contoso.com:

    Run contoso.com Admin

  5. L'esecuzione raccoglierà i dettagli utente nei passaggi 1-2, i dettagli del gruppo di dominio delle risorse nel passaggio 3 e quindi compilerà il report nei passaggi 4 e 5.

  6. I risultati verranno archiviati in un file TSV nella directory corrente come screenshot seguente:

    Screenshot che mostra che i risultati verranno archiviati in un file TSV nella directory corrente.

Vedere la guida seguente per leggere un file TSV:

  • Tipo SID: Indica se si tratta del SID primario del gruppo/utente o di SIDHistory.
  • Numero di cronologia SID: quanti SID di SIDHistory introduce questo account?
  • Un livello MemberOf Count: quanti SID aggiunge questa voce alla raccolta su un singolo livello (membro delle voci)?
  • Total MemberOf Count: quanti SID questa voce aggiunge alla raccolta in totale?
  • Proprietario del gruppo: per gli ambienti con gestione delegata dei gruppi, è possibile ottenere suggerimenti su come usare un numero eccessivo di gruppi per attaccare l'accesso degli utenti.
  • Tipo di gruppo: tipo di sid. WellKnown, sid utente, gruppi di sicurezza globali e universali si presenterebbero in tutti i token creati per questo utente. Il gruppo di sicurezza locale del dominio si appresto solo a questo dominio di risorse. Può essere importante quando un utente presenta problemi di accesso solo in un determinato dominio di risorse.
  • Member WhenChanged (UTC): modifica più recente all'appartenenza al gruppo. Può essere utile per la correlazione con il momento in cui gli utenti hanno segnalato per la prima volta i problemi di accesso.

Suggerimenti per trovare i gruppi di destinazione per una modifica:

  • I gruppi con SIDHistory hanno una buona leva per ridurre il numero di SID.

  • I gruppi che introducono molti altri gruppi tramite l'annidamento hanno un'ottima leva per ridurre il numero di SID.

  • Cercare gli indizi nel nome del gruppo per determinare se il gruppo non può più essere usato. Ad esempio, un cliente ha un gruppo per applicazione nella soluzione di distribuzione software. Sono stati trovati gruppi che contenevano office2000 o access2000.

  • Passare il report dell'elenco di gruppi agli amministratori del servizio e dell'applicazione. Identificare i gruppi che non sono più necessari, forse solo per questo utente in questa business unit o reparto.

Limitazioni:

  • Lo strumento non include alcuni tipi di SID speciali/WellKnown elencati di seguito in questo articolo. Tenere quindi presente che un utente deve cancellare diversi SID da 1.024 nel report prima di poter accedere correttamente.

  • Lo strumento inoltre non copre i gruppi locali del server. Se si verificano problemi solo in determinati server di un dominio di risorse, è possibile che l'utente o alcuni dei relativi gruppi siano membri di gruppi locali del server.

Per ottenere un elenco di gruppi locali del server e dei relativi membri:

Nota

Eseguire come amministratore in un prompt dei comandi con privilegi elevati.

Net localgroup | findstr * > %computername%-grouplist.txt

Per ottenere un elenco di membri da un dominio:

Md server-groups

For /f "delims=*" %d in (%computername%-grouplist.txt) do Net localgroup %d | findstr \ > server-groups\%d-domain-memberlist.txt**

Combinare e associare i gruppi segnalati con il report utente di NTDSUTIL.

Risoluzione

Per risolvere questo problema, usare uno dei metodi seguenti, in base alla situazione.

Metodo 1

Questa risoluzione si applica alla situazione seguente:

  • L'utente che rileva l'errore di accesso non è un amministratore.
  • Gli amministratori possono accedere correttamente al computer o al dominio.

Questa risoluzione deve essere eseguita da un amministratore che dispone delle autorizzazioni per modificare le appartenenze ai gruppi dell'utente. L'amministratore deve modificare le appartenenze ai gruppi dell'utente per assicurarsi che l'utente non sia più membro di più di circa 1.010 gruppi di sicurezza. Si considerino le appartenenze ai gruppi transitivi e le appartenenze ai gruppi locali.

Le opzioni per ridurre il numero di SID nel token utente includono quanto segue. La raccolta di dati da NTDSUTIL dovrebbe aiutare a vedere quali gruppi sono nell'ambito per la modifica o la rimozione:

  • Rimuovere l'utente da un numero sufficiente di gruppi di sicurezza.

  • Convertire i gruppi di sicurezza inutilizzati in gruppi di distribuzione. I gruppi di distribuzione non sono conteggiati rispetto al limite del token di accesso. I gruppi di distribuzione possono essere convertiti nuovamente in gruppi di sicurezza quando è necessario un gruppo convertito.

  • Determinare se le entità di sicurezza si basano sulla cronologia SID per l'accesso alle risorse. In caso contrario, rimuovere l'attributo SIDHistory da questi account. È possibile recuperare il valore dell'attributo tramite un ripristino autorevole.

Nota

Anche se il numero massimo di gruppi di sicurezza di cui un utente può essere membro è 1.024, come procedura consigliata, limitare il numero a meno di 1.010. Questo numero garantisce che la generazione di token abbia sempre esito positivo perché fornisce spazio per i SID generici inseriti dall'LSA.

Metodo 2

La risoluzione si applica alla situazione in cui l'account amministratore non può accedere al computer.

Quando l'utente il cui accesso ha esito negativo a causa di un numero eccessivo di appartenenze a gruppi è membro del gruppo Administrators, un amministratore che dispone delle credenziali per l'account Amministratore (ovvero un account con un identificatore relativo noto [RID] di 500) deve riavviare un controller di dominio selezionando l'opzione di avvio modalità provvisoria (o selezionando l'opzione Modalità provvisoria con avvio rete). In modalità provvisoria, l'amministratore deve quindi accedere al controller di dominio usando le credenziali dell'account amministratore.

Microsoft ha modificato l'algoritmo di generazione del token. L'LSA può creare un token di accesso per l'account Amministratore in modo che l'amministratore possa accedere indipendentemente dal numero di gruppi transitivi o intransitivi di cui è membro l'account amministratore. Quando si usa una di queste opzioni di avvio in modalità provvisoria, il token di accesso creato per l'account amministratore include i SID di tutti i gruppi predefiniti e di tutti i gruppi globali di dominio di cui è membro l'account amministratore.

Questi gruppi includono in genere:

  • Tutti (S-1-1-0)
  • BUILTIN\Users (S-1-5-32-545)
  • BUILTIN\Administrators (S-1-5-32-544)
  • NT AUTHORITY\INTERACTIVE (S-1-5-4)
  • NT AUTHORITY\Authenticated Users (S-1-5-11)
  • LOCAL (S-1-2-0)
  • Domain\Domain Users (S-1-5-21-xxxxxxxx-yyyy-zzzzzzzz-513)
  • Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyyy-zzzzzzzz-512)
  • BUILTIN\Pre-Windows 2000 Compatible Access (S-1-5-32-554) se Everyone è membro di questo gruppo
  • NT AUTHORITY\This Organization (S-1-5-15) se il controller di dominio esegue Windows Server 2003

Nota

Se si usa l'opzione di avvio in modalità provvisoria, l'interfaccia utente dello snap-in Utenti e computer di Active Directory non è disponibile. In Windows Server 2003, l'amministratore può in alternativa accedere selezionando l'opzione Modalità provvisoria con avvio rete; in questa modalità è disponibile l'interfaccia utente dello snap-in Utenti e computer di Active Directory.

Dopo che un amministratore ha eseguito l'accesso selezionando una delle opzioni di avvio in modalità provvisoria e utilizzando le credenziali dell'account Amministratore, l'amministratore deve quindi identificare e modificare l'appartenenza dei gruppi di sicurezza che hanno causato il servizio Denial of Logon.

Dopo aver apportato questa modifica, gli utenti devono essere in grado di accedere correttamente dopo un periodo di tempo uguale alla latenza di replica del dominio.

Metodo 3

Questa opzione presenta l'aspetto più significativo se sono presenti molti gruppi creati per concedere l'accesso alle risorse usate in un set specifico di server e non sono rilevanti per molti altri server. Il token di accesso degli utenti contiene sempre i SID dei gruppi utente, globale e universale. Tuttavia, contiene solo i SID di Domain-Local gruppi del dominio in cui si trovano i server delle risorse. Pertanto, da 600 gruppi di cui un utente è membro, 400 contribuiscono a concedere l'accesso alle risorse del file server in due gruppi di server e quindi le idee seguenti possono essere fattibili:

  • Suddividere i server in più gruppi in base al numero di gruppi Domain-Local.
  • Anziché un dominio di risorse con tutti i gruppi e i server, hanno più domini in cui sono definiti solo i gruppi che contengono i server necessari.
  • Avere un dominio separato per i server con un minimo bisogno di gruppi locali di dominio. Un esempio potrebbe essere il server Exchange, in quanto Exchange ha una forte preferenza per i gruppi universali.

Ulteriori informazioni

I SID generici di un account includono spesso:

  • Tutti (S-1-1-0)
  • BUILTIN\Users (S-1-5-32-545)
  • BUILTIN\Administrators (S-1-5-32-544)
  • NT AUTHORITY\Authenticated Users (S-1-5-11)
  • Sid sessione di accesso (S-1-5-5-X-Y)
  • BUILTIN\Accesso compatibile pre-Windows 2000 (S-1-5-32-554) se l'utente è membro di questo gruppo (annidato)

Importante

Lo strumento Whoami viene spesso usato per controllare i token di accesso. Questo strumento non mostra il SID della sessione di accesso.

Esempi per i SID a seconda del tipo di sessione di accesso:

  • LOCAL (S-1-2-0)
  • ACCESSO CONSOLE (S-1-2-1)
  • NT AUTHORITY\NETWORK (S-1-5-2)
  • NT AUTHORITY\SERVICE (S-1-5-6)
  • NT AUTHORITY\INTERACTIVE (S-1-5-4)
  • NT AUTHORITY\TERMINAL SERVER USER (S-1-5-13)
  • NT AUTHORITY\BATCH (S-1-5-3)

SID per gruppi primari usati di frequente:

  • Domain\Domain Computers (S-1-5-21-xxxxxxxx-yyyyyy-zzzzzzzz-515)
  • Domain\Domain Users (S-1-5-21-xxxxxxxx-yyyy-zzzzzzzz-513)
  • Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyyy-zzzzzzzz-512)

SID che documenta come è stata verificata la sessione di accesso, uno dei valori seguenti:

  • Identità asserita dall'autorità di autenticazione (S-1-18-1)
  • Identità asserita del servizio (S-1-18-2)

SID che forniscono dettagli sul contesto del token e sui dettagli delle attestazioni, più di uno possibile:

  • Attestazioni dispositivo in uso (S-1-5-21-0-0-0-496)
  • Attestazioni utente usate (S-1-5-21-0-0-0-497)
  • Questo certificato dell'organizzazione (S-1-5-65-1)
  • Il token è stato creato con l'aiuto di un'identità verificata dall'infrastruttura a chiave pubblica (S-1-18-4)
  • Il token è stato creato usando l'approccio MFA (S-1-18-5)
  • È stato usato Credential Guard (S-1-18-6)

SID che descrivono il livello di coerenza del token, gli esempi più comuni:

  • Livello medio obbligatorio (S-1-16-8192)
  • Alto livello obbligatorio (S-1-16-12288)

Il token di accesso include un SID relativo all'origine utente/computer, uno dei valori seguenti:

  • NT AUTHORITY\OTHER_ORGANIZATION (S-1-5-1000)
  • NT AUTHORITY\This Organization (S-1-5-15) se l'account proviene dalla stessa foresta del computer.

Nota

  • Come si può notare con la nota alla voce SID Logon Session SID, non contare i SID nell'elenco degli output degli strumenti e presupporre che siano completi per tutti i computer di destinazione e i tipi di accesso. È consigliabile considerare che un account rischia di entrare in questo limite quando ha più di 1.000 SID. Non dimenticare che, a seconda del computer in cui viene creato un token, è anche possibile aggiungere gruppi locali di server o workstation.
  • xxxxxxxx-yyyyy-zzzzzzzz indica i componenti del dominio o della workstation del SID.

Nell'esempio seguente vengono illustrati i gruppi di sicurezza locali di dominio che verranno visualizzati nel token dell'utente quando l'utente accede a un computer in un dominio.

In questo esempio si supponga che Joe appartenga al dominio A ed sia membro di un gruppo locale di dominio Dominio A\Utenti di Chicago. Joe è anche membro di un gruppo locale di dominio Domain B\Chicago Users. Quando Joe accede a un computer appartenente al dominio A (ad esempio, Dominio A\Workstation1), viene generato un token per Joe nel computer e il token contiene, oltre a tutte le appartenenze a gruppi universali e globali, il SID per Domain A\Chicago Users. Non conterrà il SID per il dominio B\Chicago Users perché il computer in cui Joe ha eseguito l'accesso (Dominio A\Workstation1) appartiene al dominio A.

Analogamente, quando Joe accede a un computer appartenente al dominio B (ad esempio dominio B\Workstation1), viene generato un token per Joe nel computer e il token contiene, oltre a tutte le appartenenze a gruppi universali e globali, il SID per il dominio B\Chicago Users; non conterrà il SID per Domain A\Chicago Users perché il computer in cui Joe ha eseguito l'accesso (Dominio B\Workstation1) appartiene al dominio B.

Tuttavia, quando Joe accede a un computer appartenente al dominio C (ad esempio, Dominio C\Workstation1), viene generato un token per Joe nel computer di accesso che contiene tutte le appartenenze a gruppi globali e universali per l'account utente di Joe. Né il SID per il dominio A\Chicago Users né il SID per il dominio B\Chicago Users vengono visualizzati nel token perché i gruppi locali di dominio di cui Joe è membro si trovano in un dominio diverso dal computer in cui è stato eseguito l'accesso Joe (Dominio C\Workstation1). Viceversa, se Joe fosse un membro di un gruppo locale di dominio appartenente al dominio C (ad esempio, Domain C\Chicago Users), il token generato per Joe nel computer conterrà, oltre a tutte le appartenenze a gruppi universali e globali, il SID per Domain C\Chicago Users.

Riferimenti