Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 27 ppsx

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Security Plan 5-5
• Installation privileges. SharePoint 2010 has its own account that you use to run
the initial setup process and the SharePoint Products Configuration Wizard.
You should not use your own account or a generic administrative account.
This specific SharePoint account must be a local administrator but should not
be a domain administrator.
• Administrator privileges. Administrative privileges should only be granted if
these privileges are necessary. Never grant them where they are not specifically
required. This applies to domain administrators, local administrators, site
collection administrators, and Internet Information Services (IIS)
administrators.
• Services. Each service relies on a service account. Some services require a
separate account that is dedicated to their specific role. You can create a
separate account for a particular service to provide isolation for that service.
For example, you can create a separate account for the Search Crawl Service.
This service is often configured to use the service account for the SharePoint
farm, which grants more privileges than are required. This creates a security
risk by exposing confidential information in the search results. By creating a
separate account for the Search Crawl Service, you mitigate this security risk.
• Application pools. IIS hosts application pools, and they use the application pool
account, which identifies the application pools. You can isolate applications
that host sensitive data by hosting them in their own application pool.


MCT USE ONLY. STUDENT USE PROHIBITED
5-6 Designing a Microsoft® SharePoint® 2010 Infrastructure
Security Architecture in SharePoint 2010

Key Points
A security architecture describes the various elements that you require to configure

security for your SharePoint infrastructure and the relationships between them.
These are primarily SharePoint elements, such as SharePoint groups and
permission levels. However, there are external elements that you must also
consider, such as Active Directory® directory service groups and user accounts.
Key elements include:
• Service accounts. Service accounts enable SharePoint services to run and to
communicate with other services. Service accounts are most often Active
Directory user accounts.
• Permission levels. Permission levels are collections of individual permissions
that you group together to simplify the process of assigning permissions for
securable objects.
• Site collection and site permissions. Each site collection and each site in your
SharePoint infrastructure has permissions that you can use to control user
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Security Plan 5-7
access. Your security plan must incorporate guidance about how to use these
permissions.
• Security groups. You can assign SharePoint 2010 permissions to SharePoint
groups, Active Directory groups, or local Windows® operating system groups.
Your security plan must include guidance about which type of group is
appropriate in your SharePoint infrastructure.
• Permission policies. Permission policies provide a centralized way to configure
and manage a set of permissions that applies to only a subset of users or
groups in a Web application.
• SSL. In addition to configuring security content via permissions, for sites that
contain sensitive information, you must ensure that traffic between the client
and the Web Front End (WFE) server is secure. SSL is the recommended
method for encrypting such traffic.

MCT USE ONLY. STUDENT USE PROHIBITED
5-8 Designing a Microsoft® SharePoint® 2010 Infrastructure
Lesson 2
Planning for Service Accounts

SharePoint 2010 relies on service accounts to run services and service applications.
You must configure these service accounts with sufficient permissions and
privileges to perform their functions. However, you must not grant them so many
permissions that you increase the risk of a security breach. It is particularly
important to ensure that the service accounts do not have administrative privileges
for the SharePoint farm, the Active Directory domain, or the local machine unless
they are specifically required.
Objectives
After completing this lesson, you will be able to:
• List the service accounts that SharePoint 2010 uses.
• Plan security for service accounts.
• Document your plan for security for service accounts.
• Describe the best practices for security for service accounts.
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Security Plan 5-9
What Are Service Accounts?

Key Points
Service accounts enable services to run. They also enable communication between
the different services on which SharePoint 2010 depends. Service accounts may be
part of SharePoint 2010 or they may be part of an external system.
Communication between the IT teams that manage the different aspects of the IT
infrastructure is crucial when you plan a SharePoint 2010 deployment, A common
reason for failure when you configure security for a SharePoint deployment is lack
of coordination between the Windows (Active Directory) team, the SharePoint

team, and the Microsoft SQL Server® database administrators (DBAs). Planning
should identify the accounts that you require to deploy SharePoint 2010 and the
time at which you will require them. You must ensure that you have created and
granted the appropriate permissions to all of the required accounts before you
begin the SharePoint deployment.
The following table describes the purpose and requirements of the core service
accounts that are used in a SharePoint 2010 farm.

MCT USE ONLY. STUDENT USE PROHIBITED
5-10 Designing a Microsoft® SharePoint® 2010 Infrastructure
Account Purpose Requirements for account
SQL Server
service
account
SQL Server uses this account to start
and run the following services:
• MSSQLSERVER
• SQLSERVERAGENT
The SQL Server service account
must be either a local system
account or a domain user
account.
Setup user
account
The Setup user account runs the
following:
• Setup
• SharePoint Products
Configuration Wizard
The Setup user account must:

• Be a domain user
account.
• Be a member of the
Administrators group
on each server on
which Setup is run.
• Have a SQL Server login
on the computer
running SQL Server.
The Setup user account must be
a member of the following SQL
Server security roles:
• securityadmin fixed
server role
• dbcreator fixed server
role
Server farm
account
The server farm account is used to
perform the following tasks:
• Configure and manage the
server farm.
• Act as the application pool
identity for the SharePoint
Central Administration Web
site.
• Run the Microsoft SharePoint
Foundation Workflow Timer
Service.

The server farm account:
• Must be a domain user
account.
• Has additional
permissions that are
automatically granted
on Web servers and
application servers that
are joined to a server
farm.
The server farm account is
automatically added as a SQL
Server login on the computer
running SQL Server. The account
is added to the following SQL
Server security roles:

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Security Plan 5-11
Account Purpose Requirements for account
• dbcreator fixed server
role
• securityadmin fixed
server role
• db_owner fixed
database role for all
SharePoint databases in
the server farm
Search
service

account
The Search service account is used as
the service account for the SharePoint
Foundation 2010 Search service.
The Search service account must
have domain user account
permissions.
Search
content
access
account

The SharePoint Foundation 2010
Search Service uses the SEARCH
content access account to crawl
content across sites.
The Search content access
account must:
• Have domain user
account permissions.
• Not be a member of the
farm administrators
group.

Other Service Accounts
You can create accounts to use for specific service applications in your SharePoint
infrastructure in accordance with the principle of least privilege. For example, you
can create a generic account that most of the service applications use, and you can
create specific accounts for service applications that you must manage more
closely.

You should also consider the service accounts that you use to identify application
pools. Application pools contain the SharePoint Web applications. You should
identify any Web applications that require isolation and create a separate account
to identify the relevant application spool.
Question: When would you configure the SQL Server service account as a local
account?
MCT USE ONLY. STUDENT USE PROHIBITED
5-12 Designing a Microsoft® SharePoint® 2010 Infrastructure
Additional Reading
For more information about account permissions and security settings for
SharePoint Server 2010, see



MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Security Plan 5-13
Planning Security for Service Accounts

Key Points
When you plan security for the core service accounts, you must determine whether
to use local or domain accounts for the services and devise a naming strategy for
your accounts. You must also consider the implications of having different
SharePoint environments in the same organization. For example, if you have
development and staging environments in addition to your production
environment, you should add a duplicate set of accounts to ensure that
development and testing are valid.
Using Local or Domain Accounts
Most core service accounts must be Active Directory accounts, including the Setup
user account and the Server farm account. However, some accounts—such as the
SQL Server service account—may be either local accounts or domain-based

accounts.
If the computer on which SQL Server is installed is not part of a domain, a local
user account without Windows administrator permissions is recommended.
MCT USE ONLY. STUDENT USE PROHIBITED
5-14 Designing a Microsoft® SharePoint® 2010 Infrastructure
If the computer on which SQL Server is installed is part of a domain, you should
use a minimally privileged domain account. The SQL Server service account may
need to perform server-to-server activities that can be accomplished only with a
domain user account. A domain administrator should create this account in your
environment before you install SharePoint 2010.
If your organization has a separate Active Directory management team, your
planning must incorporate schedules and mechanisms for liaising with this team.
Naming Strategy
It is recommended that when you devise a naming strategy, you document it
clearly and use it consistently so that each account is identifiable. Consistent
naming is particularly important if there is a separate Active Directory management
team and you must accurately identify each account.
In organizations with multiple environments—such as production, development
and staging environments—the account names should identify the environment in
which the account is used. For example, the service account for service
applications may be named sp-p-serviceapp in the production environment and sp-
s-serviceapp in the staging environment.