11
PowerShell-Aktionen mit anderen Accounts ausführen
Heyho,
Ich möchte per PowerShell auf meinem Win2k8 SP1 - bzw von meinem APC - ein PowerShell-Script laufen
lassen, was den Besitz der Profilordner auf mich - oder andere Funktionsaccounts überträgt.
Da diese ganze WMI - TakeOwnership oder Set-ACL Geschichten funktionieren bei den Profilordnern irgendwie nicht.
Nun wäre meine Idee die Befehle vom Nutzer "System" oder von dem Besitzer ausführen zu lassen.
Gibt es da eine Möglichkeit oder hat wer noch andere Ideen?
Ich möchte per PowerShell auf meinem Win2k8 SP1 - bzw von meinem APC - ein PowerShell-Script laufen
lassen, was den Besitz der Profilordner auf mich - oder andere Funktionsaccounts überträgt.
Da diese ganze WMI - TakeOwnership oder Set-ACL Geschichten funktionieren bei den Profilordnern irgendwie nicht.
Nun wäre meine Idee die Befehle vom Nutzer "System" oder von dem Besitzer ausführen zu lassen.
Gibt es da eine Möglichkeit oder hat wer noch andere Ideen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 213220
Url: https://administrator.de/contentid/213220
Printed on: April 19, 2024 at 09:04 o'clock
11 Comments
Latest comment
Moin,
warum brauchst du die Besitzrechte der einzelnen Profilverzechnisse. Es reicht doch, wenn du Vollzugriff hast oder?
Es gibt eine Gruppenrichtlinie ala "Sicherheitsgruppe "Administratoren" zu servergespeicherten Profilen hinzufügen". Damit ist die lokale Administratorgruppe gemeint. D.h. die Rechte sind nicht benutzerspezifisch sondern durch eine Gruppe steuerbar. Macht das Ganze flexibel.
Grüße,
Dani
warum brauchst du die Besitzrechte der einzelnen Profilverzechnisse. Es reicht doch, wenn du Vollzugriff hast oder?
Es gibt eine Gruppenrichtlinie ala "Sicherheitsgruppe "Administratoren" zu servergespeicherten Profilen hinzufügen". Damit ist die lokale Administratorgruppe gemeint. D.h. die Rechte sind nicht benutzerspezifisch sondern durch eine Gruppe steuerbar. Macht das Ganze flexibel.
Grüße,
Dani
Es handelt sich bei den Verzeichnissen um Profile von nicht mehr existenten Nutzern. Aufgrund von Datenschutz
haben Admins kein Zugriff auf die Profile. Die einzigen sind die Nutzer und das System. Da ich nicht durch jeden
Sicherheitsreiter der Eigenschaften jedes Profiles durchklicken will um den Besitz zu übernehmen, war der Plan ein Script.
Aber der Ansatz mit der Richtlinie ist auch nicht schlecht, vielleicht kann man da was mit spezifischen OU's was regeln...
haben Admins kein Zugriff auf die Profile. Die einzigen sind die Nutzer und das System. Da ich nicht durch jeden
Sicherheitsreiter der Eigenschaften jedes Profiles durchklicken will um den Besitz zu übernehmen, war der Plan ein Script.
Aber der Ansatz mit der Richtlinie ist auch nicht schlecht, vielleicht kann man da was mit spezifischen OU's was regeln...
Die Richtlinie ist statisch... du kannst keinen Wunschbenutzer bzw. -gruppe hinterlegen. Es gilt für die Administratorengruppe auf dem Server wo das Share liegt.
Grüße,
Dani
Es handelt sich bei den Verzeichnissen um Profile von nicht mehr existenten Nutzern. Aufgrund von Datenschutz haben Admins kein Zugriff auf die Profile.
Ich würde wetten, die könnten sich die Rechte geben und nehmen, ohne das du etwas merkst. Den Domänenadmin ist der "König" im Netzwerk. Abhilfe schafft eigentlich nur eine NTFS-Journaling mit extra zweistufiger Authentifizierung.Grüße,
Dani
Hallo,
ein Powershellskript hast du ja schon. Das im System-Kontext ausführen zu lassen (wenn du lokaler Admin bist) ist ganz leicht: mit "at" kannst du in der cmd.exe einen Task zum Ausführen unter System erstellen (und dann powershell.exe -command oder so ausführen).
Gruß
Filipp
ein Powershellskript hast du ja schon. Das im System-Kontext ausführen zu lassen (wenn du lokaler Admin bist) ist ganz leicht: mit "at" kannst du in der cmd.exe einen Task zum Ausführen unter System erstellen (und dann powershell.exe -command oder so ausführen).
Gruß
Filipp
Ich würde wetten, die könnten sich die Rechte geben und nehmen, ohne das du etwas merkst. Den Domänenadmin ist der
"König" im Netzwerk. Abhilfe schafft eigentlich nur eine NTFS-Journaling mit extra zweistufiger Authentifizierung.
"König" im Netzwerk. Abhilfe schafft eigentlich nur eine NTFS-Journaling mit extra zweistufiger Authentifizierung.
Ich bin ja einer der DOMAdmins und ja klar, wir können uns die Rechte mit 2-3- Klicks geben. Der Plan ist aber das alles per Script zu machen - bzw automatisiert nenne ich es mal. Denn wenn man mal eben den Besitz von ~25 Ordnern übernehmen muss (die man unter 100ten ersteinmal finden muss) dann ist das eher lästig und zeitintensiv.
..(wenn du lokaler Admin bist) ist ganz leicht: mit "at" kannst du in der cmd.exe einen Task zum Ausführen unter System erstellen..
Wenn "at" die Powershell als System ausführt, habe ich das Problem mit dem Besitz übernehmen garnicht mehr. Dann kann ich die Profilordner (und alle anderen die einen Nutzer betreffen) ganz einfach vom System löschen lassen. Was aber auch ein Nachteil sein kann, wenn man mal nachvollziehen muss wer was gelöscht hat (aber das ist ein anderes Problem). Ich denke ich werde parallel mal mit "at" arbeiten..
Die "at" Methode mit Systemaccount funktioniert nur, wenn die Dinge (in dem Fa [ll Verzeichnisse= lokal auf der Festplatte liegen. Wenn du einen UNC-Pfad o.ä. nutzen möchtest, geht es schief. Das Problem ist gerade bei SQL-Servern die auf Netzwerk sichern sollen bekannt.
Mit Powershell funktioniert das eigentlich ganz gut - Beispiel.
Grüße,
Dani
Mit Powershell funktioniert das eigentlich ganz gut - Beispiel.
Grüße,
Dani
Hallo,
SQL läuft afaik unter "Network Service", nicht unter "System".
Außerdem habe ich den TO so verstanden, dass er das lokal auf dem Fileserver ausführen will - sonst würden System ja tatäschlich keinen Sinn machen.
Btw: In Powershell cmdlets im Kontext eines anderen Nutzers (oder auch auf einem anderen Server) ausführen zu lassen ist tatsächlich total einfach, mittels New-PSSession. Aber man benötigt dazu die Credentials des gewünschten Accounts - und das Kennwort vom "System"-Account stellt einen vor erhebliche Herausforderungen.
Grüße
Filipp
Die "at" Methode mit Systemaccount funktioniert nur, wenn die Dinge (in dem Fa [ll Verzeichnisse= lokal auf der
Festplatte liegen.
Sicher? Kann das gerade nicht testen, würde mich aber sehr wundern. Natürlich muss man das Computerkonto auf dem Ziel entsprechend berechtigen.Festplatte liegen.
SQL läuft afaik unter "Network Service", nicht unter "System".
Außerdem habe ich den TO so verstanden, dass er das lokal auf dem Fileserver ausführen will - sonst würden System ja tatäschlich keinen Sinn machen.
Mit Powershell funktioniert das eigentlich ganz gut -
[http://social.technet.microsoft.com/Forums/windowsserver/de-DE/b9b8331b-a206-4511-b0da-d36209d0e318/powershell-wie-besitzer-von-verzeichnissen-ndern
Beispiel].
Hm.. in dem Beispiel werden, wenn ich das jetzt nicht ganz falsch sehe, alle Aktionen im Kontext dessen, der das Skript startet, ausgeführt - und genau das war doch in diesem Thread das Problem.[http://social.technet.microsoft.com/Forums/windowsserver/de-DE/b9b8331b-a206-4511-b0da-d36209d0e318/powershell-wie-besitzer-von-verzeichnissen-ndern
Beispiel].
Btw: In Powershell cmdlets im Kontext eines anderen Nutzers (oder auch auf einem anderen Server) ausführen zu lassen ist tatsächlich total einfach, mittels New-PSSession. Aber man benötigt dazu die Credentials des gewünschten Accounts - und das Kennwort vom "System"-Account stellt einen vor erhebliche Herausforderungen.
Grüße
Filipp
Stimmt, die Credentials der anderen User zu benutzen ist auch eine Möglichkeit. Dabei muss ich mich wie gesagt aber immer mit dem jeweiligen User anmelden. Dies kann bei 50 Usern ganz schön - ich nenne es mal aufwendig und lästig werden.
Normalerweise müssten meine Adminrechte ja ausreichen um den Besitz zu übernehmen. Bzw reichen sie ja unter Windows. Diesen ganzen Prozess muss man doch auch als Script ausführen können..
Ich habe auch versucht ein Script unter einem anderen Benutzer auszuführen und das Verzeichnis selbst löschen zu lassen. Da bekommt der User immer "Zugriff verweigert" obwohl er der Besitzer ist und Zugriff hat.
Normalerweise müssten meine Adminrechte ja ausreichen um den Besitz zu übernehmen. Bzw reichen sie ja unter Windows. Diesen ganzen Prozess muss man doch auch als Script ausführen können..
Ich habe auch versucht ein Script unter einem anderen Benutzer auszuführen und das Verzeichnis selbst löschen zu lassen. Da bekommt der User immer "Zugriff verweigert" obwohl er der Besitzer ist und Zugriff hat.
Moin,
poste doch bitte das Script...
Grüße,
Dani
poste doch bitte das Script...
Die "at" Methode mit Systemaccount funktioniert nur, wenn die Dinge (in dem Fa [ll Verzeichnisse= lokal auf der Festplatte liegen.
Ist dies gegeben?Grüße,
Dani
Soo, war einige Zeit beschäftigt hatte noch ein paar andere Baustellen..
Mein Script ist mittlerweile zu einer - ich nenne es mal "Powershellanwendung" mutiert. Es hat nun ein Menü und sowas. Das Problem mit den
Profilpfaden und dem zu übernehmenden Besitz besteht immernoch. Hier mal eine Funktion mit der es auch nicht funktioniert
Mein Script ist mittlerweile zu einer - ich nenne es mal "Powershellanwendung" mutiert. Es hat nun ein Menü und sowas. Das Problem mit den
Profilpfaden und dem zu übernehmenden Besitz besteht immernoch. Hier mal eine Funktion mit der es auch nicht funktioniert
Function Set-Ownership($pfad) {
If ( (Test-Path $pfad) -eq $false)
{ Throw "Ordner $pfad nicht gefunden." }
$pfad = $pfad.Replace('\', '\\')
$wql = "Select * from Win32_Directory Where Name = '$pfad'"
Get-WmiObject -query $wql | ForEach-Object {
($_.TakeOwnership()).ReturnValue }
}
If ( (Test-Path $pfad) -eq $false)
{ Throw "Ordner $pfad nicht gefunden." }
$pfad = $pfad.Replace('\', '\\')
$wql = "Select * from Win32_Directory Where Name = '$pfad'"
Get-WmiObject -query $wql | ForEach-Object {
($_.TakeOwnership()).ReturnValue }
}
...wenn die Dinge (in dem Fa [ll Verzeichnisse= lokal auf der Festplatte liegen..
Ist dies gegeben?
--> Jein, das Script führe ich auf meinem Rechner aus, ABER ich kann "at" ja auch auf dem Server laufen lassen, durch remote-Powershell. Davon mal abgesehen braucht man für "at" den Zeitplanerdienst, welcher auf unseren Servern nicht aktiv ist.Ist dies gegeben?
