Transcript SPS Permissionsx

Callahan
Permissions
No Permission, No SharePoint
Thanks to our Sponsors!
 Platinum:
 Gold:
 Silver:
 Raffle:
More Fun Stuff
Raffle: Please join us in the Atrium at 5:15 PM for the raffle. We are
raffling some exciting prizes including Fitbits, HP tablets, and who
knows, maybe a Surface 3 (need to be present to win)!!!
SharePint will be held at Mad Mex (370 Atwood St, Pittsburgh, PA
15213). While it starts at 5:30 PM, there’s no end time!!!! 
Pittsburgh Area SharePoint User Group
Meets at the Microsoft office on the North Shore
More Info: https://www.linkedin.com/groups/Pittsburgh-Area-SharePointUser-Group-3769745/about
We do Request that…
You fill out the Session Evals. These will also be your Raffle tickets.
Print your name clearly if you intend to participate in the Raffle and
drop the forms at the registration desk after the last session.
You visit the sponsors. The event is possible due to their generous
support and we request that you visit them and inquire about their
products & services.
Cell phones be kept on silent as a courtesy to other attendees and
speakers
Agenda
• Permissions
• What they do
• Authorization versus Authentication
• Types of Permissions
• Everyone thinks it’s about user permissions...
• Inheritance
• Breaking inheritance
• Extras
• Oldies but goodies– Members and the disappearing team site home page, and Members
don’t just contribute anymore
• List Advanced Settings
• Oh, so that’s what it does...
• Hidden people (or, how to keep from having too many user objects haunting you Site
Collections)
Prerequisites
• Basic understanding of permissions does help
• Experience using SharePoint
• Some experience administering SharePoint
• Interested in learning/reviewing the details of Permissions regarding
SharePoint top to bottom
• Willing to sit through an hour long session about SharePoint
• There should be refreshments afterwards
• Sense of humor
Permissions what they do
• After an authentication provider verifies that a user has the right to login to
SharePoint, SharePoint gives Authorization to use its resources
• Permissions are that authorization
• And only authorization within the actions one would perform to use or administer SharePoint
farms, web applications, site collections, sites, pages, lists, libraries, web parts, and users.
• SharePoint organizes Permissions into three general categories
• List
• Site
• Personal
• To apply those permissions to users, you combine them into Permission Levels
• You can create groups, Permission Levels to the groups, then add users (or AD
security groups) to those groups
• You can also add users individually, and apply Permission Levels to them directly
• Useful if they simply don’t fit into an existing group
Types of Permissions
• Service Accounts
• Don’t forget the file shares or SQL
• Farm Administrators
• Service Application Adminstrators
• Web Application Policies
• And the convenient Auditor
• Site Collection Administrators
• ”There can be only one... At a time...”
• Owners
• Groups
• Users (finally)
Service Accounts
• The Farm account should be a normal domain user
• It is given special permissions on the SharePoint server and in SQL by the Install account
• The Install account should only be used for installing SharePoint
• Not as an account you log in to regularly
• It is the most powerful SharePoint account
•
It has to have the administrative right to install software on the SharePoint server, and install, start, stop services, and server roles
•
It MUST have a Login on the SQL server, and be a dbcreator and SecurityAdmin on the SQL server
•
You can have it be a Domain Admin, but best practice is to make it a local Administrator of each SharePoint server individually
• Services and web applications need service accounts
• They should be domain accounts only
• They should be added to SharePoint as managed accounts after installation
•
Except for the Search Index account for some reason
• You may want to reconsider having SharePoint manage passwords.. But it’s up to you
• If you do SharePoint Backups, make sure you give the correct accounts access to the backup location
• Service Applications, like User Profile Service, might need additional (and excessive) permissions, see documentation for
those services for more information
Farm Administrator
• SharePoint adds the server’s local, built in Administrators group to the
Farm Administrators at installation
• Remove them as soon as you can afford to do so
• The Farm Account MUST be a farm administrator
• In order for Farm Administrators to be able to change services and roles on
the server, they also need to be administrators on the server
• If a Farm Administrator is not also a local server administrator, what they can do in
Central Administration is curtailed (rather making them junior farm administrators)
• You can make an account an administrator for a single service application,
and they will be able to log in to Central Administration to administer that
service application, but will only be able to see the options they need to
work on that service application
Web Application
• All permissions are actually managed at the Web Application level
• At this level you can choose which permissions will be available for the site collections within that web
application. EVEN site collection administrators, EVEN user policy accounts, cannot use permissions that are
not allowed from the web application level
• On the web applications list page in Central Administration, select the web application you want to modify, then click User
Permissions in the ribbon. Remove the check from the box next to the permissions you do not want to be available to ANYONE
who uses site collections in that web application.
•
Cruel administrator trick
• Web Application policies can be created to give overriding permissions to accounts to do things
(or block them explicitly from doing things), in the site collections therein.
• Permission Policy
• Permission levels used that the Web Application level. You can create an easy default “Auditor” permission level here, to give
someone overriding read rights to everything contained in the web application. You can also explicitly DENY permissions in a
permission level, so that, when applied to a user policy holder, that account explicitly cannot use that permission for that web
application’s site collections.
• User Policy
• Add user accounts (or service accounts) and apply a Permission Policy to them for the site collections in the web application.
They can be set to show up as a “System Account” obscuring their real name for actions in the site collection
• Anonymous Policy
• Here you do step one of allowing anonymous to the content in the web application. Then it is further applied, specifically, in
the site collections themselves
Site Collection
• Site Collection Administrators can be assigned (and are initially) at the
farm level
• Site Collection Administrators override site Owners
• Site Collections are collected from the top down
• The top level site of a site collection holds all the administrative powers for all
subsites beneath it (even in some cases, if inheritance is broken, such as
features and templates)
• Subsites can break from inheriting permissions from the top level site
• They initially simply keep the permissions and groups from the top level site, but they
can be changed
• All users and groups are listed at the top level site, even if they are not
applied there
Subsites
• Subsites can be created within a Site Collection
• They automatically inherit all settings, such as features, templates, users,
groups, and permissions
• Subsites can have numerous subsites beneath them as well
• Their permissions will define the permissions of the subsites beneath them
• If they break inheritance from the top level site, then all directly beneath them in the URL
path, will use their permissions, not the top level site
• When inheritance is broken, the subsite can have it’s own unique owners,
users, etc. BUT they will never be able to block the Site Collection
Administrators
Inheritance
• The point of a site collection is that the permissions set at the top level site
cascade throughout the subsites below it
• Eases administration
• Simplifies management
• A subsite, list, library, page, or item can be set to have it’s own unique
permissions if necessary
• Makes it harder for Search to work
• Adds complexity
• Can cause confusion concerning user permissions
• That said, it is a good idea to make the home page uneditable for Members
• You cannot block a site collection administrator (or web application user
policy)
Permissions are everywhere, at every level...
• Because SharePoint is network accessible resource, everything about it requires permissions... To
install, to configure, to use...
• The server has to be on a domain
• The account to install SharePoint on has to have the correct permissions in SQL (unless you are installing a
standalone server)
• SharePoint requires a domain user account to use as the farm account
• The farm account will create all subsequent databases for SharePoint in SQL
• Web Applications have content databases. Those web applications have to have a service account to access
those databases.
• To do backups and restores, the correct SharePoint accounts must have access to the file share
• If a file share contains documents that are indexed by search, the users that need to find them must have
access to that file share
• Each Web Application can have their own Permission and User Policies that override those used by the site
collections they contain
• Site collections can be user boundaries
• Site Collection Administrators are different than Owners... Although Owners often don’t realize that
•
What can a site owner do anyway?
• There are Permissions, which are combined into Permission Levels, which are then applied.
• Permissions are never individually applied
• Groups can be created and have Permission Levels applied to them
• Then users (or AD security groups) can be added to the Groups
•
Or... The users can be added individually then have permission levels applied to them
Some little issues...
• The home page for the Team Site (one of the most popular templates
used in SharePoint) is a wiki page for SharePoint 2010 and 2013
• Think about that a minute--- it’s in a library...
• In SharePoint 2013, Members no longer are Contributors by default,
they’re Editors
• This can cause some issues, like deleting any list or library they’d like to...
• Advanced Settings for all lists and libraries can be used to modify
what users can use them for– even if they do have rights as editors or
contributors
• Naughty administrator pranks...
The Ghost in the site collection
• Say you have a user in a group
• And then you remove that user
• Where does that user actually go?
• Away? No, not really
• What is the difference between removing a permission from a user and
deleting the user from a site collection?
• Remember, it is best practice to keep the number of individual users down
• How to see ghosts?
• Go to a group page, append the MembershipGroupID= with 0
• Example: MembershipGroupId=0&FilterField1=ContentType&FilterValue1=Person
• It will show you the forgotten ”All People” page
• You can see the people from whom you’ve removed permissions, so they can’t access the site, but
are missing from the site permissions or People and Groups page
• Open their User Information page, and Delete from site collection to truly remove their account
Summary
• Permissions
• What they do
• Authorization versus Authentication
• Types of Permissions
• Everyone thinks it’s about user permissions...
• Inheritance
• Breaking inheritance
• Extras
• Oldies but goodies– Members and the disappearing team site home page, and Members
don’t just contribute anymore
• List Advanced Settings
• Oh, so that’s what it does...
• Hidden people (or, how to keep from having too many user objects haunting you Site
Collections)
Permissions
(After Authentication, it’s all about Permissions...)
Callahan
[email protected]
Twitter: @cacallahan
Facebook group:
https://www.facebook.com/groups/callahanSPF/