Emprunt d'identité et CredentialCache.DefaultCredentials donne HTTP 401 Non autorisé

Question

J'ai un service Web ASMX (sur mon hôte local - WinXP IIS 5.1) que j'appelle d'un client Web. Mon service Web doit consommer un autre service Web ASMX (sur un serveur Win 2003 IIS 6.0).

Quand je fournir des informations dans mon code webservice de manière "codées en dur":

engineWSE.Credentials = new System.Net.NetworkCredential("myUser", "myPass", "myDomain"); 

... l'invocation ultérieure du service Web distant fonctionne très bien. Maintenant, j'essaie de me faire passer pour un test initial. Ma première lecture sur ce qui me dit cela peut être un grand sujet, mais voici ce que je l'ai fait pour commencer:

1. UNCHECKED « accès anonyme » dans mon répertoire virtuel pour le site WebClient sur mon localhost

2. dans web.config de mon site webclient, j'ai créé: mode d'authentification = "Windows" et l'identité impersonate = "true"

3. dans le webmethod de mon webservice qui doit appeler le service à distance, I changé à:

   engineWSE.Credentials = System.Net.CredentialCache.DefaultCredentials; 
   

4. Lorsque le webservice distant s'invoqué avec ces DefaultCredentials, je reçois l'erreur suivante :

   System.Web.Services System.Web.Services.Protocols.SoapException: serveur n'a pas pu demande de processus .--->

   System.Net.WebException: La demande a échoué avec l'état HTTP 401: non autorisé.

   à System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse (message SoapClientMessage, réponse WebResponse, Stream responseStream, Boolean asyncCall)

   à System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke (String methodName, Object [] paramètres)

Je ne suis pas sûr que je l'ai mal compris et a essayé de trop simplifier « Impersonation » ou si le webservice à distance est en quelque sorte câblé à accepter que des informations d'identification avec 3 arguments (par exemple le nom d'utilisateur, mot de passe, domaine).

Answer 1

Avez-vous utilisé netmon ou wireshark pour vous assurer que les informations d'identification sont transmises? Quel est le journal du fournisseur de services qui vous le dit? Assurez-vous également qu'il n'y a pas de balise d'emprunt d'identité configurée dans web.config (ou autre .config).

EDIT:

Un bloc HostingEnvironment.Impersonate() peut-être - qui utilise l'identité du pool d'application par défaut, ou l'identité d'un utilisateur que vous passez jeton il.

Answer 2

Selon le MSDN suivant article, il ne fonctionnera pas pour les protcols HTTP et FTP. Vous devrez fournir explicitement les informations d'identification lorsque vous établissez une connexion au serveur distant.

Answer 3

@ Michael Kniskern - C'est certainement possible avec HTTP. La fonctionnalité d'emprunt d'identité transmettra les informations d'identification de l'application ASP.Net à IIS. Avec l'authentification Windows intégrée, les informations d'identification de l'utilisateur final seront utilisées à la place du compte ASPNET par défaut (ou du compte associé à l'App Pool). La mention de cet article MSDN à HTTP et FTP a été dirigée vers DefaultNetworkCredentials, je crois.

Answer 4

Il s'agit d'un problème double-saut classique: vous ne pouvez pas utiliser les informations d'identification utilisateur obtenues par emprunt d'identité pour accéder à un autre serveur sauf si la délégation Kerberos est correctement configurée dans votre domaine. Dupliquer de this question

Answer 5

Comme l'a dit @Michael Levy, c'est un problème de double saut. Cela signifie qu'à moins de configurer Kerberos (Negotiate), NTLM est probablement utilisé dans un environnement Windows exécutant IIS, ayant un client avec un navigateur sur la machine A essayant d'accéder au site sur la machine B aura accès au site MAIS, quand le site essaiera de contacter le service sur la machine C, les informations d'identification du pool devraient être utilisées à la place.

en est de même pour le site Web Un service d'appel B qui appelle à son tour le service C.

Lors de la configuration Kerberos pour les sites web, plusieurs choses doivent être prises en compte. Le premier est de savoir si c'est une ferme ou non. Si c'est le cas, vous devez définir un utilisateur commun pour le pool pour toutes les parties de la batterie. Cela est nécessaire car Kerberos utilise le nom de domaine pour identifier le principal utilisé pour crypter les jetons de sécurité. Si vous avez des utilisateurs différents sur des machines différentes de la même batterie, toutes les requêtes seront recherchées via le même nom de domaine. la même entrée. Des informations plus détaillées peuvent être trouvées ici au Kerberos and load balancing. Par exemple, supposons que vous ayez un site avec myApp.intranet comme URL. Dans AD, vous auriez un SPN défini sur, disons, myUser dans le domaine MyDomain (setspn -S MyDomain \ myUser HTTP/myapp.intranet). Lorsque la requête est envoyée au KDN (voir les liens kerberos à la fin pour plus d'informations sur le KDN), il retournera toujours un jeton chiffré avec myUser mais IIS essaiera de le déchiffrer avec différents utilisateurs. Il peut être tentant de créer plusieurs SPN pour un même service (HTTP/myapp.intranet) mais cela entraînerait une erreur KRB. De plus, si vous utilisez IIS 7+, vous devrez définir un petit détail dans votre ApplicationHost.config si vous voulez que l'authentification en mode noyau soit activée (ce qui est fortement recommandé): useAppPoolCredentials = true. Cette valeur doit être définie sur configuration \ system.webServer \ security \ authentication \ windowsAuthentication. C'est parce que par défaut, Kernel-mode auth will use the Computer account, pas le compte de pool et cela nous ramènerait au scénario multi-utilisateur.

Dans tous les cas, le Trust this user for ... of the Delegation tab de l'entité AD doit être activé pour que la délégation fonctionne. Vous devez ensuite décider si vous souhaitez utiliser une délégation générale ou contrainte.

Comme je l'ai dit précédemment, vous devez également définir un SPN pour le bon utilisateur et le bon service. L'utilisateur est assez facile à identifier car il sera celui que vous avez défini sur votre piscine mais le service peut être un peu compliqué selon votre configuration. DNS, navigateur et probablement d'autres variables peuvent changer ce qui devrait être utilisé. Nos essais et erreurs ont donné les résultats suivants:

• Si votre entrée DNS est une Une entrée, vous utilisez directement
• Si votre entrée est un CName, dans nos tests, il a utilisé la Une entrée qui lui est associée
• Nous avons eu des cas où le CName serait utilisé et il semblait être lié à la version du navigateur.

Notez que si aucun SPN est défini spécifiquement et que vous accédez à votre site Web par le nom NetBIOS, le service HTTP/machine sera demandée et que, par défaut, HOST service (search for extra) peut être utilisé à la place de HTTP si HOST/machine à serait utilisé. Cela peut être utile pour une configuration facile sur un petit réseau. Il convient également de garder à l'esprit que si vous souhaitez limiter les temps d'arrêt lorsque vous passez de NTLM à Kerberos, vous devez d'abord modifier ApplicationHost, puis utiliser SetSPN. Vous pouvez également désactiver la négociation avant toute action et conserver uniquement NTLM jusqu'à ce que tout soit configuré, puis, si possible, activer uniquement la négociation (sans NTLM). Cela devrait forcer les clients à modifier la façon dont ils accèdent à votre site Web. Si vous ne faites pas cela, le mécanisme de mise en cache semble avoir tendance à rester sur NTLM pendant un moment.

En espérant que cela peut aider. Si vous avez toujours un problème de configuration de Kerberos, WireShark est votre ami le plus fidèle. Vous pouvez trouver des informations sur le débogage de Kerberos dans les pages suivantes: - Debug Kerberos for a website - Debug AD problems with Kerberos (taille maximum de jeton est l'un d'entre eux) - Kerberos tools and other links - General network capture Kerberos debugging