Issues With New-ADGroup, Set-ACL and Network Folde

问题:

I'm playing with some PowerShell code to dynamically generate AD security groups and then apply them to folders on a network share, but having issues with resolving the newly created group.

Consider this:

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

}

Which works fine.

However, if I change the folder to a network folder, such as G:\Temp, or \\domain.network\DFS\GroupShare\Temp, I get a 'Method failed with unexpected error code 1337'.

I tired using SetACL.exe and received a similar error:

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>

If I wait say 10 to 20 seconds, and run the Set-ACL (or SetACL.exe) portion of the code again, it completes successfully.

At first I thought this was related directly to the domain controllers (4 of them which are a mix of 2003 and 2008 R2), but the fact that it worked fine on local folders was intriguing (and annoying).

I did a Wireshark trace during the execution of the code on a local folder and then a network folder. The main difference is when trying to apply the ACLs to the network folder I see LDAP lookups and (amongst other things) the following SMB response:

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

Which I assume is what causes my Set-ACL command to fail.

The underlying network filesystem is EMC Celerra 6.0.xx. I am very unfamiliar with this technology, however from what I understand it holds some kind of SID cache which would explain the above error (it doesn't yet know of the new group even though AD does).

So I guess there are two questions:

1. Is there any way around this (PowerShell/C# ect) that doesn't involve sleeping/waiting? IE, set the ACL even though the SID is invalid?
2. If EMC Celerra is the issue (I assume it is), is there any way I can force it to update its 'SID cache' or whatever it may be?

I have read various articles about this issue, but none seem to have an effective resolution (or work for me).

Thanks for your help.

Rhys.

回答1:

If the issue is just the delay involved in waiting for the cache to update blocking other work the script needs to be doing you could ship that off to a background job and let your main script go on to other things.

回答2:

Figured it out!

Modified the acl.mappingErrorAction on our EMC Celerra NAS.

Was set to 0, updated it to 1.

server_param server_2 -facility cifs -modify acl.mappingErrorAction -value 1

Now we have no issues in setting the newly created security group into the ACLs for the folder on a network share (no delays).

---

Info: acl.mappingErrorAction

Defines the rules for unknown mapping between security, user, and group identifiers (SID/UID/GID) on ACL settings.

Two kinds of errors might occur: The SID set in the ACL is unknown to the domain controllers being used. The username is not yet mapped to a UID/GID.

The bit list consists of four binary bits (bits 0 through 3, right to left). Each bit is 1 when set; otherwise 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).

Values: 0 – 15 Default: 0

---

Seems obvious enough now that I understand more about the underlying CIFS/ACL settings on the NAS then I ever wanted to know.

Rhys.