Problemas con New-Adgroup, Set-ACL y carpetas de red

Question

Estoy jugando con un código de PowerShell para generar dinámicamente grupos de seguridad de anuncios y luego aplicarlos a carpetas en un recurso compartido de red, pero tener problemas con la resolución del grupo recién creado.

Considere esto:

import-module activedirectory

for ($i = 0; $i -lt 10; $i++) {

  $group = New-ADGroup -Path "OU=Groups,OU=Department,DC=Domain,DC=Network" -Name "z-test-group-$i" -GroupScope DomainLocal -GroupCategory Security -PassThru
  $acl = Get-Acl C:\Temp
  $permission = $group.SID,"FullControl","Allow"
  $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
  $acl.SetAccessRule($accessRule)
  $acl | Set-Acl C:\Temp

}

que funciona bien.

Sin embargo, si cambio la carpeta a una carpeta de red, como G: \ TEMP, OR \\ DOMING.NETWORK \ DFS \ GROUPSHARE \ TEMP, obtengo un método 'fallido con un código de error inesperado 1337'.

Me cansé de usar setacl.exe y recibí un error similar:

C:\Temp\SetACL.exe -on "\\domani.network\dfs\GroupShare\Temp" -ot file -actn ace -ace "n:$GroupSID;p:full;s:y"

SetACL finished with error(s): 
SetACL error message: The call to SetNamedSecurityInfo () failed
Operating system error message: The security ID structure is invalid.
INFORMATION: Processing ACL of: <\\?\UNC\domain.network\dfs\GroupShare\Temp>

Si espero, diga 10 a 20 segundos, y ejecute nuevamente la parte de SET-ACL (o SetAcl.exe), se completa con éxito.

Al principio, pensé que esto estaba relacionado directamente con los controladores de dominio (4 de ellos, que son una combinación de 2003 y 2008 R2), pero el hecho de que funcionaba bien en las carpetas locales era intrigante (y molesto).

Hice un rastreo de Wireshark durante la ejecución del código en una carpeta local y luego una carpeta de red. La principal diferencia es cuando se intenta aplicar las ACL a la carpeta de red, veo las miradas LDAP y (entre otras cosas) la siguiente respuesta de SMB:

NT Trans Response, FID: 0x0040, NT SET SECURITY DESC, Error: STATUS_INVALID_SID

Lo que asumo es lo que hace que mi comando Set-ACL falle.

El sistema de archivos de red subyacente es EMC Celerra 6.0.xx. Sin embargo, estoy muy desconocido con esta tecnología, sin embargo, a partir de lo que entiendo, tiene algún tipo de caché SID, lo que explicaría el error anterior (todavía no se conoce del nuevo grupo, aunque el anuncio).

, así que supongo que hay dos preguntas:

1. existe de alguna manera alrededor de esto (PowerShell / C # ECT) que no ¿Implica dormir / esperar? Es decir, configure la ACL aunque el SID sea ¿inválido?
2. Si EMC Celerra es el problema (asumo que lo es), ¿hay alguna ¿Cómo puedo forzarlo a actualizar su 'Cache SID' o lo que sea que pueda ser?

Tengo leer VARIOS artículos sobre este tema , pero ninguno parece tener una resolución efectiva (o trabajar para mí).

Gracias por su ayuda.

rhys.

Answer 1

¡Lo descubrió!

modificó la acl.mappingerroraction en nuestra EMC CELERRA NAS.

se estableció en 0, se actualizó a 1.

server_param server_2 -facility cifs -modify acl.mappingerroraction -Value 1

Ahora no tenemos problemas para establecer el grupo de seguridad recién creado en las ACL para la carpeta en una red compartida (sin demoras).

---

info: acl.mappingerroraction

Define las reglas para el mapeo desconocido entre la seguridad, el usuario y los identificadores de grupo (SID / UID / GID) en la configuración de ACL.

puede ocurrir dos tipos de errores: Se desconoce el SID en la ACL para los controladores de dominio que se están utilizando. El nombre de usuario aún no se asigna a un UID / GID.

La lista de bits consta de cuatro bits binarios (bits 0 a 3, derecha a izquierda). Cada bit es 1 cuando se establece; de lo contrario 0.

Bit 0 (0001 or +1): Store unknown SID.
Bit 1 (0010 or +2): Store SID with no UNIX mapping.
Bit 2 (0100 or +4): Enable debug traces.
Bit 3 (1000 or +8): Do lookup only in cache (secmap or global SID cache or per connection SID cache).

Valores: 0 - 15 Predeterminado: 0

---

Parece lo suficientemente obvio ahora que entiendo más sobre la configuración subyacente de CIFS / ACL en la NAS, entonces alguna vez quise saber.

rhys.

Answer 2

Si el problema es solo la demora involucrada en la espera de que el caché actualice el bloqueo de otro trabajo. La secuencia de comandos debe hacerlo podría enviarlo a un trabajo de fondo y dejar que su script principal continúe a otras cosas.