Comment configurer correctement l’identité du pool d’applications IIS 7?

Après avoir déployé mon site Web sur IIS7.5, j’ai constaté un comportement étrange: lorsque l’identité du pool d’applications est laissée à ApplicationPoolIdentity par défaut (comme recommandé dans Identités du pool d’applications IIS ), Ninject semble être ignoré, car l’erreur suivante Ninject lors de la création. le tout premier contrôleur:

System.InvalidOperationException: une erreur s’est produite lors de la tentative de création d’un contrôleur de type ‘..MainController’. Assurez-vous que le contrôleur a un constructeur public sans paramètre. —> System.DirectoryServices.DirectoryServicesCOMException: une erreur d’opération s’est produite.

J’ai essayé d’octroyer FullAccess à IIS AppPool\ dans le dossier contenant le site (y compris tous les sous-dossiers et fichiers), mais cela n’a rien changé.

Toutefois, lorsque je définis l’identité du pool d’applications sur un compte de domaine (même simple, sans privilèges d’administrateur, ni d’access au dossier contenant le site), cela fonctionne normalement.

Ninject est installé conformément au didacticiel ” Mise en place d’une application MVC3″ via le package NuGet.

Je ne suis pas sûr que, si c’est pertinent, le site est supposé fonctionner dans un intranet de domaine avec authentification Windows.

Donc, le seul problème semble être avec l’identité du pool d’applications. Dans la mesure où je suis désireux d’utiliser la méthode recommandée, j’aimerais avoir ApplicationPoolIdentity , pas un compte de domaine.

À quoi cela peut-il être connecté? Est-il possible de mélanger tous ces éléments?

Voici un thread SO avec un problème similaire: ASP.NET MVC 4 + Ninject MVC 3 = Aucun constructeur sans paramètre défini pour cet object . Cependant, il n’y a pas non plus de réponse appropriée.

Comme suggéré un commentaire supprimé, j’ai essayé d’utiliser NetworkSerive comme identité. Et cela a fonctionné correctement. Cependant, je suppose que ce n’est pas beaucoup mieux qu’un compte de domaine non privilégié.

MODIFIER

Soudainement, une autre dépendance a été trouvée: l’identité du pool d’applications est utilisée pour l’authentification Windows sur le serveur SQL, bien que je m’attende à ce que les informations d’identification de l’utilisateur côté client y soient utilisées.

Basé sur les commentaires

Acceptez qu’un serveur SQL distant soit accessible avec les informations d’identification authentifiées via l’emprunt d’identité.

Cependant, on ne sait toujours pas quel est le problème avec ApplicationPoolIdentity et Ninject.

L’article mentionné au sumt de cette question m’a fait supposer que cela pourrait être causé par le fait que le compte virtuel n’a pas de profil d’utilisateur . Cet aspect rest flou pour moi, car on peut toujours permettre à IIS de charger le profil utilisateur avec l’atsortingbut LoadUserProfile . Je ne peux pas obtenir ce que IIS va charger s’il n’y a pas de profil pour le compte virtuel.

On dit là:

IIS ne charge pas le profil utilisateur Windows, mais certaines applications peuvent en tirer parti pour stocker des données temporaires. SQL Express est un exemple d’application qui effectue cela. Cependant, un profil utilisateur doit être créé pour stocker des données temporaires dans le répertoire du profil ou dans la hive de registre. Le profil utilisateur du compte NETWORKSERVICE a été créé par le système et était toujours disponible. Cependant, avec le passage aux identités uniques du pool d’applications, aucun profil d’utilisateur n’est créé par le système. Seuls les pools d’applications standard (DefaultAppPool et Classic .NET AppPool) ont des profils utilisateur sur le disque. Aucun profil d’utilisateur n’est créé si l’administrateur crée un nouveau pool d’applications.

Toutefois, si vous le souhaitez, vous pouvez configurer des pools d’applications IIS pour charger le profil utilisateur en définissant l’atsortingbut “LoadUserProfile” sur “true”.

J’ai trouvé le fil suivant sur serverfault.com:

Comment atsortingbuer une autorisation Active Directory à l’identité du pool d’applications par défaut

Il est également indiqué que l’identité du pool d’applications ne peut pas fonctionner en tant que service réseau, en particulier interroger l’AD.

D’après les détails de la question, cela ressemble beaucoup à un problème d’permissions entraînant la COMException une COMException , ce qui empêche Ninject d’instancier MainController . L’exception est liée à System.DirectoryServices qui sont les classes utilisées pour interroger Active Directory.

Lorsque IIS est exécuté sous les comptes de pool d’applications normaux, ces comptes ne disposent pas des permissions nécessaires pour effectuer des requêtes sur Active Directory et une COMException peut être levée. Je pense que le message réel dans l’exception (impossible de trouver un constructeur sans paramètre) est un peu un piège rouge et que Ninject essaie de se rabattre sur un autre constructeur puisque celui-ci ne fonctionnait pas.

Cela expliquerait pourquoi, lorsque vous modifiez le pool d’applications IIS pour qu’il s’exécute en tant que compte de domaine, cela fonctionne soudainement, car ce compte est autorisé à interroger le domaine.

La question de savoir si vous utilisez System.DirectoryServices ou si Ninject / IIS / ASP les utilise n’est pas claire. Si vous les utilisez vous-même, assurez-vous qu’aucun des constructeurs de vos classes AD ne peut émettre d’exceptions (les intercepter et les consigner ou quelque chose du genre), ce qui empêchera votre application de tomber en panne au démarrage. Vous découvrirez probablement ce que j’ai dit ci-dessus à propos des permissions.

Si vous avez besoin que IIS s’exécute en tant que compte de pool d’applications normal (ce qui est une bonne idée) tout en interrogeant AD en tant qu’utilisateur de domaine, vous pouvez spécifier les informations d’identification à DirectoryEntry et utiliser DirectorySearcher pour effectuer la recherche AD. Si vous êtes sur .Net 4 ou supérieur, nous vous recommandons d’utiliser plutôt les nouvelles classes System.DirectoryServices.AccountManagement (qui vous permettent également de spécifier des informations d’identification).

Avec cette méthode, vous n’avez pas besoin d’emprunter l’identité pour les requêtes AD et votre pool d’applications peut toujours s’exécuter en tant que comptes de pool d’applications normaux.

Les comptes iispool \ appPoolName sont appelés comptes virtuels et ont été ajoutés à Windows 2008. L’idée est qu’ils ne sont pas vraiment des comptes au sens véritable. Ce qu’ils permettent, c’est une sécurité renforcée entre les processus utilisant le compte de base.

De nombreux services sur votre machine utilisent networkService, un compte intégré avec access au réseau. De ce fait, si un attaquant devait exploiter l’un de ces services, tout autre processus exécuté sous le même compte serait accessible. Les comptes virtuels, tels que ceux utilisés par IIS, empêchent cela en apparaissant sous différents comptes, tout en restant le même compte – votre application asp.net fonctionne toujours techniquement en tant que service de réseau et accorde à ce compte l’access à des éléments fonctionnant toujours. Cela signifie également que si vous avez besoin d’accéder à des ressources réseau, les comptes iispool le feront de la même manière que networkservice utilise et utilise le compte de domaine machines.

Si vous accédez à un serveur SQL distant, il s’agit du compte que vous devez append pour autoriser l’access depuis votre serveur Web. Je ne conseillerais pas d’utiliser l’emprunt d’identité, à moins que vous ayez vraiment besoin de savoir qui est l’utilisateur sur le serveur SQL. La sécurité de votre application est plus simple si vous la laissez désactivée.

quant à la raison pour laquelle vos injections ne fonctionnent pas, il pourrait y avoir une défaillance de vos dépendances. Si ControllerA reçoit une injection de ClassB, qui à son tour est injectée de ClassC et que cette classe ne parvient pas à l’injecter, toute la chaîne échouera. Cela m’est arrivé et j’ai mis du temps à comprendre que c’était quelque chose d’aussi éloigné de ce que je regardais.