El registro en una cuenta de usuario que es miembro de más de 1010 grupos puede producir un error en un equipo basado en Windows Server

En este artículo se resuelve un problema por el que se produce un error en el registro en una cuenta de usuario que es miembro de más de 1010 grupos.

Se aplica a: Windows Server 2008 R2 Service Pack 1
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 acumuló demasiados identificadores de seguridad. Inténtelo de nuevo o consulte con el 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 el usuario es miembro. Estos SID incluyen grupos transitivos y valores 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. El LSA no puede quitar ningún SID del token. Por lo tanto, si hay más SID, el 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 y conocidos además de los SID para las pertenencias a grupos del usuario (se evalúan 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.

La lista de SID personalizados incluirá:

• Los SID principales del usuario o equipo y los grupos de seguridad a los que pertenece 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, se puede alcanzar rápidamente el límite de 1024 SID si las cuentas se migran varias veces. El número de SID en el 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 en una confianza en la que los SID están en cuarentena. A continuación, solo se incluyen los SID del mismo dominio que los del usuario.
• Solo se incluyen los SID de grupo local de dominio del dominio del recurso.
• Solo se incluyen los SID del grupo local de servidores 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 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 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 siguiente captura de pantalla:

   

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

   • Establecimiento del controlador de dominio de la cuenta %s: controlador de dominio del dominio del usuario
   • Establecer %s del catálogo global: GC del bosque del usuario
   • Establecimiento del controlador de dominio de recurso %s: controlador de dominio del dominio de recursos
   • Establezca las credenciales según sea necesario o 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 Administración en contoso.com):

   Run contoso.com Admin

5. La ejecución recopilará los detalles del usuario en los pasos 1 a 2, los 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 historiales de SID: ¿Cuántos SID de SIDHistory presenta esta cuenta?
• Número de miembros de un nivel: ¿cuántos SID agrega esta entrada a la colección en un único nivel (miembro de las entradas)?
• Total MemberOf Count: ¿Cuántos SID agrega esta entrada a la colección en total?
• Propietario del grupo: en los entornos que han delegado la administración de grupos, puede obtener sugerencias sobre cómo se usan demasiados grupos para atacar el inicio de sesión del usuario.
• Tipo de grupo: tipo de sid. WellKnown, el SID de usuario, los grupos de seguridad global y universal 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.
• Member WhenChanged (UTC): último cambio en la pertenencia al grupo. Puede ayudar a correlacionar con la hora en que los usuarios notificaron por primera vez problemas de inicio de sesión.

Sugerencias para buscar grupos de destino para un cambio:

• Los grupos que tienen SIDHistory tienen un buen aprovechamiento que ayuda a reducir el número de SID.

• Los grupos que introducen muchos otros grupos mediante el 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 no se use más tiempo. 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 servicios y aplicaciones. Identifique los grupos que ya no se necesitan, quizás solo para este usuario en 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 tiene que borrar varios SID de 1024 en el informe para poder iniciar sesión correctamente.

• La herramienta tampoco cubre los grupos locales de 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:

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 situación siguiente:

• 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 el dominio.

Esta resolución debe realizarla un administrador 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 es miembro de más de 1010 grupos de seguridad. Tenga en cuenta las pertenencias a grupos transitivas 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 respecto al límite de token 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 mediante una restauración autoritativa.

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 falla 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 la opción de inicio Modo seguro con redes). En modo seguro, el administrador debe iniciar sesión en el controlador de dominio mediante las credenciales de la cuenta de administrador.

Microsoft ha cambiado el algoritmo de generación de tokens. 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 sea miembro la cuenta de administrador. Cuando se usa una de estas opciones de inicio en modo seguro, el token de acceso que se crea para la cuenta de administrador incluye los SID de todos los grupos integrados y 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\Authenticated Users (S-1-5-11)
• LOCAL (S-1-2-0)
• Domain\Domain Users (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzz-512)
• BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554) si Todos son miembros de este grupo
• NT AUTHORITY\This Organization (S-1-5-15) si el controlador de dominio ejecuta Windows Server 2003

Después de que un administrador haya iniciado sesión seleccionando una de las opciones de inicio de 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 del servicio 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 que se crean 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 de los grupos de usuarios, globales y universales. Sin embargo, solo contiene los SID de Domain-Local grupos del dominio donde están los servidores de recursos. Por lo tanto, de 600 grupos a los que pertenece un usuario, 400 ayudan a dar 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 Domain-Local.
• En lugar de un dominio de recursos que tiene todos los grupos y servidores, tiene varios dominios en los que solo se definen los grupos que contienen los servidores que necesita.
• Tener un dominio independiente para los servidores con un poco de necesidad de grupos locales de dominio. Un ejemplo podría ser servidores de Exchange, ya que Exchange tiene una fuerte preferencia por 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\Authenticated Users (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)

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 principales usados con frecuencia:

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

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

• Identidad aserda de la entidad de autenticación (S-1-18-1)
• Identidad aserda por el servicio (S-1-18-2)

SID que proporcionan detalles sobre el contexto del token y los detalles de 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 por PKI (S-1-18-4)
• El token se creó mediante el enfoque de MFA (S-1-18-5)
• Se usó Credential Guard (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\This Organization (S-1-5-15) si la cuenta procede del mismo bosque que el equipo.

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, suponga 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 para los usuarios del dominio B\Chicago porque el equipo donde Joe inició sesión (Dominio A\Estación de trabajo1) 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 para los usuarios del dominio A\Chicago porque el equipo donde Joe inició sesión (Dominio B\Estación de trabajo1) pertenece al dominio B.

Sin embargo, cuando Joe inicia sesión en un equipo que pertenece al dominio C (por ejemplo, Dominio C\Estación de trabajo1), 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 para los usuarios del dominio A\Chicago ni el SID para los usuarios del dominio B\Chicago aparecen en el token porque los grupos locales de dominio de los que Joe es miembro se encuentran en un dominio diferente al equipo donde Joe inició sesión (Dominio C\Workstation1). Por el contrario, si Joe fuera 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 los usuarios de Dominio C\Chicago.

Referencias

• SID conocidos

• Estructuras de SID conocidas

• evaluación de pertenencia a grupos