El problema del límite de 64 bits ACL

Todos los objetos de Active Directory, y todos los objetos que se pueden proteger en un equipo local o en la red, tienen descriptores de seguridad para controlar el acceso a los objetos. Los descriptores de seguridad incluyen información acerca de quién posee un objeto, que puede acceder a él y de qué manera, y qué tipos de acceso son auditados. Los descriptores de seguridad, a su vez, contiene la lista de control de acceso (ACL) de un objeto, que incluye todos los permisos de seguridad que se aplican a dicho objeto. Descriptor de un objeto de seguridad puede contener dos tipos de ACL:

• Una lista de control de acceso discrecional (DACL) que identifica a los usuarios y grupos a quienes se permite o deniega el acceso
• Una lista de control de acceso al sistema (SACL) que controla la forma de acceso es auditado

En muchos casos, conseguir aparece el error "The parameter is incorrect" en los logs de search de Sharepoint Microsoft dice que: "Este comportamiento se produce si el tamaño de la lista de control de acceso (ACL) es mayor de 64 kilobytes (KB). El tamaño máximo del búfer de la función InitializeAcl es de 64 KB. Por lo tanto, el tamaño máximo de un ligamento cruzado anterior de Windows, incluyendo las entradas de control de acceso (ACE) que se contienen en la ACL, es de 64 KB. "http://support.microsoft.com/kb/885482

-Ámbitos de Seguridad - Cada vez que rompemos la herencia en un elemento de la lista, una carpeta o sub-web, que crear un ámbito nuevo de seguridad que cubra ese elemento y sus hijos hasta llegar a un nuevo elemento con la herencia rota.
- (ACL Access Control Lists) - Cada Alcance de Seguridad tendrá un ligamento cruzado anterior, esto es básicamente una estructura de datos que contendrá una lista de ACE.
- ACE - (Entidades de Control de Acceso) - Cada ACE contiene un identificador de un usuario o grupo y una lista de los permisos que tiene este usuario.

Sharepoint utiliza ACL para las cuestiones de seguridad. Y esta limitación no es en realidad un límite de SharePoint. Se trata de un límite del sistema operativo. Si se supera el límite, el cálculo de las entidades de seguridad no funciona y causa anomalías. Uno de ellos es que no permite sitios o lanzar errores del tipo "The parameter is incorrect".

Para SharePoint 2010 se debe considerar dos límites:

1) "Alcance o scope de Seguridad: El número máximo de los ámbitos de seguridad únicas establecidas para obtener una lista no debe superar los 1.000.
Un ámbito es el límite de seguridad para un objeto asegurable y cualquiera de sus hijos que no tienen un límite de seguridad por separado definido. Un ámbito de aplicación contiene una lista de control de acceso (ACL), pero a diferencia de ACL de NTFS, un ámbito puede incluir entidades de seguridad que son específicos de SharePoint Server.Los miembros de una ACL para un ámbito pueden incluir los usuarios de Windows, cuentas de usuario que no sean usuarios de Windows (por ejemplo, las formas basadas en las cuentas), los grupos de Active Directory, o grupos de SharePoint. " http://technet.microsoft.com/en-us/library/cc262787.aspx .

Para SharePoint 2010 "superar los 1000 ACE" es sólo un umbral. Dependiendo del tamaño de la ACE no hay límite de cuentas estricta. Debe ser entre 1820 - 2000 ACE.

Utilizando esta consulta se puede identificar la cantidad de entidades de seguridad (ACE) por alcance o scope (ACL):

 

   1:  select COUNT(ra.PrincipalId) as [Count],p.ScopeUrl

   2:  from RoleAssignment ra with(nolock)

   3:  join Perms p with(nolock) on p.SiteId = ra.SiteId and p.ScopeId = ra.ScopeId

   4:  group by p.ScopeUrl

   5:  order by [Count] desc

Como se puede ver en los resultados que el alcance de "Planing" contiene 370 entidades. Estos pueden ser grupos o usuarios añadidos de forma directa

Mira los siguientes escenarios:

(1) Si hay 369 usuarios directamente añadidos y un grupo de SharePoint que contiene 5.000 usuarios lo que  excede el límite total de ese ámbito! (Recuento total  sería de 5.369!)

(2) Si hay 369 usuarios directamente añadidos y un grupo de SharePoint que contiene un grupo de AD con 400.000 usuarios no excede el límite total de ese ámbito! (Recuento total sería sólo de 370!)

Usando la siguiente consulta se puede identificar cuántos usuarios están en sus grupos de SharePoint disponibles:

   1:  select COUNT(m.MemberId) as [Count], g.Title as [Group-Title]

   2:  from GroupMembership m with(nolock)

   3:  join Groups g with(nolock) on m.GroupId = g.ID and m.SiteId = g.SiteId

   4:  group by g.Title

   5:  order by [Count] desc

 

Hay dos grupos de SharePoint que son de nuestro interés.

1289 Performace Management System.
1050 Quality Team Members .

Utilizando uno de estos grupos en cualquiera de sus sitios (= ScopeUrl) puede provocar el error de rastreo "El parámetro es incorrecto" que mencioné anteriormente.

La solución:
1) Definir grandes grupos de SharePoint.
2) Crear un grupo de seguridad de AD para cada uno
3) Mueva los usuarios del grupo de SharePoint al grupo de AD
4) Agregar este grupo de AD a su grupo de SharePoint en lugar de agregar usuarios uno por uno.

 

Problemas de performance:

Tener una infraestructura complejha, causa problemas de performance.

Imaginemos que tenemos una lista muy grande (decenas de miles de items)y estamos tratando de obtener información acerca de todos los elementos de la lista. Parte de los store procedure que se ejecutan será obtener sólo los elementos que los usuarios pueden ver. Esto significa que tenemos que procesar las ACL para todos los ámbitos de seguridad en esa lista. Debido a que consultar listas muy grandes, que son en su mayoría también se enfrentan a una escalada de bloqueos en SQL. Esto significa que tenemos una gran cantidad de recursos (y también de tiempo) de consultas que mantendrá la tabla AllUserData bloqueada, lo cual es un problema.

¿Cómo sabes que tienes este tipo de problemas:
- Algunas operaciones están tomando mucho tiempo: ver una lista en la interfaz de usuario, que muestra ciertos elementos de la lista.
- Bloqueos de SQL están bloqueando el portal.
- Los clientes de Office se ven afectados por el mal desempeño

Con el fin de evitar estos problemas, se aconseja las siguientes limitaciones:

 

ACL size	select   ScopeUrl,datalength(Acl) as DataLenght ,cast(dbo.fn_ChangeEndian4(SUBSTRING(Acl,1,16))as int) as AceCount from   Perms with (nolock) order by 2 desc	AceCount debería estar debajo de 900
Número de scopes de seguridad	SELECT alld.listid, alll.tp_title, allw.FullUrl, COUNT(DISTINCT alld.ScopeId) as countscopes FROM   ALLDOCS AS ALLD WITH(NOLOCK) INNER JOIN   ALLLISTS AS ALLL ON   ALLD.LISTID =   ALLL.TP_ID inner join Webs as allw on alld.WebId = allw.Id WHERE LISTID IS NOT NULL Group by alld.ListId, alll.tp_Title, allw.FullUrl order by   countscopes desc	Count debería estar debajo de 1000
Número de usuarios de AD y grupos de Sharepoint	select COUNT(m.MemberId) as [Count], g.Title as [Group-Title] from GroupMembership m with(nolock) join Groups g with(nolock) on m.GroupId = g.ID and m.SiteId = g.SiteId group by g.Title order by [Count] desc	~2500

Fuente:

http://blog.bugrapostaci.com/2011/08/01/how-to-fix-64bit-acl-limit-exceeded-problem-on-sharepoint/

http://blogs.msdn.com/b/spblog/archive/2012/03/13/security-infrastructure-related-performance-problems.aspx

http://blogs.msdn.com/b/arvind7in/archive/2010/05/26/what-is-64k-acl-limit.aspx