ASP.Net application web en essayant d'utiliser l'emprunt d'identité et de la Délégation à se connecter à SQL Server
Je suis en train d'utiliser l'emprunt d'identité et de la Délégation dans un intranet ASP.Net web-app afin de passer authentifié informations d'identification des utilisateurs sur un Serveur SQL.
Le serveur web et SQL server sont deux machines distinctes, mais dans le même domaine, de sorte que la Délégation est nécessaire.
J'ai effectué les opérations suivantes:
- ensemble
<authentication mode="Windows"/>
et<identity impersonate="true"/>
dans mon web-app web.config. - permis à la Délégation Contrainte de du serveur web au service MSSQLSvc sur le Serveur SQL server, Active Directory.
- activé uniquement l'Authentification Windows dans le site web, par l'intermédiaire de IIS.
Apparemment ce doit tous les travaux, mais il n'a pas (le Serveur SQL est le refus de l'accès à l'utilisateur anonyme - "échec de la Connexion de l'utilisateur "NT AUTHORITY\ANONYMOUS LOGON'").
Dans IIS7, le Pool d'Applications est configuré pour utiliser Intégrée Pipleline Mode et est en cours d'exécution avec le service réseau de l'Identité. Le site a uniquement l'Authentification Windows est activée, la Protection Étendue est Éteint, en mode Noyau de l'authentification est activée, et NTLM est le fournisseur.
Toutes les pages web que j'ai lu semble indiquer que mon installation devrait fonctionner. Ce qui me manque?
anonymous user
ont accès à la base?L'utilisateur anonyme n'a pas accès à la base de données. Je ne veux pas que l'utilisateur anonyme accéder à la base de données, je veux de l'actuel de l'utilisateur du site web. La délégation devrait signifier que l'utilisateur actuel est le seul accès à la base de données, plutôt que l'utilisateur anonyme.
OriginalL'auteur Graham Clark | 2010-01-20
Vous devez vous connecter pour publier un commentaire.
J'ai découvert la réponse:
Le fournisseur d'Authentification Windows dans IIS7 doit être mis à Négocier:Kerberos, pas NTLM. Cela signifie que l'authentification en mode Noyau paramètre doit être désactivé. Cela semble aller pour le mieux. Je pense que j'ai raison en disant que le Kernel-mode d'authentification est requis lors de l'utilisation d'une identité personnalisée, c'est à dire une identité spécifique. La délégation peut utiliser un nombre arbitraire d'identités. Donc, tout est bien.
J'ai écrit un post de blog à propos de cette trop, qui va dans un peu plus en détail.
Avez-vous eu des problèmes avec les utilisateurs de ne pas obtenir leurs informations d'identification transmis à l'instance de SQL server lorsque vous utilisez un navigateur autre que Internet Explorer? J'ai trouvé que, une fois qu'ils ont établi une session dans IE, alors que le site web peut déléguer leurs pouvoirs s'ils passer à un autre navigateur.
OriginalL'auteur Graham Clark
Pas - il n'est pas exact de dire que vous avez besoin de Kerberos, un nom principal de service, de faire confiance au serveur pour la délégation, et que c'est la SEULE façon de le faire. Oui, c'est une façon de le faire (et vous avez besoin de tout cela pour le faire via Kerberos), mais il n'est pas le SEUL moyen, ou même techniquement le plus sûr moyen ou la manière la plus simple. Voulez-vous vraiment avoir à faire des configurations supplémentaires et de créer un compte de connexion pour chaque utilisateur web à votre base de données dans SQL? Que faire si l'un de ces comptes est-il compromis? Plus de comptes, plus de vulnérabilités.
Pas, créer un compte de service de Domaine, au lieu de cela, et de laisser l'accès SQL. Si votre sécurité gars de verrouiller les choses, de donner à l'utilisateur les droits suivants: ouverture de session en tant que service, ouvrez une session en tant que tâche, et d'Autoriser l'ouverture de session localement. Ou, si c'est juste pour développer et tester la théorie ou vous ne se soucient pas ou ne pouvez pas trouver les paramètres ou encore les erreurs plus tard, et ce ne pourriez pas obtenir une grande suite, mais il donner à l'Administrateur local (parfois, tu dois faire ce que tu dois faire - certains professionnels de l'informatique sécurité verrouiller les choses plus serré que je ne le soin d'écrire à propos - peut toujours dépanner de sécurité plus tard pour le verrouiller en arrière vers le bas). Ensuite définir ce compte comme compte personnalisé sur l'application de la piscine et de donner à ce compte de connexion SQL. Donner dbo sur UNE seule base de données.
Sur le site web dans IIS, définir le type d'authentification de Windows. Je les ai vu dire "de Base" dans d'autres blogs afin de Kerberos fonctionne, mais NTLM utilise l'authentification Windows. Dans IIS 7, vous pouvez également activer ASP .NET de l'emprunt d'identité. Personnellement, je ne l'ai essayé sur IIS 6, mais le principal est le même.
Dans le web.config, ajouter ce sous
<configuration>
, qui est un "pair" à<system.web>
:Et dans
<system.web>
:Alors lisez la chaîne dans votre application comme ceci:
Voir http://msdn.microsoft.com/en-us/library/ms178411.aspx.
Si elle ne peut pas se connecter avec le compte de service après le remplissage en compte dans le web.config pour emprunter l'identité de la balise et de la connexion SQL, vous pouvez utiliser l'emprunt d'identité à l'aide de méthodes WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). Plus précisément, vous voulez wic.Usurper l'identité d'() et wic.Annuler() après l'obtention de leur jeton. Vous pouvez le lire dans le compte de service de domaine, le nom et le mot de passe à partir du web.config, sous la forme de AppKeys.
En bref, il ya des façons de contourner les problèmes. Vous pouvez même crypter le mot de passe dans le web.config - à la fois dans la propriété ConnectionString, et si vous souhaitez le stocker dans un AppKey, plutôt que directement dans le "emprunter l'identité" de la balise, si vous ne voulez pas de texte en clair des mots de passe (que je déconseille), et donc vous pouvez l'avoir pour la création d'un jeton de Connexion, si vous avez besoin d'utiliser l'emprunt d'identité méthodes (comme je l'ai fait).
euh, j'ai donné toutes les étapes nécessaires à "utiliser l'emprunt d'identité et de la Délégation dans un intranet ASP.Net web-app afin de passer authentifié informations d'identification des utilisateurs sur un Serveur SQL server". Cela nécessite 1) un svc compte, 2) les droits dans la Politique Locale de Sécurité (décrit ci-dessus) 3) les droits dans SQL (dbo - décrit ci-dessus), 3) ajouter un compte de Pool d'applications de l'identité, 4) Site Web dans IIS pour l'authentification Windows, 5) set conn chaîne dans le web.config, 6) jeu de balise de l'authentification et de l'identité dans le web.config, 7) ajouter la chaîne de connexion dans le code, 8) utiliser l'emprunt d'identité de code MSDN à l'adresse le lien s'il ne fonctionne pas.
Des milieux différents, on va avoir des droits différents, d'autant que les comptes aller, et il peut ou peut ne pas avoir des privilèges à accorder au compte les droits dont il a besoin. Sans la connaissance de son environnement, il est difficile de donner les détails de exactement ce que sera le travail. Il faudra essayer de donner le svc acct les droits que j'ai précisé, et configurer le site web et le web.config. Peut-être qu'il va travailler sans MSDN code de l'usurpation d'identité, peut-être pas. Pour mon application, j'ai eu tout juste de terminer quand j'ai posté ces étapes, j'en avais besoin. Pour celui que j'ai fait récemment, à l'aide de Kerberos, Spn, et un svc acct, je n'ai pas.
Comment est ce passage de l'utilisateur de SQL? Votre web.config extrait de a l'application imitant le compte de service, pas l'utilisateur.
Ainsi, depuis votre solution n'est pas en utilisant les identifiants de l'utilisateur à authentifier la session SQL, vous n'êtes pas à répondre à la question. Vous avez dit Graham ce que vous pensez qu'il devrait faire au lieu de lui dire comment faire ce qu'il veut faire.
OriginalL'auteur vapcguy