Anonymous and 403 forbidden – Search not working
Hello, and welcome to my blog! Since this is my first post, I’ll let you know that you can expect to see all kinds of posts here, from very technical like this first one, to governance, to user experience and so on. I’m happy to hear from you, especially if you see any errors or better ways to do things than what I post here. As most SharePoint people know, learning SharePoint is an ongoing process. Great product, but very complex…anyway, here we go!
We were installing SharePoint 2010 (SP1, CU June 11) Web Standard Edition for a public site. The environment was to have two WFE’s with one of the servers also being the app server. We had created the environment in TEST, and had been developing the branding solution with no problems.
When we created the production system, however, we immediately were presented with 403 forbidden whenever we tried to access the anonymous URL. When we attempted to access the authenticated site, we were unable to access the site collection at all, even using the installation Admin ID, which had a policy of Full Control set on it. We eventually would get a 401 error after hitting enter several times. After trying many different things to get around this, we decided that we would try deleting the web apps and recreate them.
From previous experience, we had created the Web Apps by first creating them as Anonymous and then extending the web app to Claims based Authentication. The reason it was done this way rather than creating the site as a claims based Authentication and then extending to Anonymous is that we had tried this before with another client and found that it if it was done that way, we could not get Search to work. Search would not produce results no matter what we tried to do.
Anyway, back to the 403 forbidden. We were able to recreate the Web Apps, and mysteriously, things worked this time! We did have a few things we had to work around. First, the Sun proxy server that was being used would not allow authentication on the Anonymous URL. We got around this by creating a Host entry in a client system that pointed directly to the server. We then were able to authenticate and turn Anonymous on at the site collection level. We also got into the authenticated site and were able to add Site Collection admins, and poke around a little. All seemed well! We went home for the weekend thinking our problems were over.
Come Monday, things went downhill quickly. We tried to create the remaining services (web analytics, State service, and search), and were having problems getting them to work. Web Analytics was failing with an "Access Denied" error. We then thought to check the anonymous URLs to the sites, and found that our 403 and 401 problem had returned!
After trying many things to isolate the problem, including removing MacAfee from the system, which did not have the SharePoint directory excluded below WebServer Extensions (see http://support.microsoft.com/kb/952167)
Here are the fixes that we implemented, thanks to our crack Premier Support engineer. Do I know that each of these steps is absolutely necessary? No, I don’t, we’re still trying to recreate the problem and the solution in our TEST environment. But here’s what we did to get it going:
- Right out of the gate, we were using the OOB search pages. This meant that the search results page had been using something like the following: /_layouts/OSSSearchresults.aspx. The light bulb went on…anonymous users probably can’t access a page that has _layouts in it. Thus, it would request us to authenticate whenever we attempted to access the search results page (never mind that our proxy server wouldn’t pass our authentication even if we tried). So…
- We created a search center in each of the site collections, and went to Site Actions/Site Settings/Search Settings, and insured that the top line had our new site in it. Depending on your requirements, you may only have to create one root site Search Center, but our requirements were to have one for each collection in this public site (different branding and navigation in each site collection).
- Still no results, but no more authentication pop-ups in anonymous!!
- Next, the engineer gave us the following SQL Query to run from SQL Management Studio:
SELECT [MSSCrawlURL].DocID, [MSSCrawlURL].DisplayURL, [MSSCrawlURL].Title, MSSDocSdids.Sdid
FROM [Search_Service_wwwcsu_CrawlStoreDB_b7ca04af96454b1ead4d1ab2dfda1429].[dbo].[MSSCrawlURL] with (NOLOCK)
INNER JOIN [Search_Service_wwwcsu_PropertyStoreDB_f5ab5f68438a4a898f06c956156d77de].[dbo].[MSSDocSdids] with (NOLOCK)
ON [MSSCrawlUrl].DocID = [MSSDocSdids].DocId
where MSSCrawlURL.DisplayURL like ‘http://wwwtemp.yoursite.com/residential/%’
or MSSCrawlURL.DisplayURL like ‘http://wwwtemp.yoursite.com/business/%’
or MSSCrawlURL.DisplayURL like ‘http://wwwtemp.yoursite.org/%’
order by Title
The query will show you the URLs which were crawled by the search service crawler. Below is a normal Anonymous result page. Notice the zeros to the right.
- Interestingly, the final column, Sdid, is a column which shows you the "security mask" for the items that are in your results. Meaning, if the item has a "0", then the item would be shown to Anonymous users. If it has a 1 or above (we only saw 0s, 1s and 2s as we went through this process), the item will be security trimmed for anonymous users, and they won’t see these items. Makes sense, you wouldn’t want public users seeing your _layouts pages, "forms" hidden folders, nor any items which may have been given unique permissions (we had none). Our query showed NO 0’s in the Sdid column at all! Why this problem exists, I’m not sure, but it appears to me that it’s showing values in this field that are created on the authenticated side of things, and aren’t changed when we are in anonymous. At any rate, when the web apps are reversed and we do anonymous and then extend to authenticated, the problem with search does not exist.
- We changed Site Actions/Site Settings/Search Settings to reflect our new Search Center in the "Enable Custom Scopes by connecting this site collection with the following Search Center.
- We eventually changed the dropdown in Site Actions/Site Settings/Search Settings called "Specify the dropdown mode for Search Boxes" from "Do not show scopes dropdown, and default to target results page" to "Do not show scopes dropdown, and default to target results page".
- We performed the following PowerShell Commands:
$lockdown = get-spfeature viewformpageslockdown
disable-spfeature $lockdown -url http://sitecollectionURL
The first line sets the variable, the second disables the feature
- I don’t know exactly what this command does, and we have a request with Microsoft to see if we have made the site more vulnerable than it was before setting this feature to disabled
- I expected to see 0s after setting this, but no 🙂 . Apparently turning this bits off just makes it ignore everything.
- Left the "Local SharePoint Sites" Search Content Source with just the authenticated URLs in the section called "Type start addresses below (one per line):". We had one for the main site and one for the blog site in this case.
- Created a new content source with the following
- A unique name for the content source (we called ours Anonymous)
- In content Source Type select SharePoint Sites
- Type in the Site Collection URLs of all of your site collections, using the Anonymous URLs
- VERY IMPORTANT – in Crawl Settings, select "Only crawl the Site Collection of each start address". This is not the default, so make sure you change it.
- After that you can take the defaults and start crawls on both Search Content Sources
- Added Server Name Mappings into the Search service
- For each domain, enter the authenticated URL in the "Address in index" field, and the anonymous URL in the "Address in search results" field
As I mentioned, we had a test system that had been built as an Anonymous site first, then extended to authenticated. The prod system didn’t work, as it got 403 in anonymous and 401 in authenticated. Here are the differences that we are aware of between the two installs:
- TEST web apps were built in another network security zone, and then moved over to the same tier as PROD
- TEST web apps were built before the Proxy was added
- TEST web apps were built before the second server was added