Rechte für das Verschieben von Computerobjekten aus der Standard Computer OU
Hi.
Kann mir jemand verraten wie ich es hinbekomme, einer AD-Gruppe nur die Rechte zum Verschieben von Computerobjekten zu geben?
Also Computerkonten die standardmässig immer in der OU "Computers" landen, sollen von ausgewählten Usern verschoben werden können.
Jedes mal bekomme ich nämlich die Meldung "Zugriff verweigert"
Habe für die AD-Gruppe schon die Rechte "Computerobjekte erstellen und löschen" vergeben, aber das reicht wohl nicht aus.
Die Standard AD-Gruppe "Konten-Operatoren" erfüllt zwar den Zweck, hat aber zuviele Rechte.
Wäre schön wenn mir da jemand helfen könnte.
Vielen Dank
Kann mir jemand verraten wie ich es hinbekomme, einer AD-Gruppe nur die Rechte zum Verschieben von Computerobjekten zu geben?
Also Computerkonten die standardmässig immer in der OU "Computers" landen, sollen von ausgewählten Usern verschoben werden können.
Jedes mal bekomme ich nämlich die Meldung "Zugriff verweigert"
Habe für die AD-Gruppe schon die Rechte "Computerobjekte erstellen und löschen" vergeben, aber das reicht wohl nicht aus.
Die Standard AD-Gruppe "Konten-Operatoren" erfüllt zwar den Zweck, hat aber zuviele Rechte.
Wäre schön wenn mir da jemand helfen könnte.
Vielen Dank
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3526935936
Url: https://administrator.de/forum/rechte-fuer-das-verschieben-von-computerobjekten-aus-der-standard-computer-ou-3526935936.html
Ausgedruckt am: 26.12.2024 um 09:12 Uhr
16 Kommentare
Neuester Kommentar
Hi,
ich würde Dir einen anderen Ansatz empfehlen.
Erstelle eine Gruppe für die betreffenden Benutzer.
Verweigere(!) der Gruppe, im Container "Computers" Computerobjekt erstellen zu können.
Dann gewähre der Gruppe das Recht, in der gewünschten OU Computerobjekte erstellen zu können (nur das Erstellen).
Jetzt können die Mitglieder dieser Gruppe Computer nur noch dann der Domäne beitreten lassen, wenn sie vorher ein entsprechendes Computerobjekt in der gewünschten OU erstellt haben.
E.
ich würde Dir einen anderen Ansatz empfehlen.
Erstelle eine Gruppe für die betreffenden Benutzer.
Verweigere(!) der Gruppe, im Container "Computers" Computerobjekt erstellen zu können.
Dann gewähre der Gruppe das Recht, in der gewünschten OU Computerobjekte erstellen zu können (nur das Erstellen).
Jetzt können die Mitglieder dieser Gruppe Computer nur noch dann der Domäne beitreten lassen, wenn sie vorher ein entsprechendes Computerobjekt in der gewünschten OU erstellt haben.
E.
Wie wäre es denn, wenn die PCs automatisch verschoben werden, basierend auf Ihrem Namen?
Beispiel: Ein neuer PC wird erstellt und heißt workstationmueller. Wie alle Workstations soll er in die OU "Workstations" geschoben werden. Dazu kannst Du am DC ein kleines Skript etablieren, das sogar automatisch losläuft, sobald der PC zur Domäne hinzugefügt wird:
Beispiel: Ein neuer PC wird erstellt und heißt workstationmueller. Wie alle Workstations soll er in die OU "Workstations" geschoben werden. Dazu kannst Du am DC ein kleines Skript etablieren, das sogar automatisch losläuft, sobald der PC zur Domäne hinzugefügt wird:
$newmachine=(Get-WinEvent -FilterHashtable @{Logname='Security'; ID=4741} -MaxEvents 1 | ForEach-Object {
$xml = [xml]($_.ToXml() -replace 'xmlns=', 'dummy=')
$_ | Select-Object -Property `
TimeCreated,
Id,
@{n='DnsHostName'; e={$xml.SelectSingleNode("Event/EventData/Data[@Name='DnsHostName']").InnerText}}
}).DnsHostName
$a, $b, $c = $newmachine.Split(".")
if ($a -like "Workstation*") {dsmove "CN=$a,CN=Computers,DC=dom,DC=local" -newparent ou=Workstations,DC=dom,DC=local}
#muesste als Task am DC laufen.
#Executor: System
#Action: dieses Skript
#Trigger:Logname='Security'; Source: Microsoft Windows security auditing", ID=4741
#Zweck in diesem Beispiel: alle PCs die mit dem Namen Workstationxyz erstellt werden, werden sofort in die OU Workstations geschoben.
Servus.
Und noch effektiver machst du das Skript indem du im Tasktrigger die Daten direkt an das Skript übergibst, dann entfällt das zusätzliche Abfragen per Get-WinEvent und die Zuordnung ist eindeutig, hier findest du ein Beispiel von mir dafür
ValueQueries im TaskTrigger
Ich würde die Computer ja beim Joinen gleich in die richtige OU pushen und das Erstellen im Computers-Container unterbinden, bzw. den Default-Container ändern falls das das Ziel des TO war.
Nur um noch die Frage des TO trotzdem noch zu beantworten. Neben den Create und Delete Rechten für die Container braucht es Write-Rechte auf die Attribute der Computer-Objekte, denn ein paar davon, unter anderen der DN wird beim Verschieben neu geschrieben.
Grüße Uwe
Zitat von @DerWoWusste:
Wie wäre es denn, wenn die PCs automatisch verschoben werden, basierend auf Ihrem Namen?
Beispiel: Ein neuer PC wird erstellt und heißt workstationmueller. Wie alle Workstations soll er in die OU "Workstations" geschoben werden. Dazu kannst Du am DC ein kleines Skript etablieren, das sogar automatisch losläuft, sobald der PC zur Domäne hinzugefügt wird:
Wie wäre es denn, wenn die PCs automatisch verschoben werden, basierend auf Ihrem Namen?
Beispiel: Ein neuer PC wird erstellt und heißt workstationmueller. Wie alle Workstations soll er in die OU "Workstations" geschoben werden. Dazu kannst Du am DC ein kleines Skript etablieren, das sogar automatisch losläuft, sobald der PC zur Domäne hinzugefügt wird:
Und noch effektiver machst du das Skript indem du im Tasktrigger die Daten direkt an das Skript übergibst, dann entfällt das zusätzliche Abfragen per Get-WinEvent und die Zuordnung ist eindeutig, hier findest du ein Beispiel von mir dafür
ValueQueries im TaskTrigger
Ich würde die Computer ja beim Joinen gleich in die richtige OU pushen und das Erstellen im Computers-Container unterbinden, bzw. den Default-Container ändern falls das das Ziel des TO war.
Nur um noch die Frage des TO trotzdem noch zu beantworten. Neben den Create und Delete Rechten für die Container braucht es Write-Rechte auf die Attribute der Computer-Objekte, denn ein paar davon, unter anderen der DN wird beim Verschieben neu geschrieben.
Grüße Uwe
Zitat von @Beny11:
Weisst du vielleicht genau, welche Attribute bei den Computer Objekten noch berechtigt werden müssten, damit man es ohne Fehlermeldung verschieben kann !?
Weisst du vielleicht genau, welche Attribute bei den Computer Objekten noch berechtigt werden müssten, damit man es ohne Fehlermeldung verschieben kann !?
distinguishedName (Distinguished Name)
rdn (name)
cn (Name)
Ich gehe immer über die GUI und dann über Sicherheit.
Wie gesagt die Property kannst du über die GUI nicht berechtigen. Da musst du wenn du eine GUI willst bswp. die ldp.exe nehmen.Der folgende PS Schnippsel klappt hier im Test einwandfrei (OUs und Gruppe anpassen) um von der Computers-OU Computer-Objekte in Richtung der Ziel-OU zu verschieben (nicht zurück) und sonst sind keine weiteren Aktionen möglich, auch nicht das Ändern von weiteren Attributen der Computer.
Import-Module ActiveDirectory
# --------------
# QUELL OU
$OU_SOURCE = "AD:CN=Computers,DC=TESTLAB,dc=INTERN"
# ZIEL OU
$OU_TARGET = "AD:OU=Verwaltung,DC=TESTLAB,dc=INTERN"
# Gruppe / Account
$account = [System.Security.Principal.NTAccount]"TESTLAB\mygroup"
# --------------
$acl_source = Get-ACL $OU_SOURCE
$acl_target = Get-ACL $OU_TARGET
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"Self,WriteProperty",'Allow','{bf9679e4-0de6-11d0-a285-00aa003049e2}','Descendents','{bf967a86-0de6-11d0-a285-00aa003049e2}')),
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"Self,WriteProperty",'Allow','{bf96793f-0de6-11d0-a285-00aa003049e2}','Descendents','{bf967a86-0de6-11d0-a285-00aa003049e2}')),
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"Self,WriteProperty",'Allow','{bf967a0e-0de6-11d0-a285-00aa003049e2}','Descendents','{bf967a86-0de6-11d0-a285-00aa003049e2}')),
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"DeleteChild",'Allow','{bf967a86-0de6-11d0-a285-00aa003049e2}','None',[guid]::Empty)) | %{
$acl_source.AddAccessRule($_)
}
Set-ACL $OU_SOURCE $acl_source
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"CreateChild",'Allow','{bf967a86-0de6-11d0-a285-00aa003049e2}','None',[guid]::Empty)),
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"Self,WriteProperty",'Allow','{bf9679e4-0de6-11d0-a285-00aa003049e2}','Descendents','{bf967a86-0de6-11d0-a285-00aa003049e2}')),
(New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($account,"Self,WriteProperty",'Allow','{bf96793f-0de6-11d0-a285-00aa003049e2}','Descendents','{bf967a86-0de6-11d0-a285-00aa003049e2}')) | %{
$acl_target.AddAccessRule($_)
}
Set-ACL $OU_TARGET $acl_target
Quell OU DACLs (ldp.exe)
Ziel OU DACLs (ldp.exe)
Works as designed .
Grüße Uwe
Hab das mal testweise ausprobiert, klappt wie Colinardo schreibt auch hier wie gewünscht... 👌
Tjo, hätte man einfach das Skript bemüht 😉, hätte man nicht mit GUIs rum futeln müssen ...