Benutzer mit den meisten Antworten
Zugriff auf Skripte in unscoped Exchange Management Roles aus zu .exe kompilierten .ps1 Dateien.

Frage
-
Hallo zusammen,
Dieses Problem ist etwas komplexer, weshalb ich schon so einige Foren abgegrast habe und mir leider nirgendwo geholfen werden konnte.
Mein Problem:
Ich möchte es Usern mit Outlook ermöglichen ihre Outlook Ordner und Unterordner komfortabel in einem Menü freizugeben, quasi als SelfService Tool. Das Tool was ich gebastelt habe sieht gut aus, funktioniert wie es soll und alles ist bestens, wenn nicht das Problem mit den Rechten wäre. Alle User sollten es ausführen können, es wird allerdings ein Zugriff auf sehr mächtige Commandlets (set-mailboxfolderpermission usw) und das default scope benötigt, weshalb jeder User auf sämtliche Postfächer zugreifen könnte. Um dies zu verhindern habe ich nun eine unscoped managementrole erstellt und mehrere eigen erstellte Scripte hinzugefügt, die zwar diese mächtigen Commandlets set-mailboxfolderpermission usw ausführen, allerdings eine Validierung die für den User uneinsichtig ist ausführen, weshalb der User nicht in der Lage ist diese Funktionen außerhalb des Tools zu nutzen. Um den gesamten Prozess für den User uneinsichtig zu machen darf das Powershellscript allerdings auch nicht mehr durchsuchbar sein, weshalb ich mich entschlossen habe die .ps1 Datei in eine .exe Datei umzuwandeln(habe das mit Sapiens PowershellStudio2012 und PS2EXE 0.4.0.0 versucht). Dort ist nun das Problem, dass normale Commandlets und die Snapins verfügbar sind, allerdings nicht meine Skripte, die ich in der Unscoped Role definiert habe. In der normalen Shell lassen sie sich super aufrufen, liegt also nicht an den Skripten selber. Es wird nur angezeigt "Die Benennung "Mein-Skript.ps1" wurde nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist und wiederholen Sie den Vorgang".
Die Frage:
Wie könnte man dieses Problem beheben? Hat jemand schon mit einer ähnlichen Situation zu kämpfen gehabt? Wo werden die eigen erstellten Skripte gespeichert? Gibt es da ein PSSnapin, was man einbinden kann? Kann man ein separates PSSnapin erstellen, was dann den Aufruf und die Rückgabewerte an die selbst erstellten Skripte durchpiped? Bin für sämtliche Lösungsansätze offen, Hauptsache die User können nur für ihr eigenes Postfach Berechtigungen auslesen und setzen und haben keinen generellen Zugriff auf diese mächtigen Cmdlets. Es handelt sich außerdem um nicht wenige User(über 17k), weshalb es auch auszuschließen ist für jeden einen eigenen Scope und eine eigene RBAC Rolle zu erstellen.
Mit freundlichen Grüßen Christian
Antworten
-
Ich glaube ich habe nun eine Lösung gefunden :)
Mir ist aufgefallen, dass die ganzen Cmdlets, die für meine GUI benötigt werden alle in der RBAC Rolle MyBaseOptions drin sind, die jeder User standardmäßig zugewiesen bekommt. Somit ist es gar nicht nötig meine eigenen Skripte zu nutzen und jeder hat nur Schreibzugriff auf seine eigenen Daten :)
Vielen Dank für die Hilfe :)
- Als Antwort markiert Christian Buchwald Montag, 10. Juni 2013 11:54
Alle Antworten
-
Zuerst einmal bin ich der Meinung dass, das ganze nicht durchgeführt werden sollte, da du hier versuchst mehrere, berechtigte Sicherheitsbarrieren zu unterwandern.
Sicherheit ist unbequem und man sollt da einen besseren Weg finden!
PS1 Dateien als .exe sind kein Hindernis diese auch wieder zu lesen, man braucht nur einen Disassembler!PowerShell bietet die Möglichkeit an Usern einen eingeschränkten PowerShell zugriff zu geben (Constrained EndPoint).
Ab der PowerShell 3.0 kann diesem sogar mit einem andren User Account arbeiten lassen.
Ein normaler User kann dann also EINE Aufgabe als Administrator ausführen (RunAs).http://powershell-enthusiast.blogspot.de/2012/11/delegated-administration-in-windows.html
Please click “Mark as Answer” if my post answers your question and click “Vote As Helpful” if my Post helps you.
Bitte markiere hilfreiche Beiträge von mir als “Als Hilfreich bewerten” und Beiträge die deine Frage ganz oder teilweise beantwortet haben als “Als Antwort markieren”.
My PowerShell Blog http://www.admin-source.info
[string](0..21|%{[char][int]([int]("{0:d}" -f 0x28)+('755964655967-86965747271757624-8796158066061').substring(($_*2),2))})-replace' '
German ? Come to German PowerShell Forum! -
Hallo Peter,
vielen Dank für deine schnelle Antwort. Beim Constrained Endpoint steht, dass die User nur Befehle ausführen können, die sie bereits vorher ausführen konnten, also müsste man ihnen die Rechte für mächtige Cmdlets geben, was ich zu vermeiden versuche. Powershell 3.0 kommt für mich leider nicht in Frage, da nicht alle Rechner Windows 7 oder 8 haben, sondern noch viele auf unbestimmte Zeit mit XP laufen müssen.
Kennst du eine alternative Möglichkeit wie man den Usern Zugriff auf Cmdlets geben kann, die sie aber nur für sich selbst anwenden können? Am besten wäre ein Scope, welches nur für den angemeldeten User gilt, aber leider scheint es so etwas nicht zu geben. Dynamisches Erstellen der RBAC Rollen kann ich auch knicken, da die User sonst auch Zugriff auf die Commandlets zum Erstellen des Scopes und der Rollen hätten, womit sie sich jedes Recht selber geben könnten. Das schreiben der Änderungen in eine Datei, die dann von einem anderen Script als Task alle paar Minuten ausgeführt wird kann man auch vergessen, da die User diese Datei sonst bearbeiten könnten um sich Zugriff auf andere Postfächer zu geben.
In Unscoped Roles Skripten, die nur Zugriff auf das eigene Postfach erlauben sehe ich da die beste Lösung. Leider bin ich mir nicht sicher wie ich die Verifizierung dort umsetzen soll. Ich hatte es anfangs so versucht, dass die Skripte eine Whoami Abfrage stellen und diese dann mit den anderen Werten an die andern Commandlets weiterleitet, aber leider werden die Skripte in unscoped roles immer von einem Systemaccount ausgeführt, weshalb der Whoami nur den Systemaccount zurückliefert. Gibt es eine andere Möglichkeit innerhalb eines Skripts abzufragen, wer das Skript aufgerufen hat?
Gruß Christian
-
Ich befürchte so wie du das geplant hast, wirst du keine hinreichend sichere Lösung finden.
Wie wärs mit einem anderem Ansatz? Ich hätte das ganze als Client/Server-Lösung konzipiert. Mit den entsprechend weitreichend gefassten Rechten ausgestattet ist nur das Serverscript. Die Clientscripts geben -nach Authentifizierung des Users- hingegen nur die Anforderung der Änderung an den Server weiter und dieser führt diese dann -nur für den authentifizierten User- durch.
Die größte Herausforderung hierbei wäre natürlich die Client/Server Kommunikation. Diese könnte z.b. per TCP/IP stattfinden, der Aufwand hierfür sollte überschaubar sein.
Deine Probleme was die Exe betrifft, kommen übrigens höchstwahrscheinlich daher, das der Entwickler von PS2EXE die Ausführung des Scriptes in der Exe über einen selbst geschriebenen Powershell-Host realisiert hat.Und das scheint -wenn man die Kommentare zu seinen Blogposts so liest- zur Zeit noch zu allerlei ungelöstem Problemen zu führen, unter anderem eben auch den von dir beschriebenen.
Grüße, Denniver
Blog: http://bytecookie.wordpress.com
Hilf mit und markiere hilfreiche Beiträge als "Hilfreich" und Beiträge die deine Frage ganz oder teilweise beantwortet haben als "Antwort".- Bearbeitet Denniver ReiningMVP, Moderator Montag, 10. Juni 2013 00:31
-
Da hast du den Sinn von constrained endpoints noch nicht ganz begriffen!
Wenn man ein eigenes Modul schreibt mit eigenen Funktionen ohne gefährliche Parameter, dann hat der User mit constrained endpoints nur die Möglichkeit die Funktion auszuführen. Nicht die Cmdlets, die die Funktion intern benutzt! Man muss die Funktion halt so schreiben, dass Sie nur diese eine Aufgabe für diesen einen User ausführt! constrained (eingeschränkt) eben! ;-)
Da der User die Funktion ausführt, läuft Sie ja in seinem Kontext (Scope)! %Username% oder $env:Username kann die Funktion auch auslesen!Client/Server Arbeiten mit Nachrichten: Anforderung/Aktion/Antwort.
Ähnliches kannst du auch über das Filesystem realisieren.
1. Starte auf einem Server (Rechner) ein Script das ein Verzeichis (Share) überwacht (FilesytemWatcher),
mit dem Windows Task Scheduler oder als Privilegierter Dienst
2. User (Script) legt auf in dieses Verzeichnis (Share) eine TXT/XML Datei mit Daten (oder Leer) (kann auch eine Signatur enthalten!)
3. Dein FileSystemwatcher reagiert dann auf das anlegen der Datei (auslesen der Daten, prüfen der Signatur) und führt die Aktion aus.Die Authentifizierung geschieht über die NTFS Berechtigung man kann pro User ein Verzeichnis anlegen (\\Share\Username) auf das nur er und dein Dienst zugriff hat! Wenn du jetzt noch jede Aktion Loggst, dann sollte auch die Revision zufrieden sein!
Etwa so:
http://powertoe.wordpress.com/2012/06/27/how-to-execute-powershell-scripts-without-the-cpu-hit-to-start-powershell/Filemonitoring
http://www.powershellpraxis.de/index.php/ntfs-filesystem/filemonitoringAber Dennivers Client/Server Ansatz ist noch besser und Skalierbar! Mein Ansatz ist nur für eine geringe Anzahl von Usern!
Please click “Mark as Answer” if my post answers your question and click “Vote As Helpful” if my Post helps you.
Bitte markiere hilfreiche Beiträge von mir als “Als Hilfreich bewerten” und Beiträge die deine Frage ganz oder teilweise beantwortet haben als “Als Antwort markieren”.
My PowerShell Blog http://www.admin-source.info
[string](0..21|%{[char][int]([int]("{0:d}" -f 0x28)+('755964655967-86965747271757624-8796158066061').substring(($_*2),2))})-replace' '
German ? Come to German PowerShell Forum!
- Bearbeitet Peter Kriegel Montag, 10. Juni 2013 08:18
-
Hallo zusammen,
vielen Dank für diese Lösungsvorschläge :)
@Peter: leider wird der Userkontext nur bei normalen Cmdlets genutzt und nicht bei Skripten die unscoped sind. Dort liefert whoami nt authority\system, %Username% verursacht eine Fehlermeldung, dass das Cmdlet nicht gefunden werden kann und $env:Username liefert den Servernamen zurück :(
Das Problem mit der TCP Lösung und der Ordnerüberwachung ist, dass wie bereits gesagt wurde ein Disassembler genutzt werden kann um den Powershellcode zu sehen. Somit wäre es möglich sowohl den TCP Request anzupassen, als auch die Datei die in dem Share ausgelesen wird. Eine Signierung der Daten bringt aus meiner Sicht auch wenig, da jeder User Zugriffsrechte auf das Zertifikat haben müsste um den Code im eigenen Context zu signieren, somit wäre es auch möglich, dass andere Mitarbeiter dieses Zertifikat für ihren eigenen Code nutzen könnten um diese Sicherheit auszuhebeln.
-
Ich glaube ich habe nun eine Lösung gefunden :)
Mir ist aufgefallen, dass die ganzen Cmdlets, die für meine GUI benötigt werden alle in der RBAC Rolle MyBaseOptions drin sind, die jeder User standardmäßig zugewiesen bekommt. Somit ist es gar nicht nötig meine eigenen Skripte zu nutzen und jeder hat nur Schreibzugriff auf seine eigenen Daten :)
Vielen Dank für die Hilfe :)
- Als Antwort markiert Christian Buchwald Montag, 10. Juni 2013 11:54
-
Ich wusste nicht das es "unscoped Scripts" gibt!
Wie erzeugt man die denn?
Gibt es darüber eine Erklärung irgendwo ?Please click “Mark as Answer” if my post answers your question and click “Vote As Helpful” if my Post helps you.
Bitte markiere hilfreiche Beiträge von mir als “Als Hilfreich bewerten” und Beiträge die deine Frage ganz oder teilweise beantwortet haben als “Als Antwort markieren”.
My PowerShell Blog http://www.admin-source.info
[string](0..21|%{[char][int]([int]("{0:d}" -f 0x28)+('755964655967-86965747271757624-8796158066061').substring(($_*2),2))})-replace' '
German ? Come to German PowerShell Forum! -
Hallo Peter,
in Exchange muss man sich erst die RBAC Rolle "Unscoped Role Management" zuweisen, da ansonsten nicht einmal Organization Management über den unscoped Parameter verfügt. Anschließend kann man in der Shell mit new-managementrole -unscopedTopLevel eine Rolle erstellen und über add-managementroleentry Befehle hinzufügen. Vorher müssen die eigenen Skripte allerdings noch in den RemoteScripts Ordner im Exchange Installationsordner auf sämtlichen CAS Servern kopiert werden. Die erstellte Rolle kann man nun den Usern in RBAC zuweisen und die Skripte können über mächtige Cmdlets verfügen, die der User sonst gar nicht ausführen können soll(wie in meinem Fall). Ist auf jeden Fall ein klasse Feature, Details gibt es hier:
http://serverfault.com/questions/359365/how-can-i-add-a-custom-powershell-cmdlet-to-exchange-2010
Gruß Christian
-
Hallo Christian !
Danke für die sehr gute Erklärung! Man lernt nie aus!
Ich dachte Unscoped wäre einfach nur ungeschickt ausgedrückt, deshalb habe ich nicht nachgefragt.
Ich bin kein Exchange Experte, da ich weder auf der Arbeit noch zu hause in meinem 180 Tage LAB einen Exchange Server zum 'spielen' habe!So, habe mich mal da durch gelesen.
Sehr Interessantes Konzept und sehr ähnlich zu den constrained endpoints.
Mir ist bei beiden Techniken noch nicht ganz klar wie man das Revisions-Sicher hin bekommt da die User wie du schon sagtest mit dem Server Maschinen Account arbeiten.
Schade ist auch das dort .ps1 Scripte verwendet werden und keine Module. Das weicht von dem normalen PowerShell vorgehen etwas ab.
Hier noch die deutschen Links zu dem Thema:
Hinzufügen eines Rolleneintrags zu einer Rolle auf oberster Ebene ohne Bereichseinschränkung
http://technet.microsoft.com/de-de/library/dd979789%28v=exchg.150%29.aspx
Sieh abschnitt: Verwaltungsrollen auf oberster Ebene ohne Bereichseinschränkung
http://technet.microsoft.com/de-de/library/dd298116%28v=exchg.150%29.aspx
Please click “Mark as Answer” if my post answers your question and click “Vote As Helpful” if my Post helps you.
Bitte markiere hilfreiche Beiträge von mir als “Als Hilfreich bewerten” und Beiträge die deine Frage ganz oder teilweise beantwortet haben als “Als Antwort markieren”.
My PowerShell Blog http://www.admin-source.info
[string](0..21|%{[char][int]([int]("{0:d}" -f 0x28)+('755964655967-86965747271757624-8796158066061').substring(($_*2),2))})-replace' '
German ? Come to German PowerShell Forum!
- Bearbeitet Peter Kriegel Dienstag, 11. Juni 2013 06:17