I was trying to figure out what to title this because the issue seems to effect a couple things.  If you've seen the following:

• Typing the [[ brackets in a wiki page result in a List Not Found message
• Navigating to a REST service (like http://sitename/_vti_bin/ListData.svc) results in an error that states Security settings for this service require Windows Authentication but it is not enabled for the IIS application that hosts this service

I started going down the path of our kerberos setup here, cause that's what we're using, and anything related to any sort of security error I look there first.  All the SPNs, account delegations and such were set up correctly.  What I did find tho' is that the Authentication Providers (inside IIS Manager) for the web application in question only had Negotiate:Kerberos in the Enabled Providers list.  This is available as a new feature in Windows Server 2008 R2.  Note that you can choose from Negotiate:Kerberos, Negotiate, or NTLM as enabled providers.  Here, we only wanted Kerberos without the fallback, so we just enabled Negotiate:Kerberos.

After doing some analysis, it looks like when you also select NTLM as an Enabled Provider, the calls to the REST services work.  Running a tool like Fiddler and examing the output right after typing the '[[' shows the NTLM traffic for that specific operation.  Regular browsing of the pages were showing Kerberos.

So, as it looks, in order for REST calls to work, NTLM must be one of the Enabled Providers in the Authentication properties of the web application.  I'm doing some additional searching to try and find some "official" supporting documentation, but as it stands, in order for those errors above to go away, adding NTLM did the trick.

Hopefully this one helps out some folks seeing this as an issue.

- M

In my Googling (we all Google to find stuff that we can use, instead of creating from scratch, right?) to find some help with an issue I was having when trying to loop through the UserProfileManager, I came across a really awesome post of Victor Vogelpel's blog that cites some code that Julien Lepine wrote to do some impersonation of the Web Application's ID.  What this code does is basically create an Identity class that runs in the context of the Web Application's ID.  Now, how does this differ with SPSecurity.RunWithElevatedPrivileges?  Well, RunWithElevatedPrivileges is kinda like a "black box" implementation in the context of the built-in "SharePoint\System" identity.  If you utilize the Identity class described above, and you give your Web Application ID the relevant access (in this case, the Manage User Profiles permission in the SSP), you're able to directly know who's doing what, where.  Better than just relying on a "black box" kinda implementation, no?

Check out the code from Victor's article.  It's a little old, but still very relevant.  Cool stuff.

Of special note: On the virtual I was working on at the time I couldn't get anything to work for the above example.  Turns out the issue was related to a fix that was applied when installing the December CU.  Remember to keep your virtual/development environments updated.

- M