9
Symlink via powershell ohne adminrechte möglich?
Hi,
ich wollte via Powershell einen Symlink erstellen aber das scheint ohne Adminrechte nicht möglich zu sein, was mich sehr wundert.
New-Item : Für diesen Vorgang sind Administratorrechte erforderlich.
In Zeile:1 Zeichen:1
+ CategoryInfo : PermissionDenied: (Z:\filelist.txt:String) [New-Item], UnauthorizedAccessException
+ FullyQualifiedErrorId : NewItemSymbolicLinkElevationRequired,Microsoft.PowerShell.Commands.NewItemCommand
Hat jemand eine Idee warum das nicht geht?
der Link soll ja im selben Ordner angelegt werden. Ich kann ansonsten rw auf den Ordner via PS zugreifen
ich wollte via Powershell einen Symlink erstellen aber das scheint ohne Adminrechte nicht möglich zu sein, was mich sehr wundert.
New-Item -ItemType SymbolicLink -Path .\link -Target .\filelist.txtNew-Item : Für diesen Vorgang sind Administratorrechte erforderlich.
In Zeile:1 Zeichen:1
New-Item -ItemType SymbolicLink -Path .\link -Target .\filelist.txt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (Z:\filelist.txt:String) [New-Item], UnauthorizedAccessException+ FullyQualifiedErrorId : NewItemSymbolicLinkElevationRequired,Microsoft.PowerShell.Commands.NewItemCommand
Hat jemand eine Idee warum das nicht geht?
der Link soll ja im selben Ordner angelegt werden. Ich kann ansonsten rw auf den Ordner via PS zugreifen
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6174708637
Url: https://administrator.de/contentid/6174708637
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
9 Kommentare
Neuester Kommentar
That's by design, weil per Default nur Administratoren Symlinks anlegen können welche das SeCreateSymbolicLinkPrivilege Token-Privileg haben
https://security.stackexchange.com/questions/10194/why-do-you-have-to-be ...
Oder legt die User fest die es dürfen:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\
Oder man aktiviert den Developer Mode
https://learn.microsoft.com/en-us/windows/apps/get-started/enable-your-d ...
und verwendet dann die CreateSymbolicLink Methode mit dem dritten Parameter auf 0x2 festgelegt.
Ist eben Sicherheitsrelevant, mit Symlinks kann man sonst einiges anstellen.
https://security.stackexchange.com/questions/10194/why-do-you-have-to-be ...
Oder legt die User fest die es dürfen:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\
Oder man aktiviert den Developer Mode
https://learn.microsoft.com/en-us/windows/apps/get-started/enable-your-d ...
und verwendet dann die CreateSymbolicLink Methode mit dem dritten Parameter auf 0x2 festgelegt.
Ist eben Sicherheitsrelevant, mit Symlinks kann man sonst einiges anstellen.
Dies hat historische Gründe (erst mit Vista eingeführt) und auch wegen der Sicherheit, da man Symlinks missbrauchen könnte, um z.B. explorer.exe umzuleiten.
Darum ist dies auf die Admins beschränkt. Alternativ dazu kann man aber den Entwicklermodus aktivieren. Dies ist aber nicht zu empfehlen in einer produktiven Umgebung.
Darum ist dies auf die Admins beschränkt. Alternativ dazu kann man aber den Entwicklermodus aktivieren. Dies ist aber nicht zu empfehlen in einer produktiven Umgebung.
Könnte man in Startscripten verteilen, die unter Admin laufen. Dann wäre es nach den nächsten Reboot drin. Wir haben das für POS unterteilt. Startup für Systemstart unter Admin. Logon Script unter dem Prinzipal Benutzer. Dann hat man damit die volle Kontrolle. Wir haben eh alles auf PS laufen und nutzen entsprechend weniger GPOs in einigen Bereichen.
Danke für die vielen Hinweise.
Interessant finde ich hierbei folgendes:
Der Symlink soll auf einem per CIFS angebundenen Share geschrieben werden. Dort liegt auch die Quelldatei.
Also z.B.
Datei --> Z:\foo\Archive\file.txt
Link --> Z:\link
Wie wir wissen geht das mit PS nur mit Adminrechten oder wie oben beschrieben.
Wenn ich mich nun auf eine Linux Maschine anmelde und dort einen Symlink anlegen will mit identischer Quelle und identischem Ziel, funktioniert das ganz ohne Probleme. Der User den ich zum Schreiben benutze, ist der identische AD User.
Interessant finde ich hierbei folgendes:
Der Symlink soll auf einem per CIFS angebundenen Share geschrieben werden. Dort liegt auch die Quelldatei.
Also z.B.
Datei --> Z:\foo\Archive\file.txt
Link --> Z:\link
Wie wir wissen geht das mit PS nur mit Adminrechten oder wie oben beschrieben.
Wenn ich mich nun auf eine Linux Maschine anmelde und dort einen Symlink anlegen will mit identischer Quelle und identischem Ziel, funktioniert das ganz ohne Probleme. Der User den ich zum Schreiben benutze, ist der identische AD User.
Linux ≠ Windows.
Pinguin ≠ Stinktier
Pinguin ≠ Stinktier
Also, nachdem ich nun die Richtlinie angepasst habe, kann mein User Symlinks erstellen.
Allerdings funktioniert dies nur auf lokalen Laufwerken. Ich muss dies aber auf einem CIFS Share tun.
Dies funktioniert dann leider auch wieder nicht, egal ob mit drive letter oder unc pfad
Hat dazu evtl noch jemand einen Lösungsvorschlag?
Allerdings funktioniert dies nur auf lokalen Laufwerken. Ich muss dies aber auf einem CIFS Share tun.
Dies funktioniert dann leider auch wieder nicht, egal ob mit drive letter oder unc pfad
New-Item : Für den angegebenen Pfad werden keine symbolischen Links unterstützt.Hat dazu evtl noch jemand einen Lösungsvorschlag?
Zitat von @instinctless:
Dies funktioniert dann leider auch wieder nicht, egal ob mit drive letter oder unc pfad
Hat dazu evtl noch jemand einen Lösungsvorschlag?
Steht doch da, geht nicht mit Netzlaufwerken.Dies funktioniert dann leider auch wieder nicht, egal ob mit drive letter oder unc pfad
New-Item : Für den angegebenen Pfad werden keine symbolischen Links unterstützt.Hat dazu evtl noch jemand einen Lösungsvorschlag?
Zitat von @6017814589:
Zitat von @instinctless:
Dies funktioniert dann leider auch wieder nicht, egal ob mit drive letter oder unc pfad
Hat dazu evtl noch jemand einen Lösungsvorschlag?
Steht doch da, geht nicht mit Netzlaufwerken.Dies funktioniert dann leider auch wieder nicht, egal ob mit drive letter oder unc pfad
New-Item : Für den angegebenen Pfad werden keine symbolischen Links unterstützt.Hat dazu evtl noch jemand einen Lösungsvorschlag?
komm, lass dich aus. du hast doch bestimmt noch ein paar mehr sinnlos kommentare in deinem troll repertoir.
oder anders: wenn du nichts hilfreiches beizutragen hast, lass es doch einfach
Servus @instinctless,
damit das funktioniert sind einige Vorbereitungen nötig:
Zum Abfragen des Status:
Sind diese Bedingungen erfüllt klappt das Anlegen über New-Item in der Powershell wie gehabt.
oder mit mklink in einer CMD
Wurde hier einwandfrei getestet.
Grüße Uwe
damit das funktioniert sind einige Vorbereitungen nötig:
- Bedingung 1: Berechtigung zum Erstellen von Symlinks muss wenn der Link selbst auf einem Netzlaufwerk liegt auf dem Fileserver des Shares gesetzte werden nicht auf der Maschine von wo aus du es versuchst! Die Berechtigung muss also immer dort gesetzt sein wo der Link angelegt wird.
- Bedingung 2: Du musst je nachdem wo die Links und Zieldateien liegen die Auflösung der Links aktivieren damit diese überhaupt erst genutzt werden können, und zwar wie folgt (je nachdem welche Variante du brauchst die jeweilige aktivieren):
# Remote-zu-Remote Link Evaluation
fsutil behavior set SymLinkEvaluation R2R:1
# Local-zu-Remote Link Evaluation
fsutil behavior set SymLinkEvaluation L2R:1
fsutil behavior query SymlinkEvaluation
- Bedingung 3: Schreibberechtigungen auf dem Laufwerk für den Link müssen vorhanden sein.
Sind diese Bedingungen erfüllt klappt das Anlegen über New-Item in der Powershell wie gehabt.
New-Item -ItemType SymbolicLink -Path "\\server\testshare\meinlink.txt" -Target "\\server\testshare\ziel.txt" -Force
mklink "\\server\testshare\meinlink.txt" "\\server\testshare\ziel.txt"
Grüße Uwe
1
