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.
Leave a Comment