This post was most recently updated on April 28th, 2019.Reading Time: 6 minutes.
Ah, everyone’s favorite, classic topic! Debugging SharePoint On-Premises configuration issues is the best thing since sliced bread, right? This post is about allowing/enabling Anonymous Access to a site collection – a simple configuration, that “simply works” like once every ten times you try it.
This article describes how to enable anonymous access for SharePoint Server 2010, 2013, 2016 and 2019 – the procedure is pretty much the same!
A lot of different ways to hit your head on this one. In any case, your on-premises SharePoint farm doesn’t allow your anonymous users (that’s users that haven’t logged in) to access a site where you are trying to allow it.
Most typically, this issue manifests itself by your users getting login prompts on your SharePoint 2013, SharePoint 2016 or SharePoint 2019 sites, even though you’ve enabled anonymous access already. They could also just encounter a plain 401 error when accessing the site, or they might be missing some of the content or styles, resulting in a partially broken site.
So, a number of symptoms. But what’s causing this?
Usually incorrect configuration or non-published resources. There’s a number of steps you could be missing, or someone might’ve messed up… But it could just be a permissions issue, or leftovers from a recent deployment.
So in short, multiple reasons can cause this and I’ll describe some of them below with the solutions.
A lot of things to check here – so let’s go through all of the most typical issues one by one!
Enabling anonymous access on web application level
This is basically the first thing you should verify. Have you enabled Anonymous Access for the web application you’re configuring? See below, on how to do that!
- Go to SharePoint Central Administration
- Manage web applications
- Edit authentication providers
- Choose to enable Anonymous Access. See below for a screen shot!
Do you have an anonymous user policy that stops users from accessing the content?
You can check and modify this in the web application settings, too. Just check out the policies you’ve set on web application level in Central Administration (see screenshot below).
- Go to SharePoint Central Administration
- Manage web applications
- Select “Anonymous Policy” in the “Policy”-group in the ribbon
- Enable access in the dialog
This link describes the steps for changing the user policy in some more detail – feel free to check it out, if my description is too vague!
Do you have anonymous access configured at site permissions?
You’ll also need to enable the Anonymous Access on the actual site level. The easiest way to do that is with PowerShell. I’ve written about this before, so you could check out that post – see below:
Is Anonymous Access enabled at IIS?
Ah – the classic. IIS might still be blocking Anonymous Access, even if SharePoint would accept it. To fix this, take the following steps
How to enable Anonymous Access in IIS?
- Open IIS Manager
- Select your web site (it’s either by the same name as your web application or extended application)
- Open the Authentication settings
- Make sure “Anonymous Access” is enabled.
Is some of the content unpublished?
This is the next thing to check. There are multiple files that can cause authentication prompts when unpublished, for example the following ones:
- The front page of the site colletion (or any other page that you’re trying to access) published?
- Publishing images or the ones used by the branding of the site published?
- CSS-files, master and publishing page layouts (check out the design galleries)
Figuring out which one is always an issue – if none of these stand out, you could also simply open your ULS logs and go through them. Look for any 401 errors in that particular site collection, and you should eventually find any resources that anonymous users are not allowed to access in that web application – if there are any!
Alternatively, by capturing your traffic with a tool such as Fiddler, you can analyze which requests result in 401 errors – but that’s a bit of a large topic to be covered in this post!
Are you trying to let anonymous users access an application page that’s not meant to be accessed by anonymous users?
Okay – this is about your own, custom application pages. It’s really easy to actually make them inherit the wrong base class. If you’re trying to access a custom
I haven’t really found a way to enable your anonymous users to access an application page like this. Instead, use “Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase” – that’ll work for anonymous users!
See this for more info: https://social.msdn.microsoft.com/Forums/office/en-US/f8b567d4-1cd0-46c1-ac47-4498af88d798/how-to-provide-anonymous-access-to-a-custom-aspx-page-in-layouts-folder?forum=sharepointdevelopmentlegacy
Check that the location is allowed at web.config
Okay, let’s be honest about this – at this point, I’m probably already pretty desperate, but web.config is still definitely worth checking. You’d need to have something like this, for example, to allow access to a certain application page:
(Image above not visible? See an XML example below):
(Sorry about the total trash formatting above – WordPress’s new fancy editor, Gutenberg, broke my <pre>-tags and refuses to save them to database for now. Clearly well tested update. </rant>)
Okay – that’s all I’ve found so far!
None of these help? Drop a comment below, let’s figure it out :)
Note: This post was written slowly over 3 years after having to fix very similar issues in a couple of different environments. There’s a chance I’ve missed some changes introduced in some obscure CUs or something. If I did, let me know!
Are you looking for instructions on how to enable anonymous access for SharePoint Online?
Well – I’m sorry to be the one to break it to you, but you can’t enable the actual anonymous access for SharePoint Online sites anymore, as Microsoft has retired public sites. You can, however, enable external sharing for the whole site, or enable anonymous access to any particular files or list items by generating anonymous access links – not whole sites, though.
Instead, you can invite external users with pretty much any email addresses, and deploy your assets to a public CDN – and you can enable pretty much a full experience for them (the only thing you’re missing is access to SharePoint People Search and features powered by it). But this, is a topic for another article!
Latest posts by Antti K. Koskela (see all)
- Azure Functions host quits with “The system cannot find the file specified” - January 22, 2020
- How to extract more information out of your Azure Functions host failing silently? - January 22, 2020
- WordPress media uploads failing after year/month change? Easy fix :) - January 14, 2020