Nachdem ich meine Website auf IIS7.5 bereitgestellt hatte, stellte ich ein merkwürdiges Verhalten fest: Wenn die Identität des Anwendungspools erhalten bleibtApplicationPoolIdentity Standardmäßig (wie in empfohlen)IIS-Anwendungspoolidentitäten),Ninject Scheint ignoriert zu werden, da beim Erstellen des allerersten Controllers die folgende Fehlermeldung angezeigt wird:

System.InvalidOperationException: Beim Erstellen eines Controllers vom Typ '..MainController' ist ein Fehler aufgetreten. Stellen Sie sicher, dass die Steuerung über einen parameterlosen öffentlichen Konstruktor verfügt. ---> System.DirectoryServices.DirectoryServicesCOMException: Ein Betriebsfehler ist aufgetreten.

Ich habe versucht zu gewährenFullAccess zuIIS AppPool\<MySiteAppPool> zu dem Ordner, der die Site enthält (einschließlich aller Unterordner und Dateien), aber dies hat nichts geändert.

Wenn ich die Anwendungspoolidentität jedoch auf ein Domänenkonto einstelle (auch auf ein einfaches Konto ohne Administratorrechte sowie ohne Zugriff auf den Ordner mit der Site), funktioniert dies normal.

Ninject ist laut installiertEinrichten einer MVC3-Anwendung Tutorial durch das NuGet-Paket.

Ich bin nicht sicher, ob die Site in einem Domänen-Intranet mit Windows-Authentifizierung funktionieren soll, wenn sie relevant ist.

Das einzige Problem scheint also die Identität des Anwendungspools zu sein. Soweit ich den empfohlenen Weg nutzen möchte, hätte ich gerne denApplicationPoolIdentity, kein Domain-Account.

Womit kann das zusammenhängen? Ist es möglich, all diese zusammen zu mischen?

Hier ist ein SO-Thread mit einem ähnlichen Problem:ASP.NET MVC 4 + Ninject MVC 3 = Für dieses Objekt ist kein parameterloser Konstruktor definiert. Allerdings auch dort überhaupt keine passende Antwort.

Wie ein gelöschter Kommentar vermuten lässt, habe ich versucht mitNetworkSerive als die Identität. Und es hat einwandfrei funktioniert. Ich denke jedoch, dass dies nicht viel besser ist als ein nicht privilegierter Domain-Account.

BEARBEITEN

Plötzlich eine andere Abhängigkeit festgestellt: Die Anwendungspoolidentität 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 mit den authentifizierten Anmeldeinformationen über Identitätswechsel auf einen Remote-SQL-Server 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, ließ mich annehmen, dass dies durch die Tatsache verursacht werden könnte, dass es sich um ein virtuelles Konto handelthat kein Benutzerprofil. Dieser Aspekt bleibt mir unklar, da man mit dem IIS noch das Benutzerprofil laden kannLoadUserProfile Attribut. Ich kann nicht abrufen, was wird IIS laden, wenn für das virtuelle Konto kein Profil vorhanden ist?

Dort heißt es:

IIS lädt das Windows-Benutzerprofil nicht, aber bestimmte Anwendungen nutzen es möglicherweise trotzdem, um temporäre Daten zu speichern. SQL Express ist ein Beispiel für eine Anwendung, die dies ausführt. Es muss jedoch ein Benutzerprofil erstellt werden, um temporäre Daten entweder im Profilverzeichnis oder in der Registrierungsstruktur zu speichern. Das Benutzerprofil für das NETWORKSERVICE-Konto wurde vom System erstellt und war immer verfügbar. Bei der Umstellung auf eindeutige Anwendungspoolidentitäten wird jedoch kein Benutzerprofil vom System erstellt. Nur die Standardanwendungspools (DefaultAppPool und Classic .NET AppPool) verfügen über Benutzerprofile auf der Festplatte. Wenn der Administrator einen neuen Anwendungspool erstellt, wird kein Benutzerprofil erstellt.

Wenn Sie möchten, können Sie jedoch IIS-Anwendungspools zum Laden des Benutzerprofils konfigurieren, indem Sie das Attribut "LoadUserProfile" auf "true" setzen.

Ich habe folgenden Thread auf serverfault.com gefunden:

Wie kann ich der Standardidentität des App-Pools Active Directory-Berechtigungen zuweisen?

Dort wird auch angegeben, dass die App-Pool-Identität nicht als Netzwerkdienst arbeiten kann, insbesondere den AD abfragen.