Comments for Rob's Tech Fun and Games

Comment on Filtering the SharePoint People Picker Results by Rob

Rob — Tue, 02 Mar 2010 14:28:30 +0000

Another option, again limited to site collections, is to specify the OU for users for the site:

stsadm -o setsiteuseraccountdirectorypath -path “CN=Sales,DC=ContosoCorp,DC=local” –url http://server_name

which is great for locking down the users with access to a particular site. Sorry I can’t help with subsites though!

Comment on Filtering the SharePoint People Picker Results by Rob

Rob — Tue, 02 Mar 2010 11:26:15 +0000

@Greg
Actually, Greg, on reflection, the situation is even worse for you than I first thought! The PeoplePicker actually returns users from two locations – from a direct query against Active Directory (or whatever directory services you’ve set up), and against users that have actually “hit” the site collection … not subsite. Even if you wrote a specific LDAP query that managed to overcome the issue, you’ll still have incorrect users returned, I believe

A redesign based on site collections, writing a custom plugin to replace the people picker, or simply locking down the entire people picker from external access would seem to be your only options, in my opinion, of course.

Comment on Filtering the SharePoint People Picker Results by Rob

Rob — Tue, 02 Mar 2010 11:07:36 +0000

@Greg
Bad news, Greg. The security model (as relates to the peeople picker) is based around the Site Collection, not subsites. If you use site collections, then

stsadm -o setproperty –url http:// –pn peoplepicker-onlysearchwithinsitecollection –pv yes

would do exactly what you need. I’m not an LDAP specialist, and altering the query will affect the entire web application, so you need to be careful, but it might be possible to write custom LDAP scripts to return an appropriate subset of users with either the custom filter or custom query options, depending on your directory services configuration.

Out of the tin, SharePoint seems designed to work with Site Collections being the security scope, though, not subsites within them. Sorry for the negative response – I think you’d be better off working with site collections for customers, not subsites.

Comment on Filtering the SharePoint People Picker Results by Greg

Greg — Mon, 01 Mar 2010 18:47:13 +0000

@Rob
I have an issue where we are using subsite for different customers. When people participate on these separate subsites they can view all contacts (all of our customers) when searching using the people picker. Very Bad. Is there a way to only return results based on who has access ot that subsite?

Thanks
Greg

Comment on More People Picker issues by Rob

Rob — Mon, 08 Feb 2010 11:00:10 +0000

Have you tried manually specifying the domain list in the people picker, with user names and passwords that have access to view the AD? You need to specify these via the command line otherwise it will use the account that the service is running under, and if that doesn’t have access, neither will the people picker.

The mix of users signing in is probably due to a group membership that has been set somewhere. If you specify authenticated users to have access to a site, they’ll log on. Incidentally, normally after logging on via a group, you’ll see them showing up in the People Picker index, whether or not the People Picker can see the AD details beforehand.

In the import via the SSP, you specify a domain account in the GUI – the people picker won’t use this. It runs in the context of the service or usernames and passwords specified via stsadm.

Comment on More People Picker issues by Tom

Tom — Fri, 22 Jan 2010 21:00:20 +0000

Oh imports from the affected domain work perfectly still using the domain account given so its not a read right which is what peoplepicker should be doing.

Comment on More People Picker issues by Tom

Tom — Fri, 22 Jan 2010 20:58:17 +0000

We have not modified peoplepicker in anyway.
The tool only finds users in the site collections.
We have some users that can sign in and get access request page and then some that can actually sign in and see a page but still cannot be found in peoplepicker.
All trusts are correct.
Peoplepicker commands run
stsadm -o getproperty -url http://sitename -pn peoplepicker-onlysearchwithinsitecollection

stsadm -o setproperty -url http://sitename -pn “peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode” -pv no

We did get the AD commands to work yet we still cannot see users in peoplepicker unless they are already in the site.
This still only affects one domain and most can authenticate we just cannot add them to a site.

Comment on The SharePoint PeoplePicker isn’t showing users from a trusted domain by Tom

Tom — Fri, 22 Jan 2010 20:50:49 +0000

Also we have multple domains as well, all are two way and verified no issues.
only one domain has this issue default and another have no issues I can find those accounts.

Comment on The SharePoint PeoplePicker isn’t showing users from a trusted domain by Tom

Tom — Fri, 22 Jan 2010 20:48:57 +0000

We have the exact problem accept we have a two way trust and peoplepicker is only finding users inside their own sites.
We have verified that the property is not set it states “NO”
We have run almost in not all STSADM commands available no affect.
Reuilt the SSP’s and all WFE’S No affect.
Some users can sign in but have no access just get read only and some get request access page.
If they get request access page I can then add them.
Very weird scenario and have no clues this issue has been happening now for like 2 months and no body seems to have a clue not even Microsoft

Comment on Searching problems in SharePoint 2007 by Rob Schmidt

Rob Schmidt — Wed, 16 Dec 2009 04:03:33 +0000

Thanks so much! Your “third” item above saved our bacon.