If you think the SharePoint security model shields you from any security – or, more precisely, privacy – concern when it comes to your public-facing SharePoint sites, think again. As a matter of fact, privacy has never been a huge concern for SharePoint, simply because SharePoint was originally built for – and still mostly caters to – internal users who want to collaborate with each other. However, over the years, SharePoint usage has gone beyond intranets and crossed over to extranets and even public-facing, anonymous web sites. Microsoft has acknowledged that shift and even encouraged those alternative usages of SharePoint, for instance by issuing detailed extranet topologies.

However, one area that is often overlooked in extranet scenarios is the privacy area, and more specifically, the answer to the following question: can I guarantee that my external users don’t know about each other, unless I want them to?

As the saying goes, a picture is worth a thousand words and, should I add, a video is worth a thousand pictures:

Now for those who prefer to get the lowdown on the issue in writing, let’s start again with the question:

Can I guarantee that my external users don’t know about each other, unless I want them to?

That’s obviously not a question that is asked in internal SharePoint deployments, because we implicitly assume that you can get access to the professional details of all your colleagues, whether it is through Outlook, the corporate org chart or other internal applications such as SharePoint. As a matter of fact, SharePoint makes it very easy to access details about your colleagues. Whenever you see the name of a colleague show up on a SharePoint site, you can click on her name and access either:

1. her SharePoint Foundation User Information page (if you use SharePoint Foundation) or
2. her SharePoint Server Profile page (if you use SharePoint Server)

Of course, you can also access your colleagues’ information through the dedicated People Search of SharePoint Server (if it has been enabled) and there are probably some other ways to sift through your colleagues’ professional profiles. But unless you are really looking for someone (and you have access to some People Search engine), in 99% of the cases, you will access those profile pages when you click on the author of a document (or list item) or on a person assigned to a task (and more generally any Person field in a SharePoint list).

So what “privacy hole” are we talking about here?

Good question, indeed! At this point, you might feel like this privacy hole has to do with the 2 profile pages I mentioned above and you would be right indeed! But in order to properly answer that question, we must investigate a bit more what those profile pages are and how they work.

The SharePoint Foundation User Information page

The SharePoint Foundation User Information page (also referred to as the “userdisp.aspx page“) is a page hosted in the _layouts folder of SharePoint, more precisely at [SiteUrl/_layouts/userdisp.aspx (which redirects to [SiteUrl]/_layouts/15/userdisp.aspx in SharePoint 2013). This page displays the user information available in the SharePoint’s User Information List, a hidden list only site collection administrators and site owners can access at [SiteCollectionUrl]/_catalogs/users.

If you only use SharePoint Foundation, whenever you click on ‘My Settings’ in the SharePoint Welcome Menu, you will redirected to that userdisp.aspx page. For instance, if you are browsing a page in the http://partners.company.com site, your ‘My Settings’ page will always point you to http://partners.company.com/_layouts/15/userdisp.aspx (or http://partners.company.com/_layouts/userdisp.aspx in SharePoint 2010).

Conversely, whenever you click on a person’s name, you will be redirected to that userdisp.aspx page with an ID parameter followed by an integer. For instance, the Url of the page could be http://partners.company.com/_layouts/15/userdisp.aspx?ID=15 . The ID parameter corresponds to the internal ID of the user in the User Information List and is incremented every time a new user signs in.

The information you will find on that page might be a bit different depending on the authentication source of the user, but generally speaking, you should see that 3 fields are populated by default: Account, Name and E-Mail:

The screenshot above shows the information available for a Windows user. For FBA users, the Name property will default to the username instead (unless you perform some special processing to display the user’s full name – as we do in Extradium):

For SAML users (i.e. users who authenticate through a Trusted Identity provider such as ADFS), you will most likely only see the Account field, unless some further processing is done on the SharePoint side (at least, that’s my current understanding, but SharePoint may be smarter if your identity provider provides some claims SharePoint knows how to process).

You can’t really customize that page or disable/hide some fields, unless you want to go with programmatic changes that are most likely unsupported.

The SharePoint Server Profile page

The SharePoint Server profile page (later referred to as the “Person.aspx”) is a page hosted in the ‘My Site’ site collection you’ve chosen to associate with your web application (through its association to a User Profile Service Application). It’s usually separate from your own site collection, but that’s not always the case and you could choose to host it in a site collection under your “content” web application. That’s usually what’s done on public web sites, such as the Microsoft WPC site where the Person.aspx page is hosted in the https://connect.digitalwpc.com/sites/my site collection.

In SharePoint Server, the ‘My Settings’ menu is replaced by an ‘About Me’ menu, as shown in the screenshot below:

When you click on it, SharePoint displays your Person.aspx page:

Conversely, when other people click on your name, they too are redirected to the Person.aspx page. For instance, in the screenshot below, a user named Alan Turing looks’ at Marilyn Jones’ profile:

Note that the screenshots above show the out-of-the-box Person.aspx page that SharePoint 2013 provides, but an administrator can configure which profile properties are available and which are not. It can also be highly customized, as is the case with my own profile on the WPC web site:

Now, if we look at the url of that Person.aspx when you browse a profile other than yours, here is how it will look like for an Active Directory user: http://mysite/Person.aspx?accountname=i:0%23.w|domain\user (for instance, for a user with a demo\marilynj account, the profile page could be accessed at http://mysite/Person.aspx?accountname=i:0%23.w|demo\marilynj )

SharePoint Server simply adds an accountname parameter and the value of the parameter is the SharePoint-encoded account name of the user, e.g. i:0#.w|domain\user (note that you have to replace the ‘#’ sign with %23, which is the HTML-encoded version of ‘#’ for the url to work).

For forms user, the accountname parameter value would be slightly different (i:0%23.f|[membership_prefix]|[account], for instance i:0%23.f|ext|ron for a ‘ron’ FBA user). For SAML users, the parameter would reflect how SharePoint encodes these accounts (the prefix for SAML users is seemingly random, but can actually be set to a specific value when initially registering the identity provider with SharePoint). The general format of accountname parameter value is i:0[idp_uid_claim_type].t|[idp_name]|[user_id] and if you want to know more about those cryptic account names, head over to Wictor Wilen’s excellent blog post on SharePoint claims encoding.

What you easily see is that if you want to access the SharePoint Server profile pages of those users, you would have to know their account names, which is usually far from obvious. However, as you may remember, the Account property is displayed on the SharePoint Foundation User Information page. Which begs the question…

Can I access the User Information page even on SharePoint Server sites?

The answer is: Yes! As a matter of fact, SharePoint Server itself directs all person links to that page before redirecting to the SharePoint Server profile page. You can witness it by moving your mouse over a person link on a SharePoint Server site in Internet Explorer and by looking at the link in the left hand side.

As you can see in the screenshot above, the link actually points to the userdisp.aspx page! If you try to type that link directly in a browser, you’ll see that SharePoint will automatically redirect you to the SharePoint Server profile page. However, here is a little trick: if you add a Force parameter with a random value (you can use ’1′ if you want) to that user, you will be able to force SharePoint Server to show the User Information page for that user. For instance, if we type http://extranet2013.company.net/_layouts/15/userdisp.aspx?ID=26&Force=1 (instead of just http://extranet2013.company.net/_layouts/15/userdisp.aspx?ID=26 ), the following page will show up:

Note: there are quite a few more user properties here than in a SharePoint Foundation farm, because some SharePoint Server user profile properties are marked as Replicable and will automatically be created in all User Information Lists of your SharePoint farm.

So what’s the problem, really?

If you’ve followed me so far, you have probably understood that no matter which version or edition of SharePoint you use (2007, 2010 or 2013, Foundation, Server or even Online!), almost any user that has access to a SharePoint site can browse all the User Information pages of all the users who have accessed that site at some point by simply using the following url construct [SharePointSiteUrl]/_layouts/userdisp.asxp?Force=1&ID={integer} and by trying out all the possible integer values for the ID parameter until the userdisp.aspx page fails to show up (note that this works not only at the site collection level but also at the sub-site level so [SharePointSiteUrl] can be the url of any site/sub-site in the site collection, including the site collection url)

You can easily see that this could be a serious privacy issue, because if you have a SharePoint extranet where all of your partners, suppliers, customers, etc… sign in to access some information you share with them, they can also retrieve a lot of private information (such as account names, full names and email addresses) from your internal users, as well as other partners, suppliers, customers, etc… whom they really should not know anything about!

To prove my point (if you’re willing to sign in with a Microsoft account), you’ll see that you can indeed access my User Information profile on the WPC web site at https://connect.digitalwpc.com/_layouts/15/userdisp.aspx?Force=1&ID=263 :

And I really can’t do anything about it!

In which situations does this occur and should I be concerned?

In a nutshell, this privacy issue will occur in the following situation:

• Your SharePoint extranet has a central point of access for all users, such as https://partners.company.com (where users are then dispatched to their own sub-sites or site collections)
• This main site (https://partners.company.com ) is NOT set up with anonymous access

When your SharePoint extranet is configured with these fairly common parameters:

1. You must grant your external users access to the main site, usually as Visitors (which usually has the Read permission level)
2. The User Information List of the main site (https://partners.company.com ) will contain the list of ALL users (internal and external) who have at least logged in once to your site.

To be fair and before you want to write an angry comment, this privacy issue doesn’t necessarily always occur, even in extranet scenarios. That’s why, in the “almost any user that has access to a SharePoint site…” sentence above, I inserted the ‘almost’ keyword before ‘any user’.

Indeed, some will likely tell you that this privacy loophole really only occurs when users have the “Browse User Information” permission, which is technically true. The problem is that this permission is by default enabled on all the default SharePoint permission levels (Read, Edit, Contribute, etc…), so virtually all users that inherit at least the out-of-the-box ‘Read’ permission level have that “Browse User Info” permission. You will probably think that disabling the “Browse User Info” permission is thus the solution to the issue, but suffice it to say that both from a usability standpoint and sometimes from a technical standpoint, it’s not a viable solution (take a look at the Why disabling the Browse User Information permission is not a realistic solution to SharePoint’s privacy issues blog post for more information).

So, are there any solutions to this privacy loophole?

Well, of course there are (otherwise I wouldn’t have written this blog post in the first place).

The first option is to choose to set up your main site (https://partners.company.com) with anonymous access and grant your external users no specific permission on that top-level site. The main site will just serve as a central access point but all the content will be shared on secure, non-anonymous sub-sites or site collections. Actually, we highly recommend that you site collections in conjunction with our SharePoint Site Collections Viewer Web Part available on CodePlex instead of sub-sites. Why? If you use sub-sites, it’s highly likely that at some point in time you or someone from your organization will inadvertently grant some external users access to the User Information List, if those users are assigned the “Browse User Information” permission through a SharePoint group or permission level (more information in the Why disabling the Browse User Information permission is not a realistic solution to SharePoint’s privacy issues video).

If you choose that setup, external users won’t be able to access the User Information pages on the main site, but only on the specific site collections they have access to, which should not be a problem, because these site collections should only be accessible by users they should know about.

The second option is to use dedicated host-named site collections. In that setup, there is no central User Information List that contains all the users (external and internal) and external users will only be able to access the User Information pages on each host-named site collection they have access to.

The third option is to use the same Profile Redirection technique SharePoint Server uses to redirect users from the userdisp.aspx page to the Person.aspx page (watch the video above for more information) in order to prevent some (or all) of your users from accessing private information about other users. Note that this option will require a solid knowledge of SharePoint development.

If none of those options work for you, the Professional Edition of Extradium itself implements the third option and provides an out-of-the-box solution to this privacy issue and adds a Privacy Settings menu that allows you to finely control who and which user information users can see on each site collection:

As you can see in the screenshot above, the Security Settings page is made of 4 distinct sections that correspond to the following 4 scenarios:

For each of those scenarios, you can control the following:

1. Whether you want to redirect to the Extradium custom profile page or not (if ‘No’, SharePoint will let the user access the userdisp.aspx page)

1. If you do choose to redirect to the Extradium custom profile page, which user information should be displayed and how:
   1. First Name: Yes, No, Initial
   2. Last Name: Yes, No, Initial
   3. Email: Yes, No
   4. Other Extradium custom profile properties (only when viewing Extradium users): Yes, No for each custom profile property

With the settings above, when an external user tries to view the profile of another external user, here is what she will see:

Instead of the default User Information page:

You can also configure whether site collection administrators can view both the User Information page and the Extradium profile page:

If that’s the case, site collection administrators will always first see the User Information page and will be able to access the Extradium User Profile page by clicking on a ‘See Extradium Profile’ link available in the top-left corner of the page:

by