SharePoint et <identity impersonate = "false" />

Je souhaite utiliser l'authentification intégrée pour accéder à une base de données SQL à partir d'un composant WebPart. Il doit utiliser l'identité du pool d'applications IIS.SharePoint et <identity impersonate = "false" />

Par défaut, vous obtiendrez l'erreur:

System.Data.SqlClient.SqlException: Login failed for user 'SERVER\IUSR_VIRTUALMACHINE'.

Parce que dans web.config usurpation d'identité est définie sur true:

<identity impersonate="true" />

je peux mettre à false et le code de base de données fonctionnera. Les sites accessibles anonymement fonctionneront également. Pour résoudre ce problème, est-ce que je devrais encapsuler tout mon code d'accès à la base de données pour fonctionner avec des privilèges élevés, est-ce que SharePoint le fait en interne? D'une certaine manière, cela ne semble pas être la solution la plus performante. Est-ce toujours la solution, utilisez simplement la sécurité SQL pour accéder aux bases de données à partir des composants WebPart personnalisés de SharePoint?

Source

2009-06-30 ArjanP

Les éléments <identity /> et <authentication /> dans le fichier web.config détermineront ensemble le compte utilisé pour se connecter à SQL Server lors de l'utilisation de l'authentification intégrée.

Lorsque <authentication mode="Windows" /> est configuré, vous passez à IIS pour authentifier les utilisateurs. Je devine que votre web.config contient:

<authentication mode="Windows" /> 
<identity impersonate="true" />

et que IIS est configuré pour autoriser les utilisateurs anonymes. Le paramètre <identity impersonate="true" /> permet à IIS de transmettre l'identité du compte d'accès anonyme IIS à SQL Server. Comme le souligne Lars, l'utilisation de SPSecurity.RunWithElevatedPrivileges permet d'obtenir ce que vous voulez. Je ne crois pas que vous verrez un impact notable sur les performances, mais c'est quelque chose que vous pouvez tester :-)

Source

2009-06-30 07:30:07 dariom

Cet accès à la base de données est très répandu dans tout le site donc je voudrais faire un choix éclairé ... SQL Auth est-il plus rapide ou plus lent que l'ajout d'une usurpation d'identité? Je vais devoir penser à un test: - \ – ArjanP

Je ne pense vraiment pas que cela fait une différence (mais c'est encore mieux testé dans votre environnement). Il y a probablement un impact négligeable sur les performances avec l'usurpation d'identité et le changement de contexte, mais je doute que ce soit perceptible.La mise en commun des connexions SQL sera la même, qu'il s'agisse d'une authentification SQL ou d'une sécurité intégrée et d'une seule identité empruntée (ce qui n'est pas le cas si l'on usurpe l'identité d'un groupe d'utilisateurs différents). Pour des raisons de sécurité, je pense que la sécurité intégrée est la meilleure approche. – dariom

Ceci est incorrect. Parce que <identity impersonate="true" /> est défini sur true ASP.NET/IIS exécutera le thread en tant qu'utilisateur actuellement connecté (donc pas le compte du pool d'applications mais l'utilisateur réel connecté au site Web).

Quelque chose d'autre se passe ici. Pourriez-vous publier votre chaîne de connexion pour la base de données personnalisée? (moins les données privées hors cours)

Source

2009-06-30 05:59:44 Colin

Rien de spécial vraiment .. connectionString = "Data Source = SQLServer; Initial Catalog = Logging; Trusted_Connection = True" La différence est que le site est sous authentification anonyme. Il n'y a donc pas d'utilisateur connecté sur le site. – ArjanP

Utilisez SPSecurity.RunWithElevatedPrivileges pour exécuter votre code dans le contexte de l'identité du pool d'applications.

Source

2009-06-30 07:19:25

Lars, Que pensez-vous de l'affirmation de Daniel Larson selon laquelle RunWithElevatedPriveges devrait être évité autant que possible? Il suggère d'utiliser l'usurpation d'identité SPUserToken à la place et donne un exemple ici: http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1919.entry?sa=636841091 -Tom –

SharePoint et <identity impersonate = "false" />

Répondre

Questions connexes