Comment configurer IIS afin que les informations d'identification de domaine de l'utilisateur soient utilisées lors de la connexion au serveur SQL?

Question

Nous avons récemment publié la dernière version de notre application intranet, qui utilise désormais l'authentification Windows en standard, et doit être capable de se connecter à un serveur SQL configuré avec les informations d'identification du domaine de l'utilisateur final. Dernièrement, nous avons constaté que sur certains déploiements de clients, bien que IIS puisse voir les informations d'identification de domaine de l'utilisateur, il ne les transmet pas au serveur SQL. Au lieu de cela, il semble utiliser le compte anonyme. Ceci en dépit de suivre toutes les étapes correctes (en changeant la sécurité du répertoire pour Win Auth, en mettant à jour Web.Config pour utiliser Win Auth et en refusant les utilisateurs anonymes). J'ai fait beaucoup de lectures qui suggèrent que nous devons nous assurer que Kerberos est en place, mais je ne suis pas sûr (a) à quel point cela est-il valide (c'est-à-dire est-ce vraiment une exigence?) Ou (b) comment faire pour enquêter si c'est mis en place ou comment s'y prendre?

Nous sommes dans une situation où nous devons pouvoir configurer IIS ou l'application pour qu'elle fonctionne pour le client, ou expliquer au client exactement ce qu'il doit faire pour que cela fonctionne.

Nous avons réussi à reproduire cela sur notre réseau interne avec un serveur SQL de test et la boîte IIS d'un développeur, donc nous allons déranger avec cette configuration et voir si nous pouvons trouver une solution, mais si quelqu'un a des idées brillantes, je serais très heureux de les entendre!

Je voudrais particulièrement entendre les pensées ou les conseils des gens en termes de Kerberos. Est-ce une exigence, et si c'est le cas, comment expliquer aux clients comment cela doit être configuré? Oh, et j'ai aussi vu quelques personnes parler de la «règle classique d'un seul bond» pour les domaines et le passage des identifiants des fenêtres, mais je ne sais pas quel poids cela représente réellement?

Merci!

Matt

Answer 1

Ceci est appelé Double-Hop Problem et interdit la transmission des informations d'identification de l'utilisateur à des tiers. Cela se produit quand ils naviguent depuis une machine, contre un site sur un autre (premier saut), et en transmettant les informations d'identification à une troisième machine (deuxième saut).

Le problème ne s'affichera pas si vous hébergez IIS et SQL Server sur la même machine.

Il y a beaucoup plus de détails techniques publiés à How to use the System.DirectoryServices namespace in ASP.NET, ce qui explique le problème du double saut et les jetons primaires et secondaires.

Answer 2

Pour exécuter votre application sous les informations d'identification Active Directory ou Windows de l'utilisateur, assurez-vous ces:

• l'application IIS est configuré pour ne pas autoriser l'accès anonyme
• l'application IIS utilise Windows intégrée authentification

• votre chaîne de connexion doit avoir Integrated Security=SSPI pour vous assurer que les informations d'identification Windows/AD de l'utilisateur sont transmises à SQL Server.

  à savoir Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;

Answer 3

Vous indiquez que vous n'êtes pas sûr (e) de "comment enquêter, s'il est configuré ou comment le configurer".

Pour cela, je recommande chaudement un outil appelé DelegConfig. C'est une application très pratique que vous pouvez vous dire si kerberos est configuré correctement.

Décompressez-le dans un répertoire, configurez un répertoire virtuel dans IIS pour qu'il pointe vers celui-ci. Naviguez jusqu'à la page principale et dites-lui à quel serveur backend vous voulez autoriser l'accès (par exemple UNC, SQL, HTTP etc.) et il vous dira sa configuration correctement ou pas et expliquez pourquoi.

Il a même le abilty à recongiure les kerberos pour résoudre le problème si vous le désirez (même si je ne l'ai pas utilisé - je préfère ce reconfiguire moi-même pour comprendre ce que je l'ai fait à l'avenir)

Je me rends compte que cela arrive trop tard pour votre problème particulier, mais j'ai pensé que cela valait la peine d'être partagé par d'autres, surtout la capacité des outils à expliquer pourquoi la délégation fonctionne ou non. Je l'ai trouvé inestimable.