Fix access denied errors for Claims-based authentication sites for users with permissions

Wow this was a fun issue. A web application using Claims-based authentication started giving access denied errors to ALL users after setting the values of the PortalSuperUserAccount and PortalSuperReaderAccount properties of the web application.

I won’t write much because it’s all explained in this excellent blog post by Andras Gaal.

Essentially, if you setup the accounts and give them permission via Web App Policy – you have to assign the account values using the Claims ID (i:0#.w|domain\user), NOT the (domain\user) NTLM ID.

To set the properties, use PowerShell!

$webapp = Get-SPWebApplication http://webappurl
$webapp.Properties["portalsuperuseraccount"] = "<claimsId>
$webapp.Properties["portalsuperreaderaccount"] = <claimsId>

Access Denied while creating Publishing Pages

I ran into one of those weird errors that just kind of gets under your skin because you think you’ve checked everything.

You’ve all seen Access Denied errors in SharePoint, but have you run into the one where users WITH proper permissions get it when trying to create a list item – in this case Publishing Pages? Very bizarre.

I checked all of the usual suspects, permission inheritance, draft items in Style Library, Master Page Gallery, etc. Nothing. But then when I reached out to the search engines just for giggles, I found this post by Gunnar Peipman which gave me exactly what I needed.

The permissions on the Master Page Gallery are unique, and users need at least “Restricted Read” to create pages. What’s frustrating is if you go into Site Permissions and view the Uniquely Secured Content, Master Page Gallery DOES NOT show up in that list. You’d think it would show you all uniquely secured content, but that’s not the case.

Thanks Gunnar for the short post with the fix!

1.Go to Site Actions -> Site Settings ->Modify all site settings
2.Go to Galleries -> Master pages and page layouts
3.From the list toolbar, select Settings -> Document library settings
4.Select permissions for this document library
5.Add ‘Restricted Read’ access to the required groups.

Connect to External Content Type (ECT) using Impersonated Identity

While this might not be the best idea for exposing LOB data, there may be times when you want all authenticated users to have the ability to have read access to an External List. This can be accomplished fairly easy, using out-of-the-box tools and menus – no code needed.
Here’s how (Note: I’m assuming you already have working BDC and Secure Store Service Applications):
1. Create a new Secure Store Target Application, call it whatever you want – but make sure you choose Group as the type.
2. In the Target App contextual menu, use Set Credentials to apply the credentials you wish to use.
3. Create a new External Content Type (or edit an existing) – in the External System settings, enter the DB Server, DB Name and choose Connect with Impersonated Windows Identity. Enter the name of your Target Application in the Secure Store Application ID field.
4. Create an External List using your new External Content Type. It should work for anyone who has permissions to the SPWeb.
It’s really as simple as that, and I’m mainly blogging this because as simple as it is – I continue to forget a step here and there. 🙂

Using PowerShell to make an entire web application read-only

STSADM.exe was great in SharePoint 2007. It provided some really good functionality, some of which was not available in the GUI. STSADM is still available in SharePoint 2010, but why anybody would use it is beyond me. PowerShell is not only much more powerful (hence the name), but it’s here to stay.
There are loads of examples of scripts online for various SharePoint tasks, and there are lots of one-offs that I’ve made scripts for that I doubt anybody else would use; however, there is one thing I think everyone may want at some point, the ability to make an entire web application read-only. Could you make the content database read-only? Sure, but maybe you want just the sites to be read-only.
In 2007, you could set a site collection as read-only via STSADM; but I was never able to find a “good” way to make an entire web application read-only. In SharePoint 2010, it’s very easy with a few commands and a ForEach loop.
Here’s the advanced function:
function Set-LockState {
Use this PowerShell script to set the Lock State of a SharePoint Web Application to Unlock, ReadOnly, NoAdditions or NoAccess.
This PowerShell script uses Set-SPSiteAdministration to set the Lock State of a SharePoint Web Application.
C:\PS>.\SetAllSitesInAWebAppToReadOnly.ps1 -WebAppUrl http://intranet -LockState ReadOnly
This example sets all site collections in a web application at http://intranet to read-only.
This PowerShell script sets the Lock State of a SharePoint Web Application.

## Input Parameters ##
[string]$WebAppUrl=(Read-Host "Please enter a Web Application URL (Example: http://intranet)"),
[string]$LockState=(Read-Host "Please enter a Lock State (Examples: Unlock, ReadOnly)")
## Add SharePoint Snap-in ##
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
### No need to modify these ###
$WebApp = Get-SPWebApplication $WebAppUrl
$AllSites = $WebApp | Get-SPSite

############################# The Script - no need to modify this section #############################
## Start SP Assignment for proper disposal of variables and objects ##
Write-Host "Starting SP Assignment..." -ForegroundColor Green
Start-SPAssignment -Global
## Use a ForEach-Object loop and Set-SPSiteAdministration to set an entire web application ##
Write-Host "Setting $WebAppUrl to $lockState..." -ForegroundColor Yellow
$AllSites | ForEach-Object { Set-SPSiteAdministration -LockState $lockState -Identity $_.url }
## End SP Assignment for proper disposal of variables and objects ##
Write-Host "Disposing of SP Objects.." -ForegroundColor Green
Stop-SPAssignment -Global
## Tell us it's done ##
Write-Host "Finished!" -ForegroundColor Green