Saturday, January 12, 2008

Anonymously Searching User Profiles in MOSS

I had a requirement the other day to enable anonymous access on an internal portal and allow users to search across the user profile database - to create what was essentially a corporate directory.

The anonymous "core requirement" was to ensure users didn't have to log in when trying to look up their colleagues (they are using the dreaded Novell e-Directory which does not play nicely with SharePoint). Anyway this time the issue wasn't importing the e-Directory accounts but rather a 401 - Unauthorized error that kept appearing when trying to view the people results.

I tried the following things:

  • I enabled Anonymous access first on the Search Centre lists and libraries and eventually on the entire site collection
  • I added IUSR as a member of Intranet Viewers and made sure that in the policy permissions for anonymous users they had a limited read policy setup
  • I tried to add IUSR_ to the SSP Settings - "Process Accounts with access to this SSP"
  • I manually turned on anonymous access to some of the individual mysite site collections that I was trying to view
  • I modified the My Site settings in the SSP to allow IUSR to be part of the default readers group and for any existing My Sites. Then I had to go to that My Sites collection and give READ permissions directly to the IUSR account
  • I created a custom permission level called "Anonymous View" in the site collection, added View Application Pages, View Items, View Pages, and Open permissions. Then I added the anonymous view permission in the "Intranet Visitors" group to ensure they could get these extra permissions.

Nothing worked. If I tried getting results back directly from the People Search page, the 401 error would instantly appear. For some reason though I could perform a user profile search if I used the regular All Items search with the People scope. However when clicking on the results the 401 error would subsequently appear.

The conclusion: anonymously accessing user profile data does not seem to be supported out of the box. I suppose some custom code might fix this but my goal was to adhere to the vanilla SharePoint as much as possible.

This issue seems to be by design - the user profile data includes colleague information, social relevance algorithms, and organizational hierarchies. None of that information would pertain to the anonymous user account. Additionally, the actual user profile data may be considered sensitive.

Has anyone else come across this limitation, and if so how did you resolve it please?

5 comments:

  1. I find myself in a similar situation. The client was promised audience targeting for anonymous users and I am unsure if it is possible in SharePoint.

    ReplyDelete
  2. Hi Nick.. Did you ever resolve this problem? I'm facing this exact issue right now.

    Thanks!

    ReplyDelete
  3. I haven't tried this yet, but we just installed the Quilogy Media Platform to our SharePoint environment. I asked the guy at Quilogy about this very same thing and he said that if your primary service accounts (in Central Admin) have the correct permissions, you should be able to set up people search for anonymous access.

    ReplyDelete
  4. Hi Anonymous - we tried two different approaches:
    1) creating a completely new user profile console which didn't have the org hierarchies on it, and
    2) removing the org hierarchy on the original profile page so the error wouldn't be produced.

    After weighing up these approaches we finally decided to go with an out of the box Active Directory authenticated approach and use the original user profile page. This involved loading the user authentication information from Novell / ADAM straight into AD so nobody was really "anonymous" anymore.

    ReplyDelete
  5. Hi Rekrapt, thanks for posting! The people search works fine anonymously, however the particular error occured when trying to view the actual profile results for a particular user.

    It seemed to be caused by the Org Hierarchy component that is included in the out-of-the-box SharePoint user profile page. Not being logged in caused this particular error, probably when SharePoint tried to figure out the org hierarchy for the anonymous user.

    ReplyDelete

Note: only a member of this blog may post a comment.