{"id":647,"date":"2012-07-26T10:26:15","date_gmt":"2012-07-26T09:26:15","guid":{"rendered":"http:\/\/blog.repsaj.nl\/?p=647"},"modified":"2012-07-26T10:26:56","modified_gmt":"2012-07-26T09:26:56","slug":"sp2010-security-risk-using-all-users-in-a-multi-tenant-environment","status":"publish","type":"post","link":"http:\/\/blog.repsaj.nl\/index.php\/2012\/07\/sp2010-security-risk-using-all-users-in-a-multi-tenant-environment\/","title":{"rendered":"SP2010: Security risk using &#8220;all users&#8221; in a multi tenant environment"},"content":{"rendered":"<p>I came across what I find to be\u00a0a pretty big security risk when you&#8217;re working with multi tenant SharePoint environments.<\/p>\n<p>Basically, it&#8217;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&#8217;s <strong>not limiting access<\/strong> to your sites!<\/p>\n<p>You might be used to granting all users access by using the &#8220;All users&#8221; groups found in the people picker. All users means: all users with a valid account. This is not limited by OU, it&#8217;s literally <strong>everyone<\/strong>!! So when you&#8217;ve got tenant A and tentant B setup, and you grant access to &#8220;All users&#8221; on a site belonging to tenant A, all\u00a0users from tenant B will have access too.<\/p>\n<p>This is most dangarous when you&#8217;ve got site administrators editing permissions on their sites and not realizing that they&#8217;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&#8217;re in a multi tenant environment. And they probably don&#8217;t know the URL of tenant A&#8217;s sites. But still, you don&#8217;t want to grant access to users you don&#8217;t want on your site.<\/p>\n<p>Ok so what are ways around this?<\/p>\n<p>Your membership provider has an attribute called &#8220;<strong>userContainer<\/strong>&#8220;. This can be used to limit the scope in which\u00a0the provider searches for users. That way, users belonging to a different OU won&#8217;t be validated and thus won&#8217;t have access to the site. A problem with this approach is that your own administrative accounts might not be in the\u00a0tenants OU and thus lose access to the site as well. So you need to create extra admin accounts for each tenant.<\/p>\n<p>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\u00a0administrative accounts (in a seperate OU) to have access. It requires some coding, but does the trick quite nicely.<\/p>\n<p>As far as I know, those are your options. But feel free to leave other solutions in the comments below.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I came across what I find to be\u00a0a pretty big security risk when you&#8217;re working with multi tenant SharePoint environments. Basically, it&#8217;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<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[34],"tags":[7,47,46],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p3KFR1-ar","_links":{"self":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/posts\/647"}],"collection":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/comments?post=647"}],"version-history":[{"count":0,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/posts\/647\/revisions"}],"wp:attachment":[{"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/media?parent=647"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/categories?post=647"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.repsaj.nl\/index.php\/wp-json\/wp\/v2\/tags?post=647"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}