Overview of security trimming, administrative policies, and privacy settings for social feeds in SharePoint Server 2013

SharePoint 2013

Applies to: SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

Topic Last Modified: 2016-12-16

Summary: Learn about how security trimming, administrative policies, and user privacy settings affect feeds in SharePoint Server 2013.

In SharePoint Server 2013, users can interact with others and view information in social feeds, such as the newsfeed on their personal site (also known as a “My Site”) or a site feed.

There are three factors that affect the information that users see when they load a feed:

Factors affecting displayed items in the newsfeed
  • Security trimming   Search in SharePoint Server 2013 performs security trimming, which prevents users from seeing information that they do not have access to in the system. Security trimming is discussed further in this article.

  • Administrative policies   SharePoint administrators can configure policies to customize the default values of user privacy settings and specify the settings that are available for users to configure. Administrators can configure these policies in the User Profile service application. For more information, see “Configure policies for privacy and people” in What's new in social computing in SharePoint Server 2013.

  • User privacy settings   Users can configure their personal privacy settings based on the administrative policies set in the User Profile service application. These settings enable users to specify the information that they want to share with others. Users can configure these settings from their personal profile page. For more information, see Update your profile privacy settings on Office.com.

In this article:

Security trimming is based on a user’s access to a URL. When the system generates an activity related to a user’s action, such as by following a site or by modifying a document, the activity includes the URL of the related item. Only system-generated activities are security trimmed; user-generated posts with URLs are not security trimmed. However, in either case SharePoint security ultimately determines whether a user has permission to access the item in a URL. This is no different from email, where someone can send a link to a document or site that recipients do not have access to.

SharePoint Server 2010 performed security trimming on user’s activities, and used SharePoint search to determine a user’s access to items that were posted in the Newsfeed, tagged with social tags, and rated. Whenever users accessed their SharePoint Server 2010 Newsfeed to view activities, the system would call search to return results about access and would display only items that the user had access to. For more information about security trimming in SharePoint Server 2010, see Privacy and security implications of social tagging (SharePoint Server 2010).

SharePoint Server 2013 continues to use search to perform security trimming. However, there is also a new cache, called the Security Trimming Cache, which now maintains information about user access to feed items based on search results. When users reload their feed, SharePoint Server uses cached results for a specified time. This reduces the number of requests made to search.

The Security Trimming Cache depends on the Distributed Cache service as a pre-requisite.

Each user has two lists in the user's My Site to organize feed items: the Microblog list and the Social list. The Microblog list is public, and it contains user-generated posts and reference posts to anything that the user comments on in another user’s feed. The Social list is private, and it contains system-generated activities including followed items, documents, and sites. The security trimmer reads items in the Social list to determine which items a user has access to see so that those items can be displayed in the user’s feed. even though search indexes both of these lists, it returns only the results that the requesting user has permission to see.

Administrative policies and user privacy settings also affect the items returned to a user’s feed. However, instead of using security trimming to remove this information, posts are created only for information that either the administrator or user has selected to share. For example, if a policy or privacy setting specifies not to share a user’s birthday, a post for that activity is never created in the first place. This differs from security trimming, where an activity exists in the user’s Social list but displays only for users who have access to that information.

When users submit a request to load their feed, SharePoint Server calls search to perform security trimming on all URLs from posts in the user’s private folder. However, to protect search from frequent, and often unnecessary requests for the same information, SharePoint Server caches the URLs a user can access in the Security Trimming Cache.

Cached results are affected by Time to Live (TTL) settings in the User Profile service application. These properties are available for configuration in PowerShell, and include the following:

  • SecTrimCacheMaxCacheTTLMinutes   This sets the long TTL for requests.

  • SecTrimCacheNonAuthoritativeAccessTTLMinutes   This sets the medium TTL for requests.

  • SecTrimCacheThrottledTTLMinutes   This sets the short TTL for requests.

The following diagram describes how search results are cached when users load their feed.

Figure: How search results are cached

Security trimming process with the cache

The first time that users submit a request to load their feed, SharePoint Server calls search for security trimming on any URLs to display in the feed. The security trimmer reviews the information in the user’s private folder, and saves access results in the cache.

If the user is allowed access to a URL, search saves this in the cache by writing “Access,” sets the Time to Live (TTL) to long, and then displays the item.

If search determines a user is denied access to a URL, search writes “Indeterminate Access” in the cache, sets the medium TTL, and does not display the content. There is a retry threshold that determines how many times a URL will be checked again to see whether a user has access. Once the retry threshold is reached, search writes “No Access” to the cache and sets the TTL to long. This process helps to make sure that users aren’t prevented from seeing an item in their feed that they might actually have access to.

If the user’s access is unable to be determined, such as if search is too busy to answer or results aren’t yet indexed, search saves this by writing “Throttle” to the cache, sets the short TTL, and retries the call after the TTL duration expires. This continues until search can determine whether access is granted or denied to the URL.

If a user’s permission to a URL changes from access granted to access denied within the long TTL cached period, the feed item will still appear in the user’s feed. However, the user will be unable to open the URL because SharePoint security prevents users from accessing information that they do not have permission to. After the long TTL period expires, the security trimming process repeats and the cached item will be updated to access denied so the feed item no longer appears.

After the long TTL expires, the cached results are no longer considered valid, and the process starts again the next time that a user loads the feed.

An administrator can use PowerShell to change some of the Security Trimming Cache properties on the User Profile service application. The following table lists the Security Trimming Cache properties that are available on the User Profile service application.

Table: Security Trimming Cache properties

Property Description Default value


Long TTL. This is the maximum number of minutes to maintain an item in the cache. The default is 1440 minutes (24 hours).



Medium TTL. If access is unable to be determined, such as when search is too busy to respond, medium TTL is set and the call is retried after this period elapses until the retry threshold is reached.



Short TTL. If access is denied to a URL, short TTL is set so that any changes to the URL permissions are caught if a user reloads the feed.



Retry count threshold. This is the maximum number of times that the cache can call search to ask about access before setting Access Denied and setting long TTL.



The maximum number of per-user items that can be cached.



Determines whether the cache is enabled or disabled.

True (1)


Determines the maximum number of URLs that can be security trimmed at one time.


An administrator can use PowerShell cmdlets to update these parameters on the User Profile Service application. For example, to set the maximum cache TTL, use the following cmdlet to update the SecTrimCacheMaxCacheTTLMinutes to 1440:

$upa = Get-SPServiceApplication | where {$_.TypeName -Like "User Profile Service Application"}
$upa.SecTrimCacheMaxCacheTTLMinutes = 1440

To update other cache settings, replace the SecTrimCacheMaxCacheTTLMinutes parameter and value with the parameter that you want to change.