Permissions and Roles

When assigning permissions to a SharePoint site, it is important to remember the ease of transition for SharePoint users when task assignments change. In a large SharePoint network with hundreds of users, transferring users from role to role, it will be useful to apply active directory on the Farm level.

Using active directory allows you to assign roles to people within your SharePoint site, with some other perks throughout your system which I won't discuss here. When users are assigned roles, they are given permissions that are specific to that position. This is useful when certain positions need certain access to perform different tasks. With pre-designed roles, the user will inherit all of the permissions needed across the entire site collection.

One of the main things to protect is the privacy of your site, this means that you are aware of what people are and are not allowed to do on your site. Generally, there will be groups of people that are assigned different tasks to perform on the site. There are pre-designed groups which are automatically prepared for your SharePoint site. These are pretty easy to interpret, but for ease we'll go through them.

• Administrator: These rights are provided to individuals with permissions to edit every detail of the site and implement different attributes which may be applied to the site. When a user belongs to a role in this group, their site settings selection will expand to include site collection features and so forth. 
• Owner: These individuals have similar rights as the administrator except cannot access site collection features throughout the site collection.
• Developer: Predominately have the permission to create and edit site content, but not as extensive as the Owner. Though this might be vague, the developer is able to contribute to the expansion of those things which the owner has made. 
• Visitor: These are people which might have contribute rights. This means that they may add things to document libraries or lists, but are not able to remove things. When you have a review process for things which are trying to be added to a site, visitors may not have a bad effect on your site

These are only a few of the pre-designed groups which are available, but this is not to say that you cannot create your own. A word of advice would suggest not assigning individuals to a group, but rather assigning roles to an individual to keep track of universal permissions.

Having different roles in your permission groups does not mean that I disagree with you, in fact, this is what I do. I have different titles in the permission groups so that when someone new gets hired, when don't need to go through each site and add them, but use active directory to automatically take care of that. 

When you are creating your sites, it is important to remember that they inherit the same permissions as the parent sites by default. If you are trying to make sites specific for individuals, there might come an occasion when you need to stop inheritance and ensure that permissions are changed. To do this you can simply go to the permissions tab on the ribbon when you decide to edit your site and change these permissions. It is important that you stop inheritance before you try to update your site, otherwise there is a strong chance that your site will update and the permissions from the parent will go down to the child. 

One of the things that you want to avoid is Orphan sites. These are sites which are not connected to a parent site which a user may access. This means that they would either have a direct link to the site to access it, or have a link somewhere else throughout your site. In the end, neither of these situations are ideal. As a rule of thumb which I have, when securing your site, have the most secure sites deep within your collection and the least secure as the home page. This will add to the ease of users with little or no troubleshooting.