views:

1641

answers:

3

I would like to use integrated authentication to access a SQL database from a web part. It should use the IIS Application pool identity.

By default you will get the error:

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

Because in web.config impersonation is set to true:

<identity impersonate="true" />

I can set this to false and the database code will work. Anonymously accessed sites will also work. Any SharePoint site that uses authentication will fail however so this is not really a solution..

To solve this would I have to encapsulate all my database access code to run with elevated priviliges, is that how SharePoint does it internally? Somehow that doesn't seem like the most performant solution. Is that still the way to go, just use SQL security to access databases from SharePoint custom web parts?

A: 

This is incorrect. Because <identity impersonate="true" /> is set to true ASP.NET / IIS will run the thread as the user that is currently logged in (so not the app pool account but the actual user logged into the website).

Something else is going on here. Could you post your connection string for the custom database? (minus the private data off course)

Colin
Nothing special really.. connectionString="Data Source=sqlserver;Initial Catalog=Logging;Trusted_Connection=True" The difference is the site is under anonymous auth.. so there is no actual user logged into the website.
ArjanP
+3  A: 

Use SPSecurity.RunWithElevatedPrivileges to run your code in the context of the app pool identity.

Lars Fastrup
Lars, How do you feel about Daniel Larson's assertion that RunWithElevatedPriveges should be avoided when possible? He suggests using SPUserToken impersonation instead and gives an example here: http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1919.entry?sa=636841091-Tom
Tom Resing
+4  A: 

The <identity /> and <authentication /> elements in the web.config file will together determine the account that is used in to connect to SQL Server when using integrated authentication.

When <authentication mode="Windows" /> is configured, you're deferring to IIS to authenticate users. I'm guessing that your your web.config contains:

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

and that IIS is configured to allow anonymous users. Setting <identity impersonate="true" /> causes IIS to pass the identity of the IIS anonymous access account to SQL Server.

As Lars point out, using SPSecurity.RunWithElevatedPrivileges will achieve what you want. I don't believe you'll see any noticeable impact on performance but that's something you can test :-)

dariom
That database access is pretty pervasive throughout the site so I'd like to make an informed choice.. is SQL auth faster or slower than adding impersonation? I'll have to think about a test :-\
ArjanP
I really don't think it makes a difference (but that's still best tested in your environment). There's likely some negligible performance hit with impersonation and context switching, but I doubt it's noticeable. The pooling of SQL connections will be the same whether using SQL authentication or integrated security and a single impersonated identity (this isn't true if impersonating a bunch of different users). For the sake of security, I think integrated security is the best approach.
dariom