Nous avons une instance de IIS6 exécutant un site Web intranet avec l'authentification Windows et Impersonate = true afin qu'il utilise les informations d'identification NT transmises par le navigateur des clients. AppPool est configuré pour s'exécuter en tant qu'utilisateur de service réseau: serviceAcctX afin que nous puissions annuler l'emprunt d'identité dans de rares cas (lire ou écrire une ressource à laquelle l'utilisateur client n'a pas accès)IIS déplacement du répertoire virtuel vers le partage de fichiers interrompt l'usurpation de l'utilisateur connecté
Fonctionne parfaitement lorsque la source du répertoire virtuel est sur un lecteur local. L'utilisateur connecté est authentifié et le contenu de la page est personnalisé en fonction des paramètres d'autorisation.
Notre équipe d'infrastructure tente de déplacer la source du répertoire virtuel vers un partage de fichiers sur un serveur distant. Nous avons déjà passé le problème avec la modification de la stratégie de sécurité .Net en ajoutant une approbation complète pour ce chemin de partage de fichiers spécifique. Nous avons défini la propriété Connect As sur le même serviceAcctX, le même que celui exécuté par AppPool.
Le site commence bien. Cependant, l'utilisateur du client n'est pas usurpé. La demande est traitée en utilisant les informations d'identification par défaut serviceAcctX au lieu de avec les informations d'identification NT du client comme avant.
Existe-t-il un moyen de faire en sorte que l'emprunt d'identité client fonctionne toujours comme avant et ait toujours le répertoire virtuel sur un partage de fichiers? Tous les pointeurs sont grandement appréciés.
Je ne suis pas sûr que ce soit la bonne solution. La délégation n'est pas le problème ici. Le problème est que le processus de travail est généré avec les informations d'identification serviceAcctX au lieu des informations d'identification des utilisateurs connectés comme précédemment. – Tion