asp.net WindowsImpersonationContext fonctionnent

Question

Quelqu'un peut-il expliquer s'il vous plaît la fonction des lignes ci-dessous:

WindowsIdentity wId = (WindowsIdentity)HttpContext.Current.User.Identity; 
WindowsImpersonationContext wIdCon = wId.Impersonate(); 

qui est utilisé sur une méthode POST avec l'authentification de base IIS et fonctionne très bien. Si toutefois l'authentification IIS est définie sur Windows, cela ne fonctionne plus.

Il y a simplement beaucoup trop de code à sauvegarder pour un exemple.

Answer 1

L'appel à Impersonate() fait qu'IIS prétend être l'utilisateur demandeur à partir de ce point. Ceci est utile pour un certain nombre de raisons, principalement que le code suivant ne fonctionnera que si l'utilisateur demandeur ne se voit pas refuser l'accès.

Cela fonctionne pour le basique car le site web reçoit le nom d'utilisateur et le mot de passe et peut donc se connecter en tant qu'utilisateur. L'authentification Windows échoue car elle utilise kerberos et reçoit uniquement un ticket faisant référence à l'utilisateur - pas le mot de passe de l'utilisateur. Pour que l'authentification Windows fonctionne, vous devez autoriser le compte de site Web (celui qui correspond à l'identité du pool d'applications pour votre application) aux utilisateurs d'usurpation d'identité. Ceci est fait dans l'onglet de délégation de leur compte dans Active Directory. Si elles n'ont pas d'onglet de délégation, vous devez d'abord ajouter un SPN (un nom principal de service). Le SPN permet aux clients de savoir quel compte est en cours d'exécution sur le site Web et donc comment crypter le ticket kerberos de sorte que le site puisse l'ouvrir. C'est tout un moyen de permettre au client et au serveur de parler sans se parler les uns les autres leurs mots de passe tant qu'ils font confiance à un tiers (le serveur AD dans l'implémentation MS standard).

Cela fait partie d'un problème commun connu sous le nom de double saut kerberos. tout provient du fait que Kerberos du client au site fonctionne (le site Web en sait assez sur les références des utilisateurs pour servir les pages etc) mais le second saut du site vers la ressource qui nécessite les informations d'identification des utilisateurs n'est pas donné eux comme le compte du site Web n'est pas autorisé à. Pour plus d'informations voir understanding-kerberos-double-hop on msdn

EDIT:

Essayez d'exécuter setspn /q http/machine_name_or_fqdn par exemple

setspn /q http/mywebbox
setspn /q http/mywebbox.my.domain.com

Quel utilisateur sont l'ensemble de ces spn contre? IIS doit avoir appPool pour le site Web en cours d'exécution en tant que même utilisateur que le nom principal de service. Une fois que vous avez confirmé cela, je suggère d'utiliser l'outil fiddler pour vérifier ce qui se passe entre le client et le serveur - confirmez que vous obtenez une réponse d'erreur 401 (c'est-à-dire que vous devez vous authentifier) ​​et réessayez immédiatement avec la requête ayant un en-tête kerberos valide.

Une fois que vous avez le client au serveur via parler kerberos, vous devez vous assurer le compte appPool a été mis en AD comme autorisé à déléguer au nom des utilisateurs.