I just recently had a bout with my MOSS search service. After a couple faithful years of service our SSP got a tick and so we decided the best thing to do was rebuild it (pretty easy really, only a few BDC apps to port, etc...) Unfortunately once everything was done we could not get the search service to crawl the "All Local Sites" content source. Here were the symptoms:
- Crawler Log indicated "Access Denied" when it tried to crawl the root of our intranet or mysites.
- Crawling of the sps:// people content source was fine.
- Content Access account had the proper policy (Read All), and actually even had rights to the site. You could log in as that user and browse all around the site from another computer.
- When a crawl was started (and thus ended very quickly with the one access denied log event) you could no longer open up the content source edit page in search administration (returned a .net "object not found" error).
- If you cleared all indexed content, then you could get back into the content source edit page, so long as you didn't actually attempt a crawl.
- Nothing else really significant in the windows logs (except a failure audit).
- Trying to navigate to the intranet root from the server with the content access account returned a 403 error <--- WHOA... BIG RED FLAG / HINT HERE.
So after searching around (sorry I'd link the blogs here, but the search was quite far and wide and I didn't properly keep track) I discovered that in Windows Server 2003 SP1 they introduced this new feature called "Loopback Check Security Feature". Essentially this means that any attempt by that machine to access an FQDN from the console (or apparently from services running on the box) will fail if it resolves back to itself. I presume the little scriptkiddie hack goes something like this: 1) trick an admin into installing your worm, 2) modify the hosts file or proxy settings so that some official site, say Paypal or your HR payrole system for example, gets redirected back to a local hacked up version of the site, 3) continue with man-in-middle attack, except without the middle man....
Anyway, you may be wonder why FQDN's were involved here since SharePoint by default pops in http://servername as the default "All Local Sites" content source. Well apparently we had changed the default access mapping for these sites a while back (typical) to their FQDN's. When we went to recreate the new SSP it just picked these up and used them.
SO-- the solution can be found at this KB article. Rather than turning off this loopback check (method 2) even though the scenario that it protects against seems pretty far fetched to me, I decided to use method 1, which worked great and didn't require a server reboot :) I've reproduced it below:
Method 1: Specify host names
Note We recommend that you use this method.
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
- Right-click MSV1_0, point to New, and then click Multi-String Value.
- Type BackConnectionHostNames, and then press ENTER.
- Right-click BackConnectionHostNames, and then click Modify.
- In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
- Quit Registry Editor, and then restart the IISAdmin service.
And that dear friends concludes this edition of "why is search not working...today (there is hope!)"
I just recently had a bout with my MOSS search service. After a couple faithful years of service our SSP got a tick and so we decided th...