Jump to content

NTFS Berechtigungen setzen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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.

Link zu diesem Kommentar

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

 

Link zu diesem Kommentar

'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 von BOfH_666
Link zu diesem Kommentar

@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 von Sunny61
Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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 von MurdocX
Link zu diesem Kommentar

@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 von Sunny61
Link zu diesem Kommentar

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

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...