Fragensteller
Netzlaufwerk Zugriff von IIS 8.0

Frage
-
Hallo,
ich habe auf einem Server2012r2 den IIS laufen. Auf diesem ist ein WebService gehostet, welcher läuft. Der Server2012 hat ein Netzlaufwerk y: durch den cmd net use Befehl verbunden (Andere Anmeldeinformationen). Auf dieses kann ich über cmd und den Explorer wunderbar zu greifen. Aber nicht vom WebService "Fehler Ein Teil des Pfades "y:\Test\Test1" konnte nicht gefunden werden". Der Anwendungspool des IIS ist auf ein Domänenkonto gesetzt. Die Authentifierung beim WebService ist auf "Anonym" gesetzt aber "Identiät des Anonymen Benutzer" = "identität des Anwendungspools". Dennoch ist es mir nicht möglich auf die Netzwerkfreigabe zuzugreifen. Hat jemand vllt einen Tipp?
mfg
Gerald
- Bearbeitet GeraldvonRiva Donnerstag, 25. August 2016 10:07
Alle Antworten
-
Moin,
ist denn das Konto, mit dem der AppPool läuft, auch das, in dessen Ausführungskontext das NET USE-Mapping durchgeführt wird? Und ich meine damit NICHT die alternativen Credentials, die da verwendet werden, sondern den Benutzer, der den CMD-Befehl ausführt.
Und da es ein elendes Gefummel ist - kannst Du die Website nicht einfach über UNC auf die Inhalte zugreifen lassen? Viel zuverlässiger und einfacher IMO.
Evgenij Smirnov
msg services ag, Berlin -> http://www.msg-services.de
my personal blog (mostly German) -> http://it-pro-berlin.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.comIn theory, there is no difference between theory and practice. In practice, there is.
-
Mal als Beispiel wir haben die Domäne test mit dem User tester. Ich rufe die CMD über "shift+rechtsklick" andere Benutzer auf und melde mich als "test/tester" an, dort führe ich dann den net use befehl aus und das Netzlaufwerk steht zur Verfügung. Der IIS AppPool ist auch auf den Nutzer "test/tester" gesetzt, sowie auch die Identität des Anonymen Benutzers im IIS. Jedoch ist das Netzlaufwerk dennoch nicht vom IIS erreichbar, nur noch von der CMD für den Nutzer "test/tester".
Auf dem Laufwerk liegt keine Webseite, der Webservice soll dort nur Dateien bearbeiten. Der User "test/tester" soll selbst auf diesem Netzlaufwerk keine Rechte haben und ein Zugriff halt nur durch das Mapping des Laufwerkes ermöglicht werden. Ist leider ne Anforderung die ich nicht so einfach umgehen kann.
- Bearbeitet GeraldvonRiva Donnerstag, 25. August 2016 11:06
-
Der User "test/tester" soll selbst auf diesem Netzlaufwerk keine Rechte haben und ein Zugriff halt nur durch das Mapping des Laufwerkes ermöglicht werden. Ist leider ne Anforderung die ich nicht so einfach umgehen kann.
Evgenij Smirnov
msg services ag, Berlin -> http://www.msg-services.de
my personal blog (mostly German) -> http://it-pro-berlin.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.comIn theory, there is no difference between theory and practice. In practice, there is.
-
Über die Einbindung wird der andere Nutzer authentifiziert und der "test/tester" kann mit dem Laufwerk arbeiten.
Also \\Server\Share freigegeben für nutzer prod/producer
einbinden mit NET USE Y: \\Server\Share producerPWD /USER:prod/producer /Persistent:No
Durch das net use erfolgt eine Authentifizierung als Nutzer "prod/producer" danach kann mit dem Netzlaufwerk normal unter dem Nutzer "test/tester" gearbeitet werden. -
Hmmm.
mit dem App-Pool wird es so nicht gehen, indem man die Benutzer-Umgebung interaktiv initialisiert. Du müßtest diesen Befehl mit den anderen Credentials beim Starten des Pools ausführen, und auch da bin ich mir nicht 100% sicher, ob die Verknüpfung inkl. Authentifizierung nicht irgendwann weggeschmissen wird.
Aber.
Wenn es ein ASP-Code ist, der auf die Share zugreift, dann kannst Du den NET USE-Befehl doch direkt im Code ausführen, bevor Zugriff genommen wird, oder? Dann ist sichergestellt, dass NET USE und der Zugriff in der gleichen Sitzung ablaufen...
Ist aber trotzdem doof, und sicherheitstechnisch ist es doch totaler Quatsch:
- Pool Identity darf auf Share zugreifen --> Credentials des Kontos mit Share-Zugriff sind im Secure Store des Computers gespeichert
- Das, was Du vorhast --> Credentials eines völlig unbedeutenden Kontos sind sicher gespeichert, Credentials eines höher berechtigten Kontos liegen hingegen im Klartext vor!
Evgenij Smirnov
msg services ag, Berlin -> http://www.msg-services.de
my personal blog (mostly German) -> http://it-pro-berlin.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.comIn theory, there is no difference between theory and practice. In practice, there is.