Quería comentarles sobre un problema con un entorno particular que puede ocurrir cuando se están integrando los sistemas UNIX y Active Directory. Microsoft tiene varios atributos en AD para facilitar esta tarea, y uno de esos atributos es el atributo memberUid en los objetos del grupo de seguridad. Hemos agregaso los ID de usuario al atributo memberUid del grupo de seguridad y Active Directory tratará que a medida que la pertenencia al grupo de los sistemas UNIX para los propósitos de autenticación/autorización.

Todo estaba muy bien durante mucho tiempo. El grupo creció y creció a más de un millar de usuarios, hasta que un día quisimos agregar otro usuario de UNIX, y obtuvimos este error:

“Se ha superado el límite administrativo para esta solicitud", hay un límite en este atributo?

La documentación MSDN establece que la propiedad rangeUpper del atributo memberUid es 256.000. El KB2983975 también menciona que:

"El límite de tamaño de atributo para el atributo memberUid en el esquema es 256.000 caracteres. Depende de la longitud valor individual de la cantidad de identificadores de usuario (UID) caben en el atributo ".

E incluso se puede ver por ti mismo si te apetece un ganso en el esquema:

Algo no cuadra aquí – sólo se han añadido alrededor de 1200 usuarios al atributo memberUid de este grupo de seguridad. Claro que es un grupo grande, pero que no exceda de 256.000 caracteres. Sumando todos los nombres que he añadido al atributo, me imagino que se suma a alguna parte alrededor de 10.000 caracteres. No 256.000.

Entonces, ¿qué pasa?

El problema es que estamos tocando un límite diferente a medida que seguimos agregando miembros al atributo memberUid, mucho antes de que lleguemos a 256k caracteres. El atributo memberUid es un atributo multivalor, sin embargo, no es linked attribute. Esto significa que tiene una limitación en su tamaño máximo que es menor que los 256.000 caracteres que se muestran en el objeto memberUid attributeSchema.

podemos distinguir entre qué atributos están relacionados o no en función de si esos objetos attributeSchema tienen valores en su atributo linkID.

Un ejemplo de un atributo multivalor y vinculadas:

Ejemplo de un atributo multivalor, pero no vinculado:

Así que si el límite no es realmente 256.000 caracteres, entonces ¿qué es?

Según Cómo el almacén de datos funciona en TechNet:

"El tamaño máximo de un registro de base de datos es 8110 bytes, en base a un niño de 8 kilobytes (KB) el tamaño de página. Debido a los requisitos generales variable y el número variable de atributos que un objeto puede tener, es imposible proporcionar un límite preciso para el número máximo de multivalues ??que un objeto puede almacenar en sus atributos...

El único valor que realmente se puede calcular es el número máximo de valores de un atributo nonlinked, varios valores cuando el objeto tiene un solo atributo (lo cual es imposible). En Windows 2000 Active Directory, este número se calcula en 1575 valores. A partir de este valor, tomando diversas estimaciones generales en cuenta y generalizar sobre los otros valores que el objeto puede almacenar, el límite práctico para el número de multivalues ??almacenados por un objeto se estima en 800 valores nonlinked por objeto en todos los atributos.

Atributos que representan enlaces no cuentan en este valor. Por ejemplo, los miembros vinculados, atributo multivalor de un objeto de grupo puede almacenar miles de valores porque los valores son enlaces solamente.

El límite práctico de 800 valores nonlinked por objeto aumenta en Windows Server 2003 y versiones posteriores. Cuando el bosque tiene un nivel funcional de Windows Server 2003 o superior, para un registro teórica de que sólo tiene un atributo con el mínimo de gastos generales, el número máximo de multivalues ??posibles en un registro se calcula en 3937. El uso de estimaciones similares para gastos generales, un límite práctico para multivalues ??nonlinked en un registro es de aproximadamente 1.200. Estas cifras se proporcionan sólo señalan que el tamaño máximo de un objeto es algo mayor en Windows Server 2003 y posteriores".

Entonces, si tenemos un dominio de Active Directory corriendo todo sobre Windows Server 2003 o superior, entonces un límite "práctico" para los atributos no vinculados de valores múltiples debe ser de aproximadamente 1.200 valores.

Así que vamos a poner esto a prueba, ¿de acuerdo?

Se encuentra disponible en el sitio de Microsoft un script de prueba rápida y sucia con PowerShell que generaría una cadena de 8 caracteres al azar de un grupo de caracteres (es decir, es un usuario ficticio al azar,) y luego añade el ID de usuario al azar al atributo memberUid de un grupo de seguridad, en un bucle hasta que el script se encuentra con un error porque el guión no puede añadir más valores:

# This script is for testing purposes only!
$ValidChars = @(‘a’, ‘b’, ‘c’, ‘d’, ‘e’, ‘f’, ‘g’, ‘h’, ‘i’, ‘j’,
‘k’, ‘l’, ‘m’, ‘n’, ‘o’, ‘p’, ‘q’, ‘r’, ‘s’, ‘t’,
‘u’, ‘v’, ‘w’, ‘x’, ‘y’, ‘z’, ‘A’, ‘B’, ‘C’, ‘D’,
‘E’, ‘F’, ‘G’, ‘H’, ‘I’, ‘J’, ‘K’, ‘L’, ‘M’, ‘N’,
‘O’, ‘P’, ‘Q’, ‘R’, ‘S’, ‘T’, ‘U’, ‘V’, ‘W’, ‘X’,
‘Y’, ‘Z’, ‘0’, ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, ‘7’,’8′, ‘9’)

[String]$Str = [String]::Empty
[Int]$Bytes = 0
[Int]$Uids = 0
While ($Uids -LT 1000000)
{
$Str = [String]::Empty
1..8 | % { $Str += ($ValidChars | Get-Random) }
Try
{
Set-ADGroup ‘TestGroup’ -Add @{ memberUid = $Str } -ErrorAction Stop
}
Catch
{
Write-Error $_.Exception.Message
Write-Host "$Bytes bytes $Uids users added"
Break
}
$Bytes += 8
$Uids += 1
}

Aquí el resultado del script:

Aproximadamente 1.200 usuarios antes de llegar al "límite administrativo", al igual que el artículo sugiere. Una forma de moverse por tamaño máximo de este atributo sería utilizar grupos anidados, o para romper los ID de usuario separados en dos grupos separados, aunque esto puede hacer que usted tenga que cambiar algo de código en los sistemas UNIX.

Por lo general no es un buen día cuando uno se da cuenta de que existe este límite, por lo que es mejor que debe saberlo de antemano. Otro atributo en Active Directory que podría tener un límite similar es el atributo servicePrincipalName, como se puede leer en este artículo AskPFEPlat.

Espero les sea de interes y utilidad. Saludos. Roberto Di Lello