1. Permissions No Permission, No SharePoint Callahan

2. Thanks to our Sponsors!  Platinum:  Gold:  Silver:  Raffle:

3. 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-SharePoint- User-Group-3769745/abouthttps://www.linkedin.com/groups/Pittsburgh-Area-SharePoint- User-Group-3769745/about

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

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

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

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

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

9. 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 You can have it be a Domain Admin, but best practice is to make it a local Administrator of each SharePoint server individually It MUST have a Login on the SQL server, and be a dbcreator and SecurityAdmin on the SQL server 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

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

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

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

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

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

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

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

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

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

19. Permissions (After Authentication, it’s all about Permissions...) Callahan callahan@callahantech.com Twitter: @cacallahan Facebook group: https://www.facebook.com/groups/callahanSPF/ https://www.facebook.com/groups/callahanSPF/