TechEd 2010: SharePoint Security – Permissions, Identities & Objects…Including a ‘Gotcha’ that Breaks Security Trimming
<a href="http://communITy.bamboosolutions.com/cfs-file.ashx/__key/CommunITyServer.Blogs.Components.WeblogFiles/sharepoint-2010/TE_5F00_DanHolme.jpg”><img src="http://communITy.bamboosolutions.com/resized-image.ashx/__size/700×0/__key/CommunITyServer.Blogs.Components.WeblogFiles/sharepoint-2010/TE_5F00_DanHolme.jpg” alt=”Dan Holme presents at TechEd 2010″ border=”0″ style=”border:0;float:left;margin-top:2px;margin-bottom:2px;margin-left:6px;margin-right:6px;” />
This afternoon at TechEd, I attended the SharePoint SecurITy: permissions, IdentITies and Objects session presented by Dan Holme. Dan is Director of Training and Consulting at Intelliem but, as he explained, his "job really is to help the [SharePoint] communITy." In his session today, Dan set out to dive into the SharePoint 2010 securITy model, "looking at the object model securITy in SharePoint."
Noting that authentication is done at the Web application level, Dan began his demo-centric session wITh the Web Application Management page in SharePoint, explaining that there are two claim types: Classic mode and Claims-based authentication. You can choose one or the other, but Dan stressed that the entire industry is moving toward claims-based authentication; as a consequence, Classic mode only supports Windows authentication.
After reviewing the Group-level permissions in SharePoint, Dan moved on to the list- and library-level permissions, mentioning that options are for permissions to eITher be inherITed from the parent sITe or be set uniquely at the list/library level. In order to set unique permissions, however, you need to break inherITance of necessITy. One nice new feature in 2010 is that when inherITance has been broken anywhere in a given sITe, there's a band at the top of the sITe that alerts you to that fact (and which also allows you to re-inherIT permissions). Dan mentioned that folder- and ITem-level permissions function just as do list- and library-level permissions.
One gotcha that Dan demonstrated is that "SharePoint is securITy trimmed, which is nice … except there's a place that IT doesn't apply." Dan explained that defaults take care of this exception but that since IT's possible to reintroduce the issue wITh unique permissions, you should be aware of IT. The issue is that if a library is added to a Web Part page, IT will show up in a user search of the sITe, even if a given user doesn't have permission to access that particular library. The user won't be able to see the contents of the library, but if they can see that IT's there at all, you could have a problem. Dan said that "Once you break inherITance on anything in the sITe, this [potential issue] kicks in." There is a setting that you can apply to circumvent the issue though, and IT's a radio button selection that says, "Do not index Web Parts if this sITe contains fine-grained permissions."
Since permission levels are defined at the sITe collection level, one problem that can occur is that if a user checks out a document then leaves on vacation wITh that object checked out, no one is able to access IT. To address this, Dan recommends creating a custom permission level via the new SharePoint 2010 feature Add a permission level (in SITe Settings). You can create a permission level called, say, "Override Check-Out," create a group to assign the permission to, and define the securable object you're given that permission to, and you'll be all set.
In addressing a question from the audience on the subject of using SharePoint groups or Active Directory (AD) groups, Dan said that "You can create a group [in SharePoint] that allows group membership management," which you can't do in AD, but Dan pointed out that AD does have the advantage of giving you "centralized management securITy." Dan recommends using AD for broadly accessed sITes and SharePoint for lower-level collaborative sITes.
Regarding administrative groups, Dan pointed out that since Windows admins can perform all of the functions of a farm admin and then some, you should "Be very careful about who's a [Windows] administrator."
Dan explained that anonymous access is "disabled by default for securITy reasons," but that if necessary IT can be enabled via Central Admin, then authorizing IT at the sITe level through SITe Settings.
Regarding Web application securITy, Dan said that though you need farm-level access in order to do so, securITy policies can be set up directly wIThin SharePoint. These farm-level admin rights include the abilITy to "Create new permission policy levels" wITh granular permissions.
Dan closed his session by discussing audIT settings and records management. Regarding audIT settings (available via SITe Settings), he said that you're able to specify which types of changes you wish to be tracked in SharePoint 2010. Dan also explained that the audIT log reports show you what's happened, including what was viewed and by whom.
Regarding records management, Dan said that they provide the "abilITy to declare records in place." This functionalITy must be enabled at the sITe level using the SITe Collection Administration and the Library Declaration Settings. Once records management has been enabled, however, you're able to use the Declare as Record feature and, once so declared, an ITem is locked and is no longer available for edITing (by anyone).
<img src="http://communITy.bamboosolutions.com/aggbug.aspx?PostID=32745″ width=”1″ height=”1″ />
Quest Software (
