Setting security rights on a group from other domain

Hey everyone,

My first script!

I’ve written my own script to obtain rights on a folder or file of a specific group, and give those exact same rights to a different group.

My script:


 $directory = "C:\Testshare\"
 
 $CSVLocation = "C:\scripts\Groupscsv.csv"
  
 <#Example CSV:
    SourceGroup;TargetGroup
    *SG-Office-Kit*;SG-PROD-Kit
    *SG-Office-Poeder*;SG-PROD-Poeder
    #>
 
 $Groups = (Import-csv $CSVLocation -Delimiter ";")
 
 $FolderChilds = Get-ChildItem $directory -Recurse
 
 foreach($Group in $Groups)
    {
    $SourceGroup = $Group.SourceGroup
    $TargetGroup = $Group.TargetGroup
 
        foreach($Folder in $FolderChilds)
        {
        $FolderACL = Get-Acl -Path $Folder.FullName
              
            If ($FolderACL.AccessToString -like $SourceGroup)
            {
               $Folderacl.Access | ForEach-Object {if ($_.identityReference.value -like $Sourcegroup)
               {
               $Ar = New-Object  system.security.accesscontrol.filesystemaccessrule($TargetGroup,$_.FileSystemRights,$_.InheritanceFlags,$_.PropagationFlags,$_.AccessControlType)
               $FolderACL.SetAccessRule($Ar)
                Set-Acl -Path $Map $FolderACL
                }
                
            write-host $TargetGroup "is now a member of" $Map "with the rights:" $_.FileSystemRights   
            }
         }      
    }
 }
 
 
 
 

It works great, when you’re only working with 1 domain.
Problem is, I’m working with two domains.
We have an office domain, and we have a production domain.
Our Fileserver is in the office domain.

I need to copy the rights from the office groups to the production groups.
If I execute my script on the fileserver it says the security groups do not exist, because it looks for the groups in the office domain instead of production domain.
If I execute my script from the DC of the production domain on \fileserver\share, it will still look for the groups on the office domain because the fileserver is member of the office domain.

Having looked for quite some time on the internet, I couldn’t find anything!
Jeffrey Snover told me to post here if I get stuck, so here goes :smiley:

Do you guys have any idea how to make it change location?

If you do not get what I’m trying to explain, here’s a different explanation:
When I’m on my DC in production domain and go to a share on the fileserver in the office domain and try to add a group or user on the security tab. You see the ‘From this location:’ field. That one is set to the Office domain because the fileserver lies in the Office Domain, eventhough I’m accessing the share from the production domain. If I try to give rights through Powershell, Powershell also tries to find the gruops in the Office domain. So I’m stuck because I don’t know how to make it add a group from a different domain.

From what I can see, you should be able to simply update your text file so instead of having “SG-PROD-Kit” for the TargetGroup, for example, it says “ProductionDomainName\SG-PROD-Kit”. Alternatively, you could prepend the "ProductionDomainName" string in your PowerShell code, if you prefer:

$TargetGroup = "ProductionDomainName\$($Group.TargetGroup)"

Hello Dave and thank you for answering.

I’ve actually already tried that. It still resulted in a fail because it tries to look for the group named:
ProductionDomainName\SG-PROD-Kit
in my office domain. :frowning:

Hmm, that’s not really how it works. When you pass a DOMAIN\Name format string to an AccessRule constructor, it should try to contact that domain to look up the name.

What error message, if any, do you get if you try to run this code (after replacing ‘ProductionDomainName’ with your actual domain name)?

$domainName = 'ProductionDomainName'
$groupName = 'Domain Admins'

$group = [System.Security.Principal.NTAccount] "$domainName\$groupName"

$group.Translate([System.Security.Principal.SecurityIdentifier])

If that code works, try changing ‘Domain Admins’ to ‘SG-PROD-Kit’ and see if it works as well. This simulates the process that has to happen behind the scenes when you pass a string to the FileSystemAccessRule constructor; the string has to be translated to a SID.

On my way home it hit me that I tried it with (example) Contoso\Groupname and not Contoso.local\Groupname.
Maybe that is what I did wrong :D.
If it doesn’t work, I’ll try what you asked me to do in your last post.

Thank you again.

I would like to thank you for your help Dave!
Changing the domainname to the full domainname (domainname.local) did the trick. You may not have actually said it, but you mentioning domainname\groupname made me think about it :slight_smile: .