SP2010: Security risk using “all users” in a multi tenant environment

I came across what I find to be a pretty big security risk when you’re working with multi tenant SharePoint environments.

Basically, it’s pretty simple. When you set up your environment and create a tenant, you have to specify the OU in which the accounts for this tenant live. This makes sure that your users cannot see accounts belonging to another tenant and vice versa. But you should be very aware that this filtering is only affecting stuff like the people picker. It’s not limiting access to your sites!

You might be used to granting all users access by using the “All users” groups found in the people picker. All users means: all users with a valid account. This is not limited by OU, it’s literally everyone!! So when you’ve got tenant A and tentant B setup, and you grant access to “All users” on a site belonging to tenant A, all users from tenant B will have access too.

This is most dangarous when you’ve got site administrators editing permissions on their sites and not realizing that they’re in a multi tenant environment. They might be tempted to use the all users group and not realise that this severely compromises security. Sure, the users of tenant B might not know that they’re in a multi tenant environment. And they probably don’t know the URL of tenant A’s sites. But still, you don’t want to grant access to users you don’t want on your site.

Ok so what are ways around this?

Your membership provider has an attribute called “userContainer“. This can be used to limit the scope in which the provider searches for users. That way, users belonging to a different OU won’t be validated and thus won’t have access to the site. A problem with this approach is that your own administrative accounts might not be in the tenants OU and thus lose access to the site as well. So you need to create extra admin accounts for each tenant.

When using a custom login page, you could implement your own code which checks for the OU the user belongs to. That way you could also allow your own administrative accounts (in a seperate OU) to have access. It requires some coding, but does the trick quite nicely.

As far as I know, those are your options. But feel free to leave other solutions in the comments below.

 

SP2010: Exporting site subscriptions in multi tenant setup

I created this little script I wanted to share, which loops though a web application; finds all site subscriptions (for multitenancy) and exports both the sites in there and the settings of the subscription. You could use the result to import the sites again into a test environment (for instance).


$url = "http://contoso.com"
$share = "\\server\backup\"

$wa = Get-SPWebApplication $url

foreach ($sub in $wa.SiteSubscriptions)
{
Write-Host Exporting site subscription $sub.Id

# create the folder (skipped when it exists
$folder = $share + $sub.Id
if(!(test-path $folder -pathtype container))
{
New-Item -Path $folder -ItemType directory
}

$exportPath = $folder + "\subscriptionsettings.bak"
Export-SPSiteSubscriptionSettings $sub -Path $exportPath -Force

foreach ($site in $sub.Sites)
{
Write-Host Exporting site $site.Id
$backupPath = $folder + "\" + $site.Id + ".bak"
Backup-SPSite $site -Path $backupPath -Force
}
}

There are some other scripts out there which use Get-SPSiteSubscription -ReturnSites, but that parameter doesn’t exist in my environments. I think it might be a left over from the beta phase. Also that script you would have to use per subscription, the script above works per web application. And with one more foreach-loop, you could run it across all webapplications too.