Securing SharePoint’s People Picker for Extranet use

Artikkeli
08/28/2008

About People Picker

One of the often used features of SharePoint (WSS 3.0 and MOSS 2007) is People Picker. This is the component responsible for providing a fancy user interface for finding users when provisioning access:

By default, which in this context means - “I did a full installation of MOSS 2007 with mostly default settings and didn’t pay particular attention to securing anything” – People Picker is not secure.

Main issue with People Picker is that it’s accessible for regular users of a given site. Thus by accessing /_layouts/aclinv.aspx">https://<portal>/_layouts/aclinv.aspx anyone with basic access to the site can list and view existing users of the system:

By typing 'a' as the user and hitting search one can review a list of accounts that match this search term. Obviously this isn't a big issue in intranets and similar closed systems where trust is already given for that particular user performing the search. For anonymous sites (public WCM-sites mostly) lockdown mode should resolve most issues related to /_layouts/ application pages. See this article for more details: https://technet.microsoft.com/en-us/library/cc263468.aspx#section6.

What additional approaches can you take to secure People Picker?

Modifying People Picker behavior with stsadm.exe

Stsadm.exe (with SP1) enables you to control People Picker with the following properties:

peoplepicker-activedirectorysearchtimeout
peoplepicker-distributionlistsearchdomains
peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode
peoplepicker-onlysearchwithinsitecollection
peoplepicker-searchadcustomfilter
peoplepicker-searchadcustomquery
peoplepicker-searchadforests
peoplepicker-serviceaccountdirectorypaths

These are well documented here: https://technet.microsoft.com/en-us/library/cc263318.aspx.

Deny access to /_layouts/aclinv.aspx

It would also be a good idea to deny access to /_layouts/aclinv.aspx. For some reason SharePoint doesn't have a built-in security authorization for this given application page like it has for settings.aspx. A proper approach would be to filter access to this given application page on the border firewall.

Alternatively, brewing your own HTTP Handler to filter out requests is also a viable option. See this article for more details: https://msdn.microsoft.com/en-us/library/bb457204.aspx

Modify /_layouts/aclinv.aspx

You should know that modifying anything underneath /_layouts/ probably breaks any support, so proceed with caution.

Modifying aclinv.aspx has its advantages too. This is the control from aclinv.aspx that renders People Picker:

<wssawc:PeopleEditor
    AllowEmpty=false
    ValidatorEnabled="true"
    id="userPicker"
    runat="server"
    ShowCreateButtonInActiveDirectoryAccountCreationMode=true
    SelectionSet="User,SecGroup,SPGroup"
/>

Several properties exist that can help in securing People Picker functionality:

ValidatorEnabled [true, false]: Set to false to disable validation of user accounts
Rows [#]: Set to 1 to prevent multiple user access
ShowButtons [true, false]: Set to false to disable the two functional buttons (check names and addressbook)
ValidateResolvedEntity [true, false]: Set to false to prevent validation of resolved entity
UrlZone [Custom, Intranet, Extranet, Internet, Default]: Specify with zone (AAM) to use for this control. Might be handy to set this to Intranet only

Hope this helps :)

Comments

Anonymous
August 27, 2008
PingBack from http://hubsfunnywallpaper.cn/?p=2759
Anonymous
December 15, 2008
Thanks jro for this article! Is it possible to use the PeopleEditor control in a custom web part in anonymous mode?
Anonymous
December 15, 2008
Hi Vadim, I think PeopleEditor requires a valid user token to work, since it queries content from user repositories (such as AD) and anonymous access would probably not be a good idea.
Anonymous
December 16, 2008
Hi jro, Thanks again for your quick response. I'm trying to figure out why a PeopleEditor control in my custom web part becomes invisible for anonymous users. Could you please give me a hint - is that normal behavior of the control or there is something wrong in my code?
Anonymous
December 16, 2008
Hi Vadim, I can't really tell why or how it works like that without seeing the implementation. I suppose the control assumes a Windows Identity or similar in order to be usable.

Jaa