One of these days I had a challenging request: create a “multi-tenant” sharepoint app using a single instance and the same Active Directory.
This application was supposed to allow several companies to use a specific part of it.
For scalabilty reasons it was decided that this segregation could not be done at web application level – what would have made things easier- so the separation will be done at site collection level.
Critical Requirement: As any multi-tenant application, users from one company must not see/be aware of users from another company. It means that every time a sharepoint people picker is used, only users from the current company must be displayed/available.
Attempt #1 – Specify ad AD query for the people picker, using a powershell command, specifiying the peoplepicker-searchadcustomfilter value:
stsadm -o setproperty -url http://mysite -pn peoplepicker-searchadcustomfilter -pv (|(company=XYZCORP))
It doesn’t solve the problem. In this particular case I needed a separation at site collection (SPSite) level, and the searchadcustom filter is applied at web application level. If the application segregation was at web application level, it would have been ok.
Attempt #2 – Set the UserAccountDirectoryPath of the site collection. This time the change is operated directly on the Site Collection (SPSite). It allows the selection of a PATH on the AD, and only the users below this path will be available inside the SiteCollection (not true if an user outside the path is already part of the site collection).
To do so, it’s necessary to execute the following powershell command:
Set-SPSite -Identity http://server/sitecol -UserAccountDirectoryPath “OU=OrganizationalUnit,DC=Domain,DC=COM“
If you are not sure of the AD Path to use, take one of the users inside the organizational unit (let’s take JohnDoe as example) and perform the following powershell command:
dsquery user -name john*
The result will be something like:
Take out the CN part, and you have the path to the HumanResources Organizational Unit.