Connexion de données du pool d'applications et du serveur SQL Asp.net

Question

J'ai une application asp.net qui s'exécute sur un pool d'applications personnalisé qui s'exécute sous un compte de niveau de service. J'ai un accès anonyme désactivé dans web.config. Le serveur Web fait partie d'un domaine. L'application accède à un serveur sql qui s'exécute sur la même machine.

Actuellement, pour tous les utilisateurs, j'emprunte l'identité du compte de niveau de service pour accéder à la base de données. Lorsque de nombreux utilisateurs accèdent au site, cela ralentit le site lorsque le processus lsass commence à utiliser le processeur.

Je ne suis pas autorisé à créer un compte SQL Server, je dois travailler avec ce que j'ai. Je ne suis également pas autorisé à ajouter chaque utilisateur individuel à la base de données et lui donner un accès spécifique. Ma question est, comment puis-je configurer ma reléion de l'application et de la base de données de telle sorte que je n'ai pas besoin d'usurper l'identité du compte de niveau de service et ainsi éviter l'effondrement du processeur lorsque l'utilisation du site est élevée.

Answer 1

Vous ne devriez pas avoir à emprunter l'identité du compte de service. Le compte de service est le compte qui a besoin d'accéder à la base de données et je suppose qu'il l'a déjà fait. Avez-vous déjà essayé d'exécuter votre application sans usurper l'identité du compte de service lorsque vous accédez à la base de données? Cela devrait fonctionner.

Pour effectuer un test simple, vérifiez l'identité renvoyée par WindowsIdentity.GetCurrent() (à l'intérieur de Page_Load par exemple). Cela devrait retourner l'identité du pool d'applications et c'est l'identité qui sera utilisée pour accéder à la base de données.

Bien sûr, cela ne fonctionne que si vous n'avez pas client impersonation configuré dans votre fichier Web.config. Mais puisque ce n'est pas une pratique générale, sauf pour certains cas de coin, je suppose que vous ne l'utilisez pas. L'usurpation d'identité n'est pas nécessaire pour déterminer qui est l'utilisateur actuel, vous ne devez l'utiliser que lorsque vous souhaitez accéder à des systèmes tiers (bases de données, fichiers, files d'attente, ...) en utilisant l'identité de l'utilisateur connecté n'est pas une approche très évolutive).