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:
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.
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.