NTFS Berechtigungen setzen

[Sunny61 806]

Hallo zusammen,

 

beim Versuch NTFS-Berechtigungen auf per Script neu erstellte Ordner zu setzen, bekomme ich beim folgenden Code die ebenfalls folgende Fehlermeldung:

 

# Code ist nicht von mir, copy + paste aus dem Netz

 

$Folder = "\\DomB.local\Daten\Teilnehmer\Name\Nummer"

$Gruppe = "DomB.local\ACC_TNG_Nummer_DL"

 

$acl = Get-Acl $Folder

$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($Gruppe, "FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")

$acl.SetAccessRule($AccessRule)

$acl | Set-Acl $Folder

 

Fehlermeldung beim $acl.SetAccessRule($AccessRule):

 

Ausnahme beim Aufrufen von "SetAccessRule" mit 1 Argument(en):  "Manche oder alle Identitätsverweise konnten nicht übersetzt werden."

 

Der ausführende User ist in DomA angemeldet und hat in DomB auf dem Ordner die entsprechenden Rechte um die Berechtigungen hinzufügen. Tausche ich den Namen der Gruppe gegen die SID der Gruppe bekomme ich die gleiche Fehlermeldung. Auch wenn ich die DomB.local weglasse kommt die gleiche Fehlermeldung. Trage ich einen Benutzer ein, funktioniert es.

 

Hat jemand noch eine Idee wie man das lösen kann?

 

Vielen Dank schon im Voraus.

 

BTW: Es gibt ja auch von Raimund Andrée File System Security PowerShell Module: https://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85

das hab ich auch ausprobiert, funktioniert nur mit der SID, nicht mit dem Namen der Gruppe. Ja, man kann natürlich die SID zum Namen auslesen, aber es sollte ja eigentlich auch nur mit dem Namen funktionieren. Beim User geht es ja auch.

[NilsK 2.934]

Moin,

 

ich stolpere darüber, dass du die NetBIOS-Schreibweise für den Namen mit dem DNS-Domänennamen verwendest. Das funktioniert manchmal, aber manchmal auch nicht. Ich nehme mal nicht an, dass der NetBIOS-Name "DomB.local" ist, sondern eher "DOMB", oder?

 

Ansonsten würde ich persönlich Berechtigungen per Skript nur mit SetACL setzen. Vielleicht wäre man da aber auf dasselbe Problem gestoßen.

 

Gruß, Nils

 

[BOfH_666 577]

'is vielleicht ne blöde Idee, aber die Fehlermeldung ist auf Deutsch und die von Dir benutzten "Identitätsverweise" sind English. Lass Dir doch die ausgelesene $ACL mal ausgeben. Sind da auch Englishe Namen drin oder sind die auf Deutsch?   Ich bin auch schon mal über "Everyone" und "Jeder" gestolpert.   

bearbeitet 4. Juni 2020 von BOfH_666

[Sunny61 806]

@NilsK

Ja, der NetBIOS-Name der Domain ist DOMB, ich hab es schon mit allen Varianten probiert.

 

@BOfH_666

Mit dem Tool von Raimund hat es ja mit den Begriffen in englisch funktioniert, allerdings nur mit der SID. Hmm, ich schau mir die Ausgabe morgen nochmal an. Und bei einem Benutzer funktioniert es ja auch mit den englischen Begriffen.

bearbeitet 4. Juni 2020 von Sunny61

[testperson 1.677]

Hi,

 

ich kann auch nur zu SetACL, icacls oder SubInACL raten. Ich habe nach mehreren Anläufen sämtliche Versuche in PowerShell aufgegeben. Das "Problem" kann da aber auch an mir liegen. ;)

 

Gruß

Jan

[NilsK 2.934]

Moin,

 

Falscher Gruppentyp?

 

Gruß, Nils

[Sunny61 806]

@Nilsk

Anderen Gruppentyp hab ich auch schon probiert. Morgen teste ich nochmal was, wenn das nichts hilft, dann wird umgestiegen.

 

Danke bisher für die Unterstützung. :)

[NilsK 2.934]

Moin,

 

Und wenn du das Skript als User aus der Zieldomäne ausführst?

 

Gruß, Nils

[daabm 1.354]

Die Meldung ist doch eindeutig - im Ausführungskontext des Skripts (Computer/User) kann DomB.local\ACC_TNG_Nummer_DL nicht in eine SID aufgelöst werden... warum kann jetzt nur der TO herausfinden. psgetsid wäre ein Ansatz, dsquery ginge auch. Oder get-adgroup oder sonstwas, was sich AD-Objekte holt.

[Sunny61 806]

vor 9 Stunden schrieb NilsK:

Und wenn du das Skript als User aus der Zieldomäne ausführst?

Das kann ich probieren, ist aber später auch nicht so angedacht.

vor 7 Stunden schrieb daabm:

Die Meldung ist doch eindeutig - im Ausführungskontext des Skripts (Computer/User) kann DomB.local\ACC_TNG_Nummer_DL nicht in eine SID aufgelöst werden... warum kann jetzt nur der TO herausfinden. psgetsid wäre ein Ansatz, dsquery ginge auch. Oder get-adgroup oder sonstwas, was sich AD-Objekte holt.

Und wenn ich eine SID nehme wird die gleiche Meldung ausgegeben, also kann es das nicht sein.

[NilsK 2.934]

Moin,

 

Geht es denn mit dem SID eines Users? Wenn nein, arbeitet die Methode nicht mit SID. Wenn ja, muss es ja doch an der Gruppe liegen.

 

Was sind denn die Eigenschaften der Gruppe?

 

Gruß, Nils

[MurdocX 952]

vor 9 Stunden schrieb daabm:

Die Meldung ist doch eindeutig - im Ausführungskontext des Skripts (Computer/User) kann DomB.local\ACC_TNG_Nummer_DL nicht in eine SID aufgelöst werden...

Bin der gleichen Meinung.

 

Ich hab mich eine Zeit lang mit dem Thema intensiv beschäftigt und poste jetzt meine geschriebene gekürzte produktiv Interna. Mit Absicht hab ich die unteren ACL-Set´s drin gelassen, damit du (und andere) die als Vorlage verwendet werden kannst/können.

 

Der Fehler kommt, wenn:

• Der DC das Objekt nicht findet
• Die Replikation zum anderen DC noch aussteht und er deshalb dort das Objekt nicht findet
• Er es nicht abrufen darf

 

Alles Weitere hilft Dir nicht direkt, zeigt aber Möglichkeiten für die Berechtigung und dem Umgang mit NT-Account und auflösen der SID für Tests. (Das Skript wurde aus dem Kontext gerissen und oben angepasst, sollte aber soweit passen)

 

Das Skript macht folgendes:

1. Generiert einen NT-Account
2. Ruft die SID ab ( versucht das mehrmals, denn die Replikation ist meist noch nicht durch )
3. Baut die ACL
4. Fügt diese zum RuleSet hinzu
5. Set die ACL

 

Wichtig: Es ist zu unterscheiden, ob eine Berechtigung auf eine Datei oder einen Ordner gesetzt wird.

 

$beispielDomain = "zielDomain.local"
$beispielName = "meineDomain\IchBinUser"

$objAdNtAccount_RWGroup = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList ( $beispielDomain, $beispielName )

# INIT-Do
$Ende = $false
$Trys = 1
      
do
{
    # Versuche den Abruf so lange, bis es klappt
        
    try
    {
        # Get Group SID
        Write-Verbose -Message "Versuch $Trys von 10, um die SID vom DC abzurufen..."
        $strAdRwGroupSID = $objAdNtAccount_RWGroup.Translate([Security.Principal.SecurityIdentifier])

        # Schleifen abbruch  
        $Ende = $true
    }
    catch
    {
        # Error is happened, try again!
        $Ende = $false
        $Trys++
        Start-Sleep -Seconds 6
          
        if ($Trys -gt 10)
        {
            # Abbruchbedingung OK, kein Auflösen möglich
            Write-Verbose -Message "[New-PoProjekt] Fehler: $_"
            Write-Warning -Message '[New-PoProjekt] Abbruch, da die SID vom DC nicht abgerufen werden konnte!'
            Break
        }
    }
}
while ($Ende -eq $false)


#
# Create ACL-Rule
#

# Null setzen
$objDirectoryAceRuleRW = $null
$objDirectoryAceRuleR = $null

# ACL - Ordner - Berechtigung 'ReadAndExecute' auf oberster Ebene
[System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleRW = [System.Security.AccessControl.FileSystemAccessRule]::new(`
    $strAdRwGroupSID,`
    [System.Security.AccessControl.FileSystemRights]::ReadAndExecute -bor [System.Security.AccessControl.FileSystemRights]::Write,`
    [System.Security.AccessControl.InheritanceFlags]::None,`
    [System.Security.AccessControl.PropagationFlags]::NoPropagateInherit,`
    [System.Security.AccessControl.AccessControlType]::Allow `
)

# ACL - Ordner - Berechtigung 'Modify' NUR auf Unterordner und Dateien
[System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleRW2 = [System.Security.AccessControl.FileSystemAccessRule]::new(`
    $strAdRwGroupSID,`
    [System.Security.AccessControl.FileSystemRights]::Modify,`
    [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit,`
    [System.Security.AccessControl.PropagationFlags]::InheritOnly,`
    [System.Security.AccessControl.AccessControlType]::Allow `
)
      
#  ACL - Ordner - Berechtigung 'ReadAndExecute' NUR auf Unterordner und Dateien
[System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleR = [System.Security.AccessControl.FileSystemAccessRule]::new(`
    $strAdRGroupSID,`
    [System.Security.AccessControl.FileSystemRights]::ReadAndExecute,`
    [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit,`
    [System.Security.AccessControl.PropagationFlags]::None,`
    [System.Security.AccessControl.AccessControlType]::Allow `
)
     
# ACL - Dateien - Berechtigung 'Modify' aber ohne 'Delete' 
[System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleMgr = [System.Security.AccessControl.FileSystemAccessRule]::new(`
    $strAdMgrGroupSID,`
    [System.Security.AccessControl.FileSystemRights]::ReadAndExecute -bor [System.Security.AccessControl.FileSystemRights]::WriteData -bor `
    [System.Security.AccessControl.FileSystemRights]::AppendData -bor [System.Security.AccessControl.FileSystemRights]::WriteAttributes -bor `
    [System.Security.AccessControl.FileSystemRights]::WriteExtendedAttributes, `
    [System.Security.AccessControl.InheritanceFlags]::None ,`
    [System.Security.AccessControl.PropagationFlags]::None,`
    [System.Security.AccessControl.AccessControlType]::Allow `
)

#  ACL - Dateien - Berechtigung 'ReadAndExecute'
[System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleMgr2 = [System.Security.AccessControl.FileSystemAccessRule]::new(`
    $strAdMgrGroupSID,`
    [System.Security.AccessControl.FileSystemRights]::ReadAndExecute,`
    [System.Security.AccessControl.InheritanceFlags]::None,`
    [System.Security.AccessControl.PropagationFlags]::None,`
    [System.Security.AccessControl.AccessControlType]::Allow `
)

## Setzen der Berechtigung auf den ProjektOrdner

# GET ACL Rule from File
$objDirectoryAceNow = Get-Acl -Path $ProjektPfad -ErrorAction Stop

# ADD New ACL Rule
$objDirectoryAceNow.AddAccessRule($objDirectoryAceRuleRW) 

# SET New ACL Rule to File
$objDirectoryAceNow | Set-Acl -Path $ProjektPfad -ErrorAction Stop

 

bearbeitet 5. Juni 2020 von MurdocX

[Sunny61 806]

@MurdocX

Vielen Dank für das Script, es hat mir sehr geholfen. Ich kann zwar als ausführender User der DomA, Accounts und Gruppen in DomB anlegen, aber wenn es um NTFS-Berechtigungen geht, wird zur Auflösung immer nur die DomA verwendet. Über die GUI kann ich die DomB auswählen. Auf der FW zwischen den beiden Doms ist auch alles in Butter.

@NilsK

Auch mit der SID eines Users die gleiche Fehlermeldung.

 

Es funktioniert nur, wenn eine Gruppe/SID/User aus der DomA verwendet wird. Führe ich das alles auf einem Rechner der DomB, angemeldet als User der DomA, aus, funktioniert alles wie gewünscht. Meine Vermutung: Intern wird immer mit der Domain gearbeitet, in der der benutzte Client beheimatet ist.

 

Wir arbeiten ab jetzt an den Scripten auf Rechnern der DomB mit Accounts aus der DomA. Falls jemand weitere Ideen hat, immer her damit, ich werde alles sehr gerne testen und Ergebnisse posten.

 

Vielen Dank für die rege und informative Beteilung und Unterstützung.

vor 12 Stunden schrieb daabm:

Oder get-adgroup oder sonstwas, was sich AD-Objekte holt.

Get-ADGroup bringt, 1 Zeile weiter oben, den CN der gewünschten Gruppe. Beispiel:

 

$Global:SRVGlobal="DomB.local"

Import-Module ActiveDirectory -ErrorAction Stop

#Zum 'Verbindungstest! Es werden alle DCs aus der DomB gelistet.

Get-ADDomainController -Server "DomB.local" -Filter *

 

$Folder = "\\DomB.local\Daten\Teilnehmer\Name\Nummer"

$Gruppe =  "DomB.local\ACC_TNG_Nummer_DL"

$Result = Get-ADGroup -Identity $Gruppe -Server $SRVGlobal

Write-Host $Result

#Es wird der CN der Gruppe gelistet.

bearbeitet 5. Juni 2020 von Sunny61

[daabm 1.354]

Grad mal kurz etwas geforscht - https://docs.microsoft.com/de-de/dotnet/api/system.security.accesscontrol.filesystemaccessrule.-ctor?view=dotnet-plat-ext-3.1#System_Security_AccessControl_FileSystemAccessRule__ctor_System_String_System_Security_AccessControl_FileSystemRights_System_Security_AccessControl_InheritanceFlags_System_Security_AccessControl_PropagationFlags_System_Security_AccessControl_AccessControlType_

Zitat: "Mit dem identity-Parameter muss ein gültiges Konto auf dem aktuellen Computer oder der aktuellen Domäne identifiziert werden." Dann dürfte es mit einem User statt einer Gruppe aber auch nicht gehen...

[Sunny61 806]

@daabm

Danke, den Artikel hatte ich bei meiner Suche nach einer Lösung/nach einem Hinweis auch gefunden.

Sobald es ein User/eine Gruppe aus der DomainA eingetragen wird, funktioniert es ja. Es sollen ja aber Gruppen aus DomainB eingetragen werden.

 

Wir haben das jetzt so wie ich in

 geschrieben habe gelöst. Damit können wir leben.