Securing Microsoft SharePoint Portal 2003 Access, Administration and Content
Module Topics
WSS vs. SPS — Process and Database Security Portal and Site Access Authentication Securing Portal Administration Delegating Site Management Security Validation Authorizing Site Users List-level content permissions
Security Overview
IIS Admin VServer
End-User VServer Site Collection
Site
Portal Site
Site
IIS Configuration WSS Configuration
Admin vserver: Custom TCP port for access Access granted via IIS authentication Control granted via group membership to box Administrators group or Portal Admins group End-user vserver: Access granted via IIS authentication Portal Site: Access granted via direct, site and crosssite group membership Site Collections: Potentially many per vserver e.g. http://svr/sites/mysite Access granted via direct, site group and cross-site group membership Sites (a.k.a. sub-Webs): Many per site collection e.g. http://svr/sites/mysite/web Same content db as parent site Access granted via direct, site and crosssite group membership
IIS Security and Application Pools
Each virtual server in IIS can have its own application pool
An application pool is a dedicated (set of) process/es that actually services requests coming in to that virtual server
Each application pool has a unique user identity which will need access to SQL server
With SPS Web farms, server portal services need to talk box-tobox:
Domain account for admin virtual server’s application pool should be decided before WSS install, and should have create db and security administrator rights in SQL server Domain account for admin and content virtual servers should be different. Each Web front-end box should have the same accounts across the farm: Different accounts can be used, but this requires manual setup
SQL Security for SharePoint Services
Two modes – Windows authentication or SQL Server authentication (“SA authentication”) By default, WSS uses Windows authentication (more secure, recommended by SQL team) WSS can be set up to use SA authentication:
This is an install time choice and cannot change Each content database can have unique credentials
IIS Authentication
Authentication – the verification of identity of a person or process: Different from authorization, which determines which functions you can perform WSS and SPS do not perform authentication – this function is handled by IIS IIS’ authentication mechanism requires an NT account (either local, NT domain, or AD domain)
Anonymous Access
Two places to enable:
Direct IIS virtual server level Portal Site level
Install-Time Selection of Authentication Modes
Two main setups for authentication – account creation mode or pre-existing domain With a pre-existing domain, use IIS with Windows authentication enabled, no new user accounts needed Account creation mode is a feature, selected at install-time, that will generate a new account in the AD for each user – pre-existing accounts cannot be used. IIS is set up to use basic or digest authentication Passport authentication and WSS don’t work well together
Security “hierarchy”
Member of local administrators group has full control over all portal properties and sites
Virtual Server represented within IIS controls access type (anonymous vs. userauthenticated) for all contained site collections
Site collection represented with a single top-level site which can contain many child sub-sites
Site collection/Top-level site can act as a unit of administration for all sites in collection via the sitecollection administrator role
Each sub-site can have its own administrator
Server and Portal Level Administration
WSS supports two sets of high level administrators: box admins and SharePoint Administrative Group members:
SharePoint Administrative Group is defined by the administrator in WSS Central Administration WSS checks to see if the current user is a box admin or in the domain created SharePoint Administrative group. If so, full access is granted to all site collections
Four abilities of box admins that WSS admins do not have:
Change configuration database Change WSS admin domain group Manage content paths Extend/un-extend IIS virtual servers
Content Security – WSS Authorization
Two main securable resources within WSS that support ACLS:
Lists and Webs
Implementation is similar to NT system:
WSS specific ACLs dictate access:
ACL is a collection of ACEs, each of which maps a security principle (user, group, etc.) to a set of rights
NT is called for domain group resolution
Top Level Sites
A Top-level site represents the root of a site collection 1:1 mapping between Top-level sites and Site Collections A Top-level site/Site Collection can have many sub-sites Individual users can be marked as Site Collection Administrator: This grants them full access to all content Site collection administrators have three main responsibilities: Users and cross-site groups on the site collection: Users are rolled up at the site collection level, and can be managed there Cross-site groups are scoped to the site collection level Quota issues for the site collection Rights mask for the site collection
Site-Wide Security
A Web site is a set of Web pages that are managed as a whole A Web site can have a parent Web and child Webs A Web Site’s security can be either inherited from its parent Web or unique
Permissions in WSS
WSS uses “rights” – a right is a privilege that allows a user to perform an action on the server:
Example: View Pages, Insert List Items, Change List Permissions There are currently 21 rights (listed on next slide) Some rights are dependent on others, for example, Insert List Items has View List Items as a dependent
At the IIS virtual server level, there is a “rights mask:”
This enables/disables rights for use on Web Site Collections within that virtual server Is settable by box administrators and WSS administrators
Site Permissions
Assignable to individual users or Site Groups