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

1. SharePoint Security 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. I will provide a general overview and description and then discuss the security model we currently have in place for your company SharePoint environment. Written by Jose M. Tamez 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.

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, setting permissions down to the item level. 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. 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. But first, we need to know the different administration levels and their assigned level of responsibilities. 1) Local Machine Administrator (Server Administrators) 2) Web Application Administrator (IIS Application Pools) 3) SharePoint Farm Administrator (can be different or the same account) a) Central Administration b) (SSP) Shared Services Provider 4) Site Collection Administrator a) (Administration of all content – Has full control and can override all Site Owners) 5) Site or Sub Site Administrator a) Site Owner 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 groups for use with the three different permission levels. Now granted, depending on the site definition (template), you may see other SharePoint groups e.g. publishing template w/workflow has the added “Approval Group”. The three SharePoint groups we want to pay particular attention too are the ones created out-of-the-box regardless of site definition.

3. **********************************Permission Levels*********************************** The permission levels used for each out-of-the-box SharePoint group is as follows: Owners: Full Control - Has Full Control Members: Contributor – Can view, add, update, and delete. Visitors: Read - Read-Only ***************************************************************************************** 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: · Full Control · Design · Manage Hierarchy · Approve · Contribute · Read · Restricted Read · Limited Access (used only by SharePoint) The next slide will provide a screen shot of those permission levels at the Site Collection level:

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: “You are about to create custom groups and custom permissions for this site. Changes to the parent groups and permissions will no longer affect the site.” 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.

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.

7. FARM LEVEL:Here is a screen shot of the Permission Policy Levels at the Farm Level:

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. 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.

9. http://yoursite/acct/Unless you change and customize permissions for accounting sub site it will inherit permissions from the root. 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. Now we have: · Accounting Owners · Accounting Members · Account Visitors Remember permission levels explain above 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.

10. Active Directory and SharePoint 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. 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). 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. YOUR DOMAINarketing administrators (usually just two users) YOUR DOMAINarketing editors (users that are allowed to modify documents) YOUR DOMAINarketing visitors (All marketing users allowed access to the sub site with read-only rights) 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. 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. That’s how it works. Based on requirements we requested from each site owner: 1) Who do you want to visit your site? 2) Who do you want to edit (collaborate) on files (documents) 3) Who do want to manage (admin) your sub site (department site).

12. 2. Site Settings

13. 3. People and Groups

14. 4. Click Groups

15. 5. Click Settings

16. 6. Scroll down and click “Set Up Groups”

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.

19. See what I did? I took the AD group GERMANIA-INSarketing_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. At first it will look like this: In this state it is inheriting from the parent site. 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”.

20. You will now see this:

21. Click the top checkbox and that will select all and tick all checkboxes. 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.

22. Click the book icon next to the check user name icon.

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 YourDomainarketing visitors AD group. (Yes, those are the requirements received.)

24. Click Add -> and then click “OK”.

25. Now you will this: 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. We have met and satisfied security requirements for the Calendar list. Only marketing employees that are in the AD group “YourDomainarketing 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.

26. The following is a list of all Active Directory Groups that are used in SharePoint for this project: 1. Accounting Administrators 2. Accounting Editor 3. Account Visitors 4. Claims Administrators 5. Claims Editor 6. Claims Visitors 7. Executive Administrators 8. Executive Editor 9. Executive Visitors 10. HR Administrators 11. HR Editors 12. HR Visitors 13. IT Administrators 14. IT Editor 15. IT Visitors 16. Life Administrators 17. Life Editor 18. Life Visitors 19. Marketing Administrators 20. Marketing Editor 21. Marketing Visitors 22. Mspuser (test) 23. mspuser2 (test) 24. Pricing Administrators 25. Pricing Editor 26. Pricing Visitors 27. SharepointAdmins 28. Sharepoint Users 29. Underwriting Administrators 30. Underwriting Editor 31. Underwriting Visitors That’s it and as always please provide some feedback or send all questions to @email…..