Nach der Bereitstellung meiner Website für IIS7.5 habe ich ein seltsames Verhalten festgestellt: Wenn die Identität des Anwendungspools standardmäßig ApplicationPoolIdentity ist (wie in IIS-Anwendungspoolidentitäten ), Ninject scheint ignoriert zu werden, da ich den folgenden Fehler erhalte, während ich das sehr erster Controller:
System.InvalidOperationException: Bei dem Versuch ist ein Fehler aufgetreten Erstelle einen Controller vom Typ ".. Hauptregler". Stelle sicher dass der Controller einen parameterlosen öffentlichen Konstruktor hat. --- & gt; System.DirectoryServices.DirectoryServicesCOMException: Ein Vorgang Fehler ist aufgetreten.
Ich habe versucht, FullAccess zu IIS AppPool\<MySiteAppPool> dem Ordner zuzuweisen, der die Site enthält (einschließlich aller Unterordner und Dateien), aber das hat nichts geändert.
Wenn ich jedoch die Identität des Anwendungspools auf einen Domänenaccount (auch einen einfachen, ohne Administratorrechte, sowie ohne Zugriff auf den Ordner mit der Site) setze, funktioniert er normal.
Ninject wird gemäß MVC3-Anwendung einrichten Tutorial durch das NuGet-Paket.
Ich bin mir nicht sicher, ob die Website in einem Domänen-Intranet mit Windows-Authentifizierung funktionieren soll.
Das einzige Problem scheint also die Identität des Anwendungspools zu sein. Soweit ich den empfohlenen Weg nutzen möchte, würde ich gerne das ApplicationPoolIdentity haben, kein Domänenkonto.
Woran kann das liegen? Ist es möglich, all diese miteinander zu vermischen?
Hier ist ein SO-Thread mit einem ähnlichen Problem: ASP.NET MVC 4 + Ninject MVC 3 = Kein parameterloser Konstruktor für dieses Objekt definiert . Aber auch hier keine passende Antwort.
Als gelöschter Kommentar habe ich versucht, NetworkSerive als Identität zu verwenden. Und es hat richtig funktioniert. Aber ich denke, das ist nicht viel besser als ein nicht-privilegiertes Domain-Konto.
BEARBEITEN
Plötzlich eine andere Abhängigkeit gefunden: Die Identität des Anwendungspools wird für die Windows-Authentifizierung auf SQL-Server verwendet, obwohl ich erwartet habe, dass die Anmeldeinformationen des clientseitigen Benutzers dort verwendet werden.
Basierend auf Kommentaren
Stimmen Sie zu, dass auf einen Remote-Sql-Server mit den authentifizierten Anmeldeinformationen über Identitätswechsel zugegriffen werden kann.
Es ist jedoch immer noch nicht klar, was das Problem mit ApplicationPoolIdentity und Ninject ist.
Der Artikel, der ganz oben in dieser Frage erwähnt wurde, hat mich vermuten lassen, dass dies daran liegen könnte, dass das virtuelle Konto kein Benutzerprofil hat . Dieser Aspekt bleibt mir unklar, da IIS weiterhin das Benutzerprofil mit dem Attribut LoadUserProfile laden kann. Ich kann nicht bekommen, was wird IIS laden, wenn es kein Profil für das virtuelle Konto gibt?
Es heißt dort:
IIS lädt nicht das Windows-Benutzerprofil, sondern bestimmte Anwendungen könnte es sowieso nutzen, um temporäre Daten zu speichern. SQL Express ist ein Beispiel für eine Anwendung, die dies tut. Jedoch ein Benutzer Profil muss erstellt werden, um temporäre Daten entweder in der Profilverzeichnis oder in der Registrierungsstruktur. Das Benutzerprofil für die NETWORKSERVICE-Konto wurde vom System erstellt und war immer verfügbar. Allerdings mit dem Wechsel zum eindeutigen Application Pool Identitäten, kein Benutzerprofil wird vom System erstellt. Nur der Standard-Anwendungspools (DefaultAppPool und Classic .NET AppPool) haben Benutzerprofile auf der Festplatte. Wenn das Benutzerprofil erstellt wird, wird kein Benutzerprofil erstellt Administrator erstellt einen neuen Anwendungspool.
Wenn Sie möchten, können Sie jedoch IIS-Anwendungspools zum Laden konfigurieren das Benutzerprofil, indem Sie das Attribut "LoadUserProfile" auf "true" setzen.
Ich habe den folgenden Thread auf serverfault.com gefunden:
Wie kann ich Weisen Sie der Standard-App-Pool-Identität die Active Directory-Berechtigung zu
Dort wird auch gesagt, dass die App-Pool-Identität nicht als Netzwerkdienst arbeiten kann, insbesondere die AD abfragen.
Aus dem Detail in der Frage klingt das sehr nach einem Berechtigungsproblem, bei dem ein COMException ausgelöst wird, was verhindert, dass Ninject MainController instanziiert. Die Ausnahme bezieht sich auf System.DirectoryServices , die Klassen, die zum Abfragen von Active Directory verwendet werden.
Wenn IIS unter den normalen App-Pool-Konten ausgeführt wird, verfügen diese Konten nicht über Berechtigungen zum Ausführen von Abfragen für Active Directory und es kann ein COMException ausgelöst werden. Ich denke, die eigentliche Nachricht in der Ausnahme (kann keinen parameterlosen Konstruktor finden) ist ein bisschen wie ein Ablenkungsmanöver und Ninject versucht, auf einen anderen Konstruktor zurückzugreifen, da der normale nicht funktioniert hat.
Das würde erklären, warum, wenn Sie den IIS-App-Pool so ändern, dass er als Domänenkonto ausgeführt wird, plötzlich funktioniert, weil dieses Konto berechtigt ist, die Domäne abzufragen.
Aus der Frage, ob du System.DirectoryServices selbst benutzt oder nicht, oder ob Ninject / IIS / ASP sie benutzt, ist nicht klar. Wenn Sie sie jedoch selbst verwenden, stellen Sie sicher, dass keiner der Konstruktoren in Ihren AD-Klassen Ausnahmen auslösen kann (fangen Sie sie ab und protokollieren Sie sie oder etwas), was verhindert, dass Ihre App beim Start abstürzt. Sie werden wahrscheinlich herausfinden, was ich oben über Berechtigungen gesagt habe.
Wenn IIS als normaler App-Pool-Account ausgeführt werden soll (was eine gute Idee ist), aber AD immer noch als Domänenbenutzer abfragt, können Sie die Anmeldeinformationen für DirectoryEntry und verwenden Sie DirectorySearcher , um die AD-Suche durchzuführen. Wenn Sie auf .Net 4 oder höher sind, empfehle ich die Verwendung des neuen System.DirectoryServices.AccountManagement Klassen (mit denen Sie auch Anmeldeinformationen angeben können).
Bei dieser Methode benötigen Sie keinen Identitätswechsel für AD-Abfragen. Ihr App-Pool kann weiterhin als normaler App-Pool-Account ausgeführt werden.
iispool \ appPoolName account nennt sich virtuelle accounts & amp; wurden zu Windows 2008 hinzugefügt. Die Idee ist, dass sie nicht wirklich Konten im eigentlichen Sinne sind. Was sie erlauben, ist eine verbesserte Sicherheit zwischen Prozessen, die das Basiskonto verwenden.
Viele Dienste auf Ihrem Computer verwenden networkService, ein eingebautes Konto mit Netzwerkzugriff. Wenn ein Angreifer einen dieser Dienste ausnutzen würde, wäre daher jeder andere Prozess verfügbar, der unter demselben Konto ausgeführt wird. Virtuelle Accounts, wie sie von IIS verwendet werden, verhindern dies, indem sie als unterschiedliche Accounts erscheinen, während sie immer noch dasselbe Konto sind - Ihre asp.net App läuft immer noch technisch als Networkservice & amp; dieses Konto Zugang zu Dingen zu gewähren, die noch funktionieren. Dies bedeutet auch, dass Sie, wenn Sie auf Netzwerkressourcen zugreifen müssen, die iispool-Konten tun müssten, da networkservice does & amp; Verwenden Sie den Domänenaccount der Maschine.
Wenn Sie auf einen Remote-SQL-Server zugreifen, ist dies das Konto, das Sie hinzufügen müssen, um den Zugriff von Ihrem Webserver zu ermöglichen. Ich würde nicht empfehlen, Identitätswechsel zu verwenden, es sei denn, Sie müssen wirklich sehen, wer der Benutzer auf dem SQL-Server ist. Die Sicherheit deiner App ist einfacher, wenn du sie auslässt.
warum Ihre Injektionen nicht funktionieren, könnte es sein, dass Ihre Abhängigkeiten fehlschlagen. wenn Controller A mit ClassB eingespritzt wird, der wiederum mit ClassC & amp; In dieser Klasse wird ClassD nicht injiziert, und die gesamte Kette schlägt fehl. Ich hatte das passiert & amp; Es dauerte eine Weile, bis ich merkte, dass es etwas war, das so weit von dem entfernt war, was ich sah.
Tags und Links asp.net-mvc-3 c# asp.net iis-7 ninject