SharePoint 2010 Anonymous Search Results
I recently ran into what should have been a well-documented and easily corrected search issue in SharePoint (2010 but the same could be said for 2007). The basic scenario was a public-facing publishing site with an extended zone for anonymous users (the default zone was configured for NTLM). Search worked find for authenticated users but wouldn’t return any results for anonymous users. At first, I thought that it might be related to the search results page inheritance issues, which plenty of people have mentioned (a quick Bing of the issues returns a bunch of results – see here, here and here. I even touched on this myself for WSS way back in 2007 here). Nope, that wasn’t it – the user was simply dropping the search web parts onto a standard web part page so the search results page wasn’t even involved. Next, I figured it had to be a configuration error on the site, so I checked to make sure ‘Indexing ASPX Page Content’ option was enabled (as shown here). That wasn’t it either. Perhaps it was an issue with permissions? Nay – all documents were available to anonymous users and they were able to retrieve them directly from the source lists.
After Binging around for a few hours and trying a dozen different possibilities, including all sorts of content source and scope configurations, we finally threw in the towel and opened an incident with Premier support. While discussing the issue with our case manager, we tried, almost as an afterthought, enabling anonymous in the Default zone. Voila! After a full crawl search results starting showing up for anonymous users. I seem to remember reading about this somewhere but discarded it as not being relevant; after all, the whole purpose of extending the web app into a new zone is to avoid having to allow anonymous access in the default zone. But that’s what finally did the trick.
So what gives? To be honest, I really don’t know. A content source using a restricted-privilege crawl account configured to index just the anonymous zone should, in theory, return results for visitors in that zone but it doesn’t. The only way to make it work is to perform the crawl against the default zone with anonymous enabled. From a security perspective, this makes me very uneasy – I shouldn’t have to open my zone to anonymous users who don’t belong there. As a practical matter, the risk wasn’t that great – only internal users could get to the default zone from inside the firewall and even if an anonymous user somehow slipped by, site and list permissions would block them from accessing any secured content. But it still doesn’t seem right to me – it should work with the proper zone configuration. It may be a bug or they may be some reason why search works that way (the case is still open so if we find the answer I’ll post an update). In any event, that seems to be the accepted workaround for the moment.
So for all those who posted to the forums with a similar issue, try enabling anonymous in your default zone and executing a full crawl. And don’t blame me if the solution keeps you up at night – I’m just a messenger in cowboy boots J
This worked for me. After enabling anonymous access in the default zone and then performing a full crawl search results appeared for anonymous visitors. Thanks for the help this has kept me busy searching the net for a few days.
Worked like a champ for us as well. Enable anonymous on the default zone and then perform a full crawl. You saved us on this one! Thank you for your post!
Hi I tried this approach and it didn’t work for me. Is there anything else that might need to be set?
Like you, I get the jitters enabling anon on the Default Zone, so under Anonymous Policy for the web application, I set the Default Zone to Deny Write Access for anonymous.
So did Premier support tell you? Did they confirm it as a bug? Is that by design (or even a feature? 😉 )
Finally a solution to this, cheers Eric and the above commenter for the tip on locking it down with the policy.
We’re running into the same issue except we’re using NT authentication for the authoring zone of the application. Turning on anonymous for this zone dampens the user editing experience (when they go to the site, they’re not authenticated). Did premier support ever resolve this issue?
Further testing reveals that anonymous access is required to be enabled on ALL zones – not just the default. This negates a possible workaround of having 3 zones: 1 for authoring without anonymous, 1 for crawling (the default zone) with anonymous, and a public-facing anonymous zone.
Yuck.
This was a known issue with Sharepoint 2010 & has been fixed in April 2012 CU KB 2598304
Rajan