MOSS2007 Security

911 views
863 views

Published on

This was written for a client that explains security for their intranet using both SharePoint and Active Directory.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
911
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • This was done quickly and not completely finished. It will be updated soon……
  • MOSS2007 Security

    1. 1. SharePoint Security<br />Security in MOSS2007 can be simple or it can be complex depending on the business requirements and the security needs of end-users and site owners. The security benefit/advantage in using MOSS2007 is that you now have more flexibility and control and along with that can bring more complexity and a greater responsibility for the user managing permissions.<br />I will provide a general overview and description and then discuss the security model we currently have in place for your company SharePoint environment.<br />Written by Jose M. Tamez<br />This is not a reference guide for complete overall security in MOSS2007 . This document provides details that specify use of available functionality that fulfills the requirements for this project.<br />
    2. 2. Security for SharePoint is more complex because unlike before, we can break it down, break it apart, and apply it at a granular level. This couldn’t be done in previous versions of SharePoint and this is now one of the new features in MOSS2007, <br />setting permissions down to the item level. <br />If you go to a document library, and then click on the document and open the dropdown menu (Edit Control Block), you will see listed in the menu “Manage Permissions” whereby you can set unique permissions for that item. This would break the permission inheritance from the site (depending where the item is i.e., root site, sub site, workspace) and you would then be customizing permissions for that item. Customizing means that the permissions applied are different from the top level site and could be different from any other part of SharePoint.<br />This leads me to the main premise behind a typical security model in MOSS2007. You either inherit permissions from the top or you create your own custom permissions for your sub site, lists, libraries, or documents. If you decide to break inheritance then you’re left to manage those permissions for that object yourself. Before I go into more detail on how to manage permissions on a lower level, I will now explain how security is setup at the top, at the site collection level. I will also explain SharePoint groups and permission levels.<br />But first, we need to know the different administration levels and their assigned level of responsibilities.<br />1)    Local Machine Administrator (Server Administrators)<br />2)    Web Application Administrator (IIS Application Pools)<br />3)    SharePoint Farm Administrator (can be different or the same account)<br /> a)    Central Administration<br /> b)    (SSP) Shared Services Provider<br />4)    Site Collection Administrator<br /> a)    (Administration of all content – Has full control and can override all Site Owners)<br />5)    Site or Sub Site Administrator<br /> a) Site Owner<br />When creating the top-level site (root site or Site Collection - all the same), SharePoint out-of-the-box by default is setup to use three SharePoint<br />groups for use with the three different permission levels. Now granted, depending on the site definition (template), you may see other SharePoint<br />groups e.g. publishing template w/workflow has the added “Approval Group”. The three SharePoint groups we want to pay particular attention too<br />are the ones created out-of-the-box regardless of site definition.<br />
    3. 3. **********************************Permission Levels***********************************<br />The permission levels used for each out-of-the-box SharePoint group is as follows:<br />Owners: Full Control - Has Full Control<br />Members: Contributor – Can view, add, update, and delete.<br />Visitors: Read - Read-Only<br />*****************************************************************************************<br />Keep in mind that these are standard out-of-the-box permission levels and there are others. Here is a list of all permission levels used in SharePoint:<br />·         Full Control<br />·         Design<br />·         Manage Hierarchy<br />·         Approve<br />·         Contribute<br />·         Read<br />·         Restricted Read<br />·         Limited Access (used only by SharePoint)<br />The next slide will provide a screen shot of those permission levels at the Site Collection level:<br />
    4. 4.
    5. 5. You can edit permission levels here but if you click the “Edit Permission Levels” link you will get a warning message that will say this:<br />“You are about to create custom groups and custom permissions for this site.<br />Changes to the parent groups and permissions will no longer affect the site.”<br />You don’t need to do this! You will lock out all users and then have to customize all the different permission levels. This would be a security management nightmare and I’ve seen other administrators doing this.<br />
    6. 6. Here is a screen shot of the page that allows you to modify a particular permission level. This one happens to be “Contribute”. At the Site Collection Level you cannot modify the Full Control permission level. If you click Full Control you will see it’s shaded out. Click the Contribute link and take a look at the different permissions.<br />
    7. 7. FARM LEVEL:Here is a screen shot of the Permission Policy Levels at the Farm Level:<br />
    8. 8. FARM LEVELHere is a screen shot of the permissions you can use to create a custom permission policy. These can override the Site Collection Permission Levels and can be customized and managed from here.<br />So administrators can customize permission levels at both the Site Collection and Farm Level. This can be misleading and I have seen administrators using both to apply security to a site collection. Think about the difficulty of managing permissions and creating custom permission levels from both the Site Collection and Farm Level. Wrong scope, Not a practical solution and also not necessary. The SharePoint team has already thought about this and has made it easy for architects to implement the right security model with right training.<br />
    9. 9. http://yoursite/acct/Unless you change and customize permissions for accounting sub site it will inherit permissions from the root.<br />Based on site security requirements provided by each site owner. Each site owner provided a list of all areas within their department sub site that required different permission settings from the root site. We had to break inheritance and customize permissions to meet those needs. We broke inheritance by changing permissions for each sub site. But first, we had to create new SharePoint Groups for each sub site and then used the same SharePoint permission levels. The example below uses the accounting sub site.<br />Now we have:<br />·         Accounting Owners<br />·         Accounting Members<br />·         Account Visitors<br />Remember permission levels explain above<br />That’s correct! Done the same way but now I will explain the difference when we use Active Directory. We will take Active Directory groups and place them in our SharePoint security groups. You can probably see how this will make it much easier to manage at this point.<br />
    10. 10. Active Directory and SharePoint<br />Active Directory is used to better manage groups of users. Instead of placing individual users into each one of these SharePoint groups, we have Active directory create groups for use in SharePoint.<br />The first thing we do is to request that the Active Directory administrator create the initial Active Directory group for users that are granted read-only access to SharePoint. I do not use the “NT AUTHORITY/authenticated users” group and I delete it from all web application farm policies. The group we use is called SharePoint_Users and all company employees are placed in that group (Active Directory nesting can be used).<br />Then we request the administrator to create three groups for each sub site. This should be planned out ahead of time during requirements gathering, and done for each sub site that will have custom permissions. We then find out who the site owners will be and request from them a list of users that are assigned to each SharePoint Group. Those users will be placed in each Active Directory group.<br /> <br />YOUR DOMAINmarketing administrators (usually just two users)<br />YOUR DOMAINmarketing editors (users that are allowed to modify documents)<br />YOUR DOMAINmarketing visitors (All marketing users allowed access to the sub site with read-only rights)<br /> <br />This allows Active Directory administrators to keep control of users in each group and it makes it easier for a SharePoint administrators and site owners to manage permissions and users when customizing security for a sub site, or any other object. If a person or user is not in a particular Active Directory group you can always put them in the SharePoint group individually.<br />At the top level the Active Directory group we use for read-only access is the “SharePoint Users” group. All Germania employees that require access to SharePoint will be put into the Active Directory “SharePoint_Users” group. We then put the AD “SharePoint_Users group into the YourSite visitors SharePoint group. That means they will only have “READ” rights because the SharePoint group YourSite visitors is assigned “READ” permissions. This will also apply to all sub sites that inherit from YourSite.<br />That’s how it works. Based on requirements we requested from each site owner:<br />1)    Who do you want to visit your site?<br />2)     Who do you want to edit (collaborate) on files (documents)<br />3)    Who do want to manage (admin) your sub site (department site). <br />
    11. 11. Example<br /> Now, it comes down to this, we don’t want to inherit the permissions from the root site and we want to create different permissions for my new sub site. This is the tricky part that requires some thought and preparation discussed previously. This is where we need to plan how we apply our security and how we want to keep track and manage it. Keep in mind that we are dealing with containers e.g. Site Collection, Sub Sites, lists, and documents (item-level). So if we break inheritance and apply custom permissions to a sub site, all items underneath will inherit from that sub site. But it’s simple because we are now familiar with our SharePoint groups and the way groups are setup in Active Directory.<br />Where will a sub site be created? Under the root site, under a department sub site, or under another sub site several levels underneath a department sub site? This is important because depending on where my sub site is created, I will inherit those permissions from the site above me and that may not be the permissions I want to use. Then you would have to break inheritance and create your own.<br />Take a look at a project site that is underneath the Projects sub site. Projects has its own custom permissions, and you can see this when you navigate to “People and Groups”. It has Projects Owners, Projects Members, and Projects Visitors. It broke inheritance from the PMO sub site that has its own custom permissions. It will also be listed in “People and Groups” as PMO Owners, PMO Members, and PMO Visitors. If you navigate [Departments] [IT] [PMO] [PROJECTS] and then choose any project under Strategic, App Enhancement, or Production Support, check the permissions for each of those project sub site and you will see they are either inheriting Permissions from PMO or they have created their own customized permissions. <br />Steps for setting up custom permissions<br />If we want to create our own security for our sub site and move away (stop inheriting from root), we first need to create our own sub site (department) groups, and then apply our own permissions for each group. This is how it’s done.<br /><ul><li>1.    Site Actions
    12. 12. 2.    Site Settings
    13. 13. 3.    People and Groups
    14. 14. 4.    Click Groups
    15. 15. 5.    Click Settings
    16. 16. 6.    Scroll down and click “Set Up Groups”
    17. 17. 7.    Click “Create a new group” We don’t want to use the YOURSITE groups, the existing group.</li></li></ul><li>Now we can apply our Active Directory Groups.<br />(Using Test site as an example)<br /> If you decide to allow all users to access you site with read-only access then click the people picker and search Active Directory for “SharePoint_Users” group. This will give all those people in that group access to your site with “Read-Only”.<br />
    18. 18. ITEM LEVEL PERMISSIONSThroughout this paper we’ve talked about managing permissions at site level. Now let’s talk about permissions at item level. I mention this because there is a slight difference in the way you can apply permissions. Take a look at the following example. Security requirements for the Marketing sub site Calendar is as follows: Read/Write Access = Everyone in Marketing Dept.Read Only Access = Everyone only in Marketing Dept.<br />
    19. 19. See what I did?<br />I took the AD group GERMANIA-INSmarketing_visitors(because that’s everyone in marketing only) and assigned “Contribute” permissions and then added the marketing administrators with “Full Control” permissions. So now they’re no longer inheriting from the root and now have their own custom permissions. The difference is that I also customized the level permissions.<br />At first it will look like this:<br />In this state it is inheriting from the parent site.<br />Click the “Actions” dropdown arrow and click “Edit Permissions”. It also says “Copy permissions from parent, and then stop inheriting permissions”. That’s exactly what we’re doing. When you click “Edit Permissions” you will get a warning message “You are about to create unique permissions for this list. Changes made to the parent site permissions will no longer affect this list”. <br />
    20. 20. You will now see this:<br />
    21. 21. Click the top checkbox and that will select all and tick all checkboxes.<br />Now click “Actions” and click “Remove User Permissions”. This will delete all listed groups and permissions but first you will get a warning message saying “Are you sure you want to remove all permissions for the selected users and groups to “Calendar”? Click “OK”. Now the list is blank and you need to add your AD groups. Click “New” and click “Add Users”. This will bring up the people picker where you locate the desired AD group for your custom permissions and bring in to the list.<br />
    22. 22. Click the book icon next to the check user name icon.<br />
    23. 23. In the “Find” box type “marketing” and click the search icon. Based on marketing site owner requirements; Read/Write Access = Everyone in Marketing Dept.Read Only Access = Everyone only in Marketing Dept. So we brought in the YourDomainmarketing visitors AD group. (Yes, those are the requirements received.)<br />
    24. 24. Click Add -> and then click “OK”. <br />
    25. 25. Now you will this:<br />You will see that we now have the ability to apply permissions from the “Give users permissions directly” section. We now assign “Contribute” permissions to the AD group.<br />We have met and satisfied security requirements for the Calendar list. Only marketing employees that are in the AD group “YourDomainmarketing visitors and should include all employees that work in marketing. We have given them “Contribute” permissions that will allow them to view all, add, update, and delete files. No other groups have access.<br />
    26. 26.  The following is a list of all Active Directory Groups that are used in SharePoint for this project:<br />1.    Accounting Administrators<br />2.    Accounting Editor<br />3.    Account Visitors<br />4.    Claims Administrators<br />5.    Claims Editor<br />6.    Claims Visitors<br />7.    Executive Administrators<br />8.    Executive Editor<br />9.    Executive Visitors<br />10.  HR Administrators<br />11.  HR Editors<br />12.  HR Visitors<br />13.  IT Administrators<br />14.  IT Editor<br />15.  IT Visitors<br />16.  Life Administrators<br />17.  Life Editor<br />18.  Life Visitors<br />19.  Marketing Administrators<br />20.  Marketing Editor<br />21.  Marketing Visitors<br />22.  Mspuser (test)<br />23.  mspuser2 (test)<br />24.  Pricing Administrators<br />25.  Pricing Editor<br />26.  Pricing Visitors<br />27.  SharepointAdmins<br />28.  Sharepoint Users<br />29.  Underwriting Administrators<br />30.  Underwriting Editor<br />31.  Underwriting Visitors<br />That’s it and as always please provide some feedback or send all questions to @email…..<br />

    ×