Thursday, November 6, 2008

Still getting Access Denied when elevating rights?

In a previous post (elevated privileges) I explained how to access a SharePoint list when the actual user security is not enough.

You already did that and still get the same "Access Denied" message...?

When elevating rights we're using the SharePoint Web Site Application Pool user as the most privileged user the Web Application can use.

Look in your IIS logs and you should see a 401 somewhere. Yes?
That means that the user registered for the SharePoint web Site Application Pool doesn't have enough rights to access the list. In Simple deployments the common one is the Network Service account.

Now.., we need to change that and use a custom domain user as service account. Also it needs to be set as Service account in the server, or you'll get a "Service Unavailable" message in your browser when changing users.

To create a service account do as follows:

1- Create an account for the service in the domain i.e. DOMAIN\Svc_SharePoint
2- In the server excecute secpol.msc and head to Local Policies > User Rights Assignment > Log On as Service.
3- Add the DOMAIN\Svc_SharePoint service account
4- Add the DOMAIN\Svc_SharePoint service account to the IIS_WPG local group
5- Change the App Pool identity account to DOMAIN\Svc_SharePoint.
6- Recycle the App Pool (no need to reboot the server)

Be sure that the DOMAIN\Svc_SharePoint account has enough rights to access the List in the SharePoint collection and no more rights than that.

That should do the trick

Using ElevatedPrivileges in SharePoint Web Parts

Yesterday I found myself into a situation in which a custom web part couldn't reach a particular SharePoint list.

Situation:

Due to the current security schema, none user should have more than read access to the Root Collection Site and at the same time for centralizing purposes, a list was created on that Collection Site.
A particular web part located several levels down the collection needed access to that list, but as no common user had the appropiate permisison level it was returning the famous "Access Denied" screen.

Solution:

I needed to elevate the privileges on the web part at the time of accessing the list to solve the problem.

Guid RootSiteID = SPContext.Current.Site.ID;
Guid RootWebID = SPContext.Current.Site.RootWeb.ID;

SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite ElevatedsiteColl = new SPSite(RootSiteID))
{
using (SPWeb ElevatedSite = ElevatedsiteColl.OpenWeb(RootWebID))
{
rootList = ElevatedSite.Lists[_strSPListName];
}
}
});


Doing so, I could get the SPList rootList out of the site collection.

One important thing to remember is that you need to create a new SPSite and SPWeb within the RunWithElevatedPrivileges and not take them from the context in order to avoid using the current user "low privileges".