Diff’rent Strokes for Diff’rent Folks… (Keeping your users separate between site collections in WSS 3 & MOSS 07)

As part of implementing a new site for a new client onto a shared environment, there are some things that need to be done to keep the sites completely independent from each other. One of those things is to restrict the people picker to not display users from the other site. For Example:

Fabrikam’s users should not be allowed to pick from a group of AD users that includes users from the Litware company. Contoso uses SQL Authentication and should not be allowed to pick from or see any AD users.

So how do you do it? Well, in an environment such as this, your MOSS Service accounts get their own individual Organizational Unit as do the Users for each SharePoint site. This allows you to apply Group policies like (for example) "No user within the Fabrikam OU can log on to any machine", as well as facilitating easier management of User and group objects.

image

Then you create separate application pools with separate App pool service accounts for each SharePoint site – this way, if the App Pool account gets locked out it only affects one site (This could happen when a service is set up to use the same account as the app pool to run, but the password is then changed on the account and the app pool). Minimize cross-site impact by sandboxing the applications as much as possible.

Then you open up Active Directory Users and computers, Click on the View Menu, then Advanced Features. This allows you to modify the security settings for each object within Active Directory including Org Units.

image

Create new Security groups called something like sec_MOSS_NoAccessFabrikam and sec_MOSS_NoAccessLitware – add them into the MOSS Service Account OU.

image

Add the App Pool user for Fabrikam’s MOSS Site into the Security Group sec_MOSS_NoAccessLitware.
Add the App Pool user for Litware’s MOSS Site into the Security Group sec_MOSS_NoAccessFabrikam.

image

Right-click on the Org Unit for the Fabrikam site users and go Properties. Under the Security Tab, Click "Add" and add the Security Group sec_MOSS_NoAccessFabrikam.

image

Assign the group sec_MOSS_NoAccessFabrikam Deny Full Control rights. Apply, OK. Rinse & Repeat for the other sites using AD Authentication.

There are 3 reasons for doing it this way.

# 1 – Deny overrules Allow, just like Rock Beats Scissors. Give that user virtually any access you want on the domain, and the deny rule will prevent enumeration of accounts in that OU (By default, Authenticated users have read on all AD objects)

# 2 – If you were naming your sec groups something like sec_MOSS_AllowAccessFabrikam and applying Deny security to that group on all other OU’s, then you can’t give users rights to enumerate users in more than one OU (See # 1)

# 3 – Using Allow-type groups to deny access (like in point # 2), You also then need to add All existing groups to each OU every time you create a new OU. With the method above, you are only adding the sec group to the OU once, then managing the users within the groups the same way you normally do.

For MOSS sites using SQL forms based authentication like Contoso’s site, you take a different approach – using functionality within STSADM.exe, you can prevent a site from doing AD lookups if the site uses Forms based Authentication.

From the STSADM.exe PeoplePicker Property name usage guide here…

http://technet2.microsoft.com/Office/en-us/library/f3f4f755-d9c8-4dbd-9caa-4faaa732da1d1033.mspx?mfr=true


Do not search Windows Active Directory when the current port is using forms authentication.

To search from a membership provider only, use the following syntax:

stsadm -o setproperty -url http://server -pn "peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode" -pv yes

To search a membership provider and Windows Active Directory, use the following syntax:

stsadm -o setproperty -url http://server -pn "peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode" -pv no

Note:

If the value is set to "Yes," the People Picker will not try to search or resolve a user against Active Directory if the current zone does not use Windows authentication.


Hope this is useful to anyone running an extranet, doing MOSS site hosting or running an intranet for multiple businesses belonging to the one parent company.

If you know of an easier way to do this, please add a comment.

Brad

Advertisements

About Brad Saide

I'm a SharePoint consultant. I'm also slowly going bald, seem to have a permanent spare tyre around my waist and enjoy socialising with friends over a beer or 10. The last 2 may possibly be related. Started working with SharePoint when the first version was in limited beta release (participated in the Technology Adoption Program while at Woolworths) and have been committed to the adoption of the technology as a business enabler ever since.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s