Audience Targeting on SharePoint Sites with Anonymous Access

You have a site that is anonymous, but you want to restrict the display of certain content to authenticated users after they sign-in.  This information is a walkthrough of several ways, permissions and audiences, that this can be accomplished.

 Anonymous Access

• Decision: Which sites does the client want to have anonymous as an option?
• Anonymous is first enabled at the web application level, so this can be a reason to have multiple web applications (and URLs) for different main sites where some need anonymous and others do not.
• Turning on anonymous at the web application does not actually change any permissions or open up anonymous on site collections.  It simply means you allow it, to give anonymous permissions to a site collection, first navigate to site permissions at the root site collection level.  Here you can choose to give access to the entire site (essentially inherit from the root all the way down) or just lists and libraries, so only part of the root site but set explicitly.
• I do want to reinforce that it is a very important task to whiteboard and brainstorm where anonymous access will exist and to document this.
• Different URLs for different access
• Some organizations extend the web application, thus creating a new IIS site to host the same content.
• Original web application might be https://intranet.domain.org, this would be claims with Windows Authentication.  Anonymous is not enabled here.
• They extend this web application into a new zone (internet) and give this site anonymous access.  https://public.domain.org.  For simplicity they would probably place all site collections in a single web application.  The default zone is only routable via local domain access or VPN.  The public internet zone is routed worldwide, but authenticated users can still click sign-in to be authenticated.
• I personally think this scenario can be confusing for users.  Different URLs for the same content always causes confusion.  If a user emails or posts the wrong link then an anonymous user could be denied access if given the internal site's URL.
• The only benefit in this scenario is that for internal authenticated users who browse to the internal site, they can be automatically signed in.  Otherwise, if only one zone exists and it is enabled for anonymous access, users will have to remember to click sign-in before they can see authenticated content or make changes.  (I have worked in this scenario before, it caused way more confusion than you might think, Help Desk will need to constantly ask users if they signed-in when troubleshooting behavior).
• Bottom-Line:  Anonymous causes problems when combined with an authenticated portion of the site.  There are pros and cons. Then you must make a decision, and document.  If you do not document your help desk and your team could forget which areas are anonymous and which are authenticated.
• Inheritance
• Anonymous access can be broken.
• Example: allow anonymous permissions on a site collection to the entire site.
• Navigate to a document library.
• Click on permissions, by default this should be inheriting the parent permissions (root site).
• If we break inheritance, we can set exactly what anonymous users can access, by default it is usually read.
• Remove read and now we have an area that only authenticated users can see.  Any content in this library will now be hidden if shown in a web part on any dashboard page and any navigation links will be security trimmed; until the user clicks sign-in and authenticates.
• 
• Audiences
• Audiences are created in the User Profile Service Application
• To create one:

• Navigate to User Profile Service in Central Administration.
• Under the People section, click on Manage Audiences.
• Click New Audience.
• Assign a name, I named mine "Auth-Only".
• Choose an owner, this should be an administrator of the system.
• I left Satisfy all the rules, as I will only have one rule.
• For Operand I left User.
• For Operator, I select Member Of
• For Value, I selected an Active Directory Security Group that contains the users I am targeting with this rule, I created a test account with all users.
• Next you will be presented with the summary of the audience:
• Click on Compile Audience to ensure the SharePoint system has access to it.
• Audiences in WebParts
• Now that User profile Service is compiling audiences for the system, if we edit a web part, we now see Target Audiences under the Advanced section.  (Without User Profiles Service, this would have been blank).
• 
• I can add my newly compiled audience for Authenticated only users:
• 
• Example:  I have two web parts on a default.aspx page (Content Editor).  The entire site is set to anonymous: read.  One of these web parts is untouched.  The second I have named Restricted Content and I applied the new Audience created above Auth-Only to it.
• Opening up the site anonymously, I only see the anonymous content:
• 
• If I sign-in, I am now authenticated, but the user account I have is not part of the compiled audience, so nothing changes:
• 
•  If I sign-in with a member of the audience, I am presented with the Restricted Content:
• 
• To view an Audience Membership:
• Navigate to User Profile Service in Central Administration.
• Under the People section, click on Manage Audiences.
• Click on the drop-down menu for the audience, and select View Membership.
• 
• In my case I only had one user in the AD Security Group.