Draft Item Security & Search Results Security Trimming

March 17 2010 11 comments

The content access account of MOSS search should have a read-only access to content. In some cases that is not enough – there is a list level setting to limit the visibility of draft versions of list items to only the ones with edit permissions. This means that the content access account cannot index the draft versions. So if you have a document with the latest version being 0.x it is totally invisible in search. If you have a document with the latest version being 1.x you will only see the version 1.0 in search results.

The first reaction to overcome this would be to ignore the best practice and grant edit permissions to content access accounts. This allows indexer to crawl the latest draft version of the document. In SharePoint, the so-called “security trimmer” takes care of cleaning the search results and showing the user only the search results he is allowed to see. Somehow the draft item security setting is ignored by the security trimmer – apparently because it is a library level setting instead of being in the document access control list.  This means that the latest draft version of the document will be indexed and shown in the search results for the user with only read permissions. But when user clicks the search result link of the document in question, he/she either gets a “access denied” error (if there are no major versions published) or the latest major version.

To sum this up, there seems to be only bad alternatives when using draft item security to require edit permissions to view drafts. Either not have draft versions indexed at all, or to elevate content access account with edit permissions, have the draft versions indexed but get problems with the search results security trimming.

Popularity: 1% [?]

11 comments to “Draft Item Security & Search Results Security Trimming”

  1. [...] SharePoint Blog Post From SharePoint Security – Google Blog Search: In SharePoint , the so-called “ security trimmer” takes care of cleaning the search results [...]

  2. [...] Draft Item Security & Search Results Security Trimming (SharePoint Blues)The content access account of MOSS search should have a read-only access to content. In some cases that is not enough – there is a list level setting to limit the visibility of draft versions of list items to only the ones with edit permissions. This means that the content access account cannot index the draft versions. So if you have a document with the latest version being 0.x it is totally invisible in search. If you have a document with the latest version being 1.x you will only see the version 1.0 in search results. [...]

  3. Arttu Arstila says:

    Microsoft has made a related KB article: http://support.microsoft.com/kb/2304855 . Apparently this refers to content access account having the default read permissions.

  4. Martin says:

    I *don’t* want viewers to be able to see draft versions in their search results, but whenever the latest version of the document is a draft version *no* version of the document appears in the search results (even though there’s been a previous published version).

    The document library is configured for major and minor versioning, require approval for publishing, require checkout to edit.

    Most frustating! This is on the IW demo vhd.
    Martin

  5. Betty says:

    Martin, have you gotten a workaround to your problem? We are encountering the exact problem.

    Thanks so much.

  6. Gransom says:

    Martin , Betty

    I found a working solution at :

    http://extreme-sharepoint.com/2011/10/04/sharepoint-search-isecuritytrimmer/

    Hope it helps

    Thanks

  7. Martin says:

    I’m revisiting this at present.
    I’m not sure what config I used before. Here’s the behaviour I currently get:
    Draft Item Security is set to “Only users who can edit items”
    Content Crawler has Full Read user policy for the web app.

    Once the content is crawled, and I’m searching (as a viewer), I get the version 1.1 of a doc in the results page, but clicking on it gives me the 1.0 version.

    If I have a doc at version 1, crawl it, (correct version gets found), then update it, crawled version (v1) is shown in results, but updated version shown when I click it (if I’m an editor). If I’m not an editor, I only see the published version

    Now another crawl happens (it’s already in index, but there’s a version 1.1 in the library now). Now when I search for this doc, the published version is shown in the search results, and when clicking through, I see the published version if I’m not an editor, and I see the new draft if I am an editor.

    It seems to me that the state of the documents at crawl time is key. In addition, in order for the search results to make sense, it’s important that the documents are crawled in each state they go through. So it’s no good if the first time a doc is crawled, it’s at v1.1. It needs to have been crawled at v1.0.

    It looks like the crawled state of the doc is used for showing in the search results, but the actual document is shown when you click through – and this maybe the latest draft if you are an editor.

    What’s wierd is that the crawled state can show the draft version even though the crawler isn’t supposed to see that version. I update the doc again (to version 1.3), this time the non editor is the first to search it. They see the 1.2 version in the search results. Clicking through, they still see v1.0.
    Editor sees 1.3. So before we crawl the lastest version, we have a more unusual situation where the version shown in the search results can be 1.2, editors click through to see 1.3 and non editors click through to see 1.0. Nice!

    It would appear the config of the “Draft Item Security” does not effect the search crawler.
    I’ve looked at the isecuritytrimmer a little, and I’m dubious about it’s value because of when it’s applied (at query time), and what it does (show/not show the search result). If the search result contains draft versions when the crawler should be able to see draft items, the security trimmer isn’t going to help.

    Martin

    Martin

  8. [...] to some blog posts like here and here  , this happens [...]

Leave a Reply