Es posible que se produzca un error al iniciar sesión en una cuenta de usuario que sea miembro de más de 1010 grupos en un equipo basado en Windows Server.

En este artículo se resuelve un problema por el que se produce un error al iniciar sesión en una cuenta de usuario que sea miembro de más de 1010 grupos.

Se aplica a: Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Número de KB original: 328889

Síntomas

Cuando un usuario intenta iniciar sesión en un equipo mediante una cuenta de equipo local o una cuenta de usuario de dominio, es posible que se produzca un error en la solicitud de inicio de sesión. Y recibe el siguiente mensaje de error:

Mensaje de inicio de sesión: El sistema no puede iniciar sesión debido al siguiente error: durante un intento de inicio de sesión, el contexto de seguridad del usuario ha acumulado demasiados identificadores de seguridad. Inténtelo de nuevo o consulte al administrador del sistema.

El problema se produce cuando el usuario de inicio de sesión es un miembro explícito o transitivo de aproximadamente 1010 o más grupos de seguridad.

Las aplicaciones y el identificador de registro de eventos de seguridad 4625 pueden mostrar este código de error:

0xc000015a

El error es STATUS_TOO_MANY_CONTEXT_IDS.

Causa

Cuando un usuario inicia sesión en un equipo, la autoridad de seguridad local (LSA, una parte del subsistema de autoridad de seguridad local) genera un token de acceso. El token representa el contexto de seguridad del usuario. El token de acceso consta de identificadores de seguridad únicos (SID) para cada grupo del que es miembro el usuario. Estos SID incluyen grupos transitivos y valores de SID de SIDHistory del usuario y las cuentas de grupo.

La matriz que contiene los SID de las pertenencias a grupos del usuario en el token de acceso no puede contener más de 1024 SID. LSA no puede quitar ningún SID del token. Por lo tanto, si hay más SID, LSA no puede crear el token de acceso y el usuario no podrá iniciar sesión.

Cuando se compila la lista de SID, el LSA también inserta varios SID genéricos conocidos además de los SID para las pertenencias a grupos del usuario (evaluados transitivamente). Por lo tanto, si un usuario es miembro de más de 1010 grupos de seguridad personalizados, el número total de SID puede superar el límite de 1024 SID.

Importante

• Los tokens para las cuentas de administrador y no administrador están sujetos al límite.
• El número exacto de SID personalizados varía con el tipo de inicio de sesión (por ejemplo, interactivo, servicio, red) y la versión del sistema operativo del controlador de dominio y el equipo que crea el token.
• El uso de Kerberos o NTLM como protocolo de autenticación no tiene ningún efecto en el límite de tokens de acceso.
• La configuración del cliente Kerberos MaxTokenSize se describe en Problemas con la autenticación Kerberos cuando un usuario pertenece a muchos grupos. Token en el contexto de Kerberos hace referencia al búfer de los vales recibidos por un host de Windows Kerberos. Según el tamaño del vale, el tipo de SID y si la compresión de SID está habilitada, el búfer puede contener menos o muchos más SID que los que caben en el token de acceso.

La lista de SID personalizados incluirá:

• Los SID principales del usuario o equipo y los grupos de seguridad de los que es miembro la cuenta.
• Los SID del atributo SIDHistory de los grupos en el ámbito del inicio de sesión.

Dado que el atributo SIDHistory puede contener varios valores, el límite de 1024 SID se puede alcanzar rápidamente si las cuentas se migran varias veces. El número de SID del token de acceso será menor que el número total de grupos de los que el usuario es miembro en la siguiente situación:

• El usuario procede de un dominio de confianza donde se filtran SIDHistory y SID.
• El usuario procede de un dominio de confianza a través de una confianza en la que se ponen en cuarentena los SID. A continuación, solo se incluyen los SID del mismo dominio que los del usuario.
• Solo se incluyen los SID del grupo local de dominio del dominio del recurso.
• Solo se incluyen los SID de grupo local del servidor de recursos.

Debido a estas diferencias, es posible que el usuario pueda iniciar sesión en un equipo de un dominio, pero no en un equipo de otro dominio. Es posible que el usuario también pueda iniciar sesión en un servidor de un dominio, pero no en otro servidor del mismo dominio.

Puede obtener información sobre las pertenencias a grupos de dominio de un usuario afectado con NTDSUTIL. Tiene una herramienta de evaluación de pertenencia a grupos que también funciona a través de los límites de los bosques. La herramienta también funciona para los siguientes usuarios:

• usuarios que están muy por encima del límite de 1024 SID
• usuarios que están en tantos grupos en los que Kerberos produce un error en la recuperación de vales, incluso con 65 535 bytes del búfer

Siga estos pasos:

1. Abra un símbolo del sistema en un equipo que tenga herramientas de administración de AD (controlador de dominio o un equipo que tenga RSAT).

2. Cambie a la gro mem eva herramienta y, a continuación, obtenga los comandos disponibles como la captura de pantalla siguiente:

   

3. Conéctese a los controladores de dominio necesarios para la evaluación:

   • Establecer controlador de dominio de cuenta %s: controlador de dominio del usuario
   • Establecer catálogo global %s: GC del bosque del usuario
   • Establecer el controlador de dominio de recursos %s: controlador de dominio del recurso
   • Establezca las credenciales según sea necesario o los registros detallados cuando los resultados parezcan incorrectos o se produzca un error en la colección.

4. Ejecute la evaluación como se indica a continuación (por ejemplo, para admin en contoso.com):

   Run contoso.com Admin

5. La ejecución recopilará los detalles del usuario en los pasos 1-2, detalles del grupo de dominio de recursos en el paso 3 y, a continuación, compilará el informe en los pasos 4 y 5.

6. Los resultados se almacenarán en un archivo TSV en el directorio actual como captura de pantalla siguiente:

   

Consulte la siguiente guía para leer un archivo TSV:

• Tipo de SID: indica si es el SID principal del grupo o usuario o SIDHistory.
• Recuento de historial de SID: ¿Cuántos SID de SIDHistory presenta esta cuenta?
• One Level MemberOf Count: ¿Cuántos SIDs agrega esta entrada a la colección en un solo nivel (miembro de las entradas)?
• Total MemberOf Count: ¿Cuántos SIDs agrega esta entrada a la colección en total?
• Propietario del grupo: en el caso de los entornos que tienen administración de grupos delegados, puede obtener sugerencias sobre cómo usar demasiados grupos para atacar el inicio de sesión del usuario.
• Tipo de grupo: tipo de sid. WellKnown, siD de usuario, grupos de seguridad globales y universales estarían en todos los tokens creados para este usuario. El grupo de seguridad local de dominio solo estaría en este dominio de recursos. Puede ser importante cuando un usuario tiene problemas de inicio de sesión solo en un dominio de recursos determinado.
• Miembro WhenChanged (UTC): cambio más reciente a la pertenencia a grupos. Puede ayudar a correlacionar con el momento en que los usuarios notifican por primera vez problemas de inicio de sesión.

Sugerencias para buscar grupos a los que se dirige un cambio:

• Los grupos que tienen SIDHistory tienen una buena ventaja que ayuda a reducir el número de SID.

• Los grupos que introducen muchos otros grupos a través del anidamiento tienen una gran ventaja para reducir el número de SID.

• Busque pistas en el nombre del grupo para determinar si es posible que el grupo ya no se use. Por ejemplo, teníamos un cliente que tiene un grupo por aplicación en su solución de implementación de software. Y encontramos grupos que contenían office2000 o access2000.

• Pase el informe de la lista de grupos a los administradores de aplicaciones y servicios. Identifique los grupos que ya no son necesarios, quizás solo para este usuario de esta unidad de negocio o departamento.

Limitaciones:

• La herramienta no incluye algunos tipos de SID especiales o WellKnown que se enumeran a continuación en este artículo. Por lo tanto, recuerde que un usuario debe borrar varios SID de 1024 en el informe para poder iniciar sesión correctamente.

• La herramienta tampoco cubre los grupos locales del servidor. Si solo tiene problemas en determinados servidores de un dominio de recursos, tal vez el usuario o parte de su grupo sean miembros de grupos locales de servidor.

Para obtener una lista de grupos locales de servidor y sus miembros:

Nota:

Ejecute como administrador en un símbolo del sistema con privilegios elevados.

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

Para obtener una lista de miembros de un dominio:

Md server-groups

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

Combine y coincida con los grupos notificados allí con el informe de usuario de NTDSUTIL.

Solución

Para solucionar este problema, use uno de los métodos siguientes, según corresponda para su situación.

Método 1

Esta resolución se aplica a la siguiente situación:

• El usuario que encuentra el error de inicio de sesión no es un administrador.
• Los administradores pueden iniciar sesión correctamente en el equipo o en el dominio.

Un administrador debe realizar esta resolución que tenga permisos para cambiar las pertenencias a grupos del usuario. El administrador debe cambiar las pertenencias a grupos del usuario para asegurarse de que el usuario ya no sea miembro de más de 1010 grupos de seguridad. Tenga en cuenta las pertenencias a grupos transitivos y las pertenencias a grupos locales.

Las opciones para reducir el número de SID en el token de usuario incluyen lo siguiente. La recopilación de datos de NTDSUTIL debe ayudarle a ver qué grupos están en el ámbito de cambio o eliminación:

• Quite el usuario de un número suficiente de grupos de seguridad.

• Convertir grupos de seguridad sin usar en grupos de distribución. Los grupos de distribución no cuentan con el límite de tokens de acceso. Los grupos de distribución se pueden volver a convertir en grupos de seguridad cuando se requiere un grupo convertido.

• Determine si las entidades de seguridad se basan en el historial de SID para el acceso a los recursos. Si no es así, quite el atributo SIDHistory de estas cuentas. Puede recuperar el valor del atributo a través de una restauración autoritativa.

Nota:

Aunque el número máximo de grupos de seguridad de los que un usuario puede ser miembro es de 1024, como procedimiento recomendado, restrinja el número a menos de 1010. Este número garantiza que la generación de tokens siempre se realizará correctamente porque proporciona espacio para los SID genéricos insertados por el LSA.

Método 2

La resolución se aplica a la situación en la que la cuenta de administrador no puede iniciar sesión en el equipo.

Cuando el usuario cuyo inicio de sesión produce un error debido a demasiadas pertenencias a grupos es miembro del grupo Administradores, un administrador que tiene las credenciales de la cuenta de administrador (es decir, una cuenta que tiene un identificador relativo conocido [RID] de 500) debe reiniciar un controlador de dominio seleccionando la opción de inicio modo seguro (o seleccionando el modo seguro con la opción de inicio de redes). En modo seguro, el administrador debe iniciar sesión en el controlador de dominio mediante las credenciales de la cuenta de administrador.

Consulte Reiniciar el controlador de dominio en modo de restauración de servicios de directorio localmente.

Microsoft ha cambiado el algoritmo de generación de tokens. El LSA puede crear un token de acceso para la cuenta de administrador para que el administrador pueda iniciar sesión independientemente del número de grupos transitivos o grupos intransitivos de los que es miembro la cuenta de administrador. Cuando se usa una de estas opciones de inicio del modo seguro, el token de acceso que se crea para la cuenta de administrador incluye los SID de todos los grupos integrados y todos los grupos globales de dominio de los que es miembro la cuenta de administrador.

Estos grupos suelen incluir:

• Todos (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\Usuarios autenticados (S-1-5-11)
• LOCAL (S-1-2-0)
• Dominio\Usuarios de dominio (S-1-5-21-xxxxxxxx-aaaay-zzzzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyy-zzzzzzzz-512)
• BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554) si Todos son miembros de este grupo
• NT AUTHORITY\Esta organización (S-1-5-15) si el controlador de dominio ejecuta Windows Server 2003

Nota:

Si se usa la opción de inicio modo seguro, la interfaz de usuario (UI) del complemento Usuarios y equipos de Active Directory no está disponible. En Windows Server, el administrador puede iniciar sesión si selecciona la opción Modo seguro con inicio de redes; en este modo, la interfaz de usuario del complemento Usuarios y equipos de Active Directory está disponible.

Una vez que un administrador haya iniciado sesión seleccionando una de las opciones de inicio del modo seguro y usando las credenciales de la cuenta de administrador, el administrador debe identificar y modificar la pertenencia de los grupos de seguridad que provocaron la denegación de inicio de sesión.

Una vez realizado este cambio, los usuarios deben poder iniciar sesión correctamente después de que haya transcurrido un período de tiempo igual a la latencia de replicación del dominio.

Método 3

Esta opción tiene el mayor atractivo si tiene muchos grupos creados para conceder acceso a los recursos que se usan en un conjunto específico de servidores y no son relevantes para muchos otros servidores. El token de acceso de los usuarios siempre contiene los SID del usuario, los grupos globales y universales. Sin embargo, solo contiene los SID de los grupos de dominio local del dominio donde están los servidores de recursos. Por lo tanto, a partir de 600 grupos de los que un usuario es miembro, 400 ayudan a conceder acceso a los recursos del servidor de archivos en dos grupos de servidores y, a continuación, las siguientes ideas pueden ser factibles:

• Divida los servidores en varios grupos según el número de grupos de dominio local.
• En lugar de un dominio de recursos que tenga todos los grupos y servidores, tenga varios dominios donde solo los grupos definidos que contengan los servidores que necesita.
• Tener un dominio independiente para los servidores con una pequeña necesidad de grupos locales de dominio. Un ejemplo podría ser servidores exchange, ya que Exchange tiene una preferencia fuerte para los grupos universales.

Más información

Los SID genéricos de una cuenta suelen incluir:

• Todos (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administrators (S-1-5-32-544)
• NT AUTHORITY\Usuarios autenticados (S-1-5-11)
• Sid de sesión de inicio de sesión (S-1-5-5-X-Y)
• BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554) si el usuario es miembro de este grupo (anidado)

Importante

La herramienta Whoami se usa a menudo para inspeccionar los tokens de acceso. Esta herramienta no muestra el SID de sesión de inicio de sesión.

Ejemplos de SID en función del tipo de sesión de inicio de sesión:

• LOCAL (S-1-2-0)
• INICIO DE SESIÓN DE CONSOLA (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 para grupos primarios usados con frecuencia:

• Dominio\Equipos de dominio (S-1-5-21-xxxxxxxx-aaaay-zzzzzzzz-515)
• Dominio\Usuarios de dominio (S-1-5-21-xxxxxxxx-aaaay-zzzzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyy-zzzzzzzz-512)

SID que documenta cómo se ha comprobado la sesión de inicio de sesión, uno de los siguientes valores:

• Identidad aserida por la autoridad de autenticación (S-1-18-1)
• Identidad aserda del servicio (S-1-18-2)

SID que proporcionan detalles sobre el contexto del token y los detalles de la notificación, más de uno posible:

• Notificaciones de dispositivo que se usan (S-1-5-21-0-0-0-496)
• Notificaciones de usuario que se usan (S-1-5-21-0-0-0-497)
• Este certificado de organización (S-1-5-65-1)
• El token se creó con la ayuda de una identidad verificada de PKI (S-1-18-4)
• El token se creó mediante el enfoque de MFA (S-1-18-5)
• Credential Guard se usó (S-1-18-6)

SID que describen el nivel de coherencia del token, los ejemplos más comunes:

• Nivel obligatorio medio (S-1-16-8192)
• Alto nivel obligatorio (S-1-16-12288)

El token de acceso incluye un SID relativo al origen de usuario o equipo, uno de los siguientes valores:

• NT AUTHORITY\OTHER_ORGANIZATION (S-1-5-1000)
• NT AUTHORITY\Esta organización (S-1-5-15) si la cuenta procede del mismo bosque que el equipo.

Nota:

• Como puede ver con la nota en el SID de inicio de sesión de sesión de entrada de SID, no cuente los SID en la lista de salidas de la herramienta y suponga que están completos para todos los equipos de destino y los tipos de inicio de sesión. Debe considerar que una cuenta está en peligro de encontrarse con este límite cuando tiene más de 1000 SID. No olvide que, dependiendo del equipo donde se crea un token, también se pueden agregar grupos locales de servidor o estación de trabajo.
• xxxxxxxx-aaaay-zzzzzzzzzz indica los componentes de dominio o estación de trabajo del SID.

En el ejemplo siguiente se muestra qué grupos de seguridad locales de dominio se mostrarán en el token del usuario cuando el usuario inicie sesión en un equipo de un dominio.

En este ejemplo, supongamos que Joe pertenece al dominio A y es miembro de un grupo local de dominio Dominio A\Usuarios de Chicago. Joe también es miembro de un grupo local de dominio Dominio B\Usuarios de Chicago . Cuando Joe inicia sesión en un equipo que pertenece al dominio A (por ejemplo, dominio A\estación de trabajo1), se genera un token para Joe en el equipo y el token contiene, además de todas las pertenencias a grupos universales y globales, el SID para los usuarios del dominio A\Chicago. No contendrá el SID del dominio B\Chicago Users porque el equipo en el que Joe inició sesión (Dominio A\Workstation1) pertenece al dominio A.

Del mismo modo, cuando Joe inicia sesión en un equipo que pertenece al dominio B (por ejemplo, dominio B\Estación de trabajo1), se genera un token para Joe en el equipo y el token contiene, además de todas las pertenencias a grupos universales y globales, el SID para los usuarios del dominio B\Chicago; no contendrá el SID del dominio A\Chicago Users porque el equipo donde Joe inició sesión (Dominio B\Workstation1) pertenece al dominio B.

Sin embargo, cuando Joe inicia sesión en un equipo que pertenece al dominio C (por ejemplo, dominio C\Workstation1), se genera un token para Joe en el equipo de inicio de sesión que contiene todas las pertenencias a grupos universales y globales para la cuenta de usuario de Joe. Ni el SID del dominio A\Chicago Users ni el SID para el dominio B\Chicago Users aparecen en el token porque los grupos locales de dominio de los que Joe es miembro están en un dominio diferente del equipo en el que Joe inició sesión (Dominio C\Workstation1). Por el contrario, si Joe era miembro de algún grupo local de dominio que pertenece al dominio C (por ejemplo, Dominio C\Usuarios de Chicago), el token que se genera para Joe en el equipo contendrá, además de todas las pertenencias a grupos universales y globales, el SID para el dominio C\Chicago Users.

Referencias

• SID conocidos

• Estructuras de SID conocidas

• evaluación de pertenencia a grupos