Problem beim Zugriff des IIS(ASPNET) auf Serverfreigaben

[Andreas Gräfe]

Ich habe einen WebServer mit IIS 5 und Framework 1.1. Die Daten liegen auf einem Backendserver und sind mit allen Rechten für jeden freigegeben. Der Webserver soll nun vom IIS auf die Daten des Backend zugreifen. Lokal ist das kein Problem, nur wenn er über das Internet aufgerufen wird, kommt ein Fehler, dass er die datei nicht erreichen kann.

An was kann das liegen? Ich habe schon mal die Sicherheitseinstellungen im Intranet geändert. Das hat aber auch nichts gebracht. Auch die Änderung in der machine.config - ProcessModel/User=SYSTEM - war nur negativ; er hatte dann gar keinen Zugriff mehr. Bei der Angabe eines Users der Domäne und dem zugehörigen Passwort ging es besser, aber das Probelm besteht immer noch.

Wenn jemand einen Rat hat, bin ich sehr dankbar.
_________________
Andreas

[Jörg Wegener]

Hallo,

wenn ich das richtig verstanden haben, dann liegen die ASP.NET Dateien nicht lokal auf der Festplatte, sondern sind zentral auf einen anderen Server ("Backend-Server") gespeichert?

Wenn das so ist, können die Sicherheitseinstellungen des .NET Framework dich behindern. Diese stufen Code, der nicht lokal auf der Maschine gespeichert ist, als "weniger" vertrauenswürdig ein.

Mit welche Stufe dieser Code vertraut wird, kann man in den Sicherheitseinstellungen bestimmen (Stichwort: Verwaltung).

Vielleicht hast du ja damit Glück.

Jör

[Andreas Gräfe]

Ich habe die einstellungen vom Intranet schon auf "voll vertrauenswürdig" gesetzt. Da hat sich aber nichts geändert.
Eigentlich ist es doch eine Konfigurationssache in der Web.config. Da muss es doch was geben, um den User die Rechte zu geben, auf die Freigaben zuzugreifen. Geht das mit IMPERSONATE oder so???

Andreas Gräf

[Andreas Kosch]

Hallo,

wenn der IIS eine Request-Aufruf auf eine Ressource erhält, die für ASP.NET registriert ist (wie zum Beispiel im Fall einer ASPX-Datei), so wird dieser Aufruf an die ISAPI-DLL <i>aspnet_isapi.dll</i> weitergeleitet. Diese DLL läuft im gleichen Prozess wie der IIS selbst (also in <i>inetinfo.exe</i>). Eine ASP.NET-Anwendung des IIS 5.x wird jedoch in einem separaten Prozess (<i>aspnet_wp.exe</I>) ausgeführt, daher muss die ISAPI-DLL den Aufruf über eine Namep Pipe an den ASP.NET-Prozess weiterleiten, wobei diese Instanz des Workerprozesses vorher über <b>LogonUser</b> und <b>CreateProcessAsUser</B> unter dem festgelegten Benutzerkonto ausgeführt wird, das In der Konfigurationsdatei <b>machine.config</B> (Framework-Unterverzeichnis von Windows) vom Eintrag <b>processModel</b> festgelegt wird.

Innerhalb des ASP.NET-Prozesses schotten verschiedene Application Domains (AppDomain) die ASP.NET-Anwendungen voneinerander ab. Mit dem IIS 6.0 (Windows Server 2003) ändert sich diese Architektur, da ASP.NET nicht mehr als separater Prozess läuft. Der Named Pipe-Zugriff wird dann durch Local Procedur Calls ersetzt.

Wenn <i>aspnet_isapi.dll</I> den Request-Aufruf an <i>aspnet_wp.exe</I> weiterleitet, überträgt es auch den vom IIS erhaltenen Access Token an ASP.NET. Dieser Access Token sieht je nach Konfiguration unterschiedlich aus:

a) Anonymer Zugriff: <b>ISUR_machinename</B>

b) Authentifizierter Zugriff (Intranet): Benutzername des Aufrufers

Bevor ASP.NET diesen Request-Aufruf weiterverarbeitet, wird zuerst geprüft, ob das erhaltene Access Token für die angeforderte Ressource die <b>ACL Authorization</b> (Zugriffsprüfung durch das NTFS-Dateisystem) besteht. ASP.NET arbeitet diese Prüfung in jedem Fall ab, auch wenn die ASP.NET-Anwendung die Impersonation aktiviert hat. War diese Prüfung erfolgreich, so wird das Access Token der ASP.NET-Anwendung zur Verfügung gestellt, so dass die Anwendung über die Impersonation eine benutzerabhängige Zugriffsberechtigung nutzen kann.

Da die ACL Authentication auf die aufgerufene ASPX-Datei in <b>jedem Fall zuerst</b> stattfindet, kann ein bestimmter Benutzer "ausgesperrt" werden, indem er keine Leserechte für diese ASPX-Datei erhält. Wenn er allerdings Leserechte für diese Datei hat, kann er die ASP.NET-Anwendung ausführen. Greift diese ASPX dann auf eine andere Datei zu und ist die Impersonation nicht aktiv, so erfolgt der Zugriff auf diese externe Datei unter dem <b>ASPNET-Benutzerkonto</b>. Der Zugriff ist also auch dann erfolgreich, wenn der Benutzer selbst für diese externe Datei keine ACL-Berechtigung (NTFS-Dateisystem) hat, aber das ASPNET-Benutzerkonto schon. Wenn die Zugriffsprüfung in jedem Fall für alle Dateien gelten soll, muss die Impersonation aktiviert werden oder die ASP.NET-Anwendung muss zur URL Authorization greifen.

Nachdem der Client identifiziert wurde, können über die Authorization bestimmte Zugriffsregeln auf Dateien und URLs für diesen Aufrufer festgelegt werden. Dabei unterstützt ASP.NET gleich zwei prinzipiell unterschiedliche Wege:

1. ACL Authorization (Zugriffsbeschränkung über die Access Control Lists des NTFS-Dateisystem)

2. URL Authorization (Zugriffsbeschränkung für Dateien, die ASP.NET bekannt sind, durch die CLR selbst)

ASP.NET stellt über die URL Authorization einen über die <i>Web.config</i> einfach zu konfigurierenden Zugriffsweg zur Verfügung. Im Authorization-Abschnitt können Zugriffsrechte über <i>allow</i> vergeben oder über <i>deny</i> verweigert werden.
&#10