Welcome - Sharing information with the community related to Microsoft SharePoint security, information protection and permissions. Topics will also cover identity federation, claims and software development. Articles will at times be technical and focussed at developers/architects. They will also be higher level and discuss concepts and customer use cases. Have a look around, share your thoughts and I do hope you find some helpful content.

Follow me on Twitter @AntonioMaio2

Wednesday, October 30, 2013

Securing SharePoint 2013: It All Begins with Deployment

This post is the first in a series where I'll introduce various concepts and considerations for security in Microsoft SharePoint 2013. These articles will serve as an introduction to those that are either new to SharePoint, or to those that have SharePoint up and running and are looking at the various out-of-box and third-party options available to secure their sensitive information.

Securing Microsoft SharePoint starts at the time of deployment. When first deploying SharePoint to a staging or production environment there are specific best practices that must be employed to ensure a secure and well managed environment. In particular, using appropriate user accounts for various necessary functions is a critical step. This concept is not new to Microsoft SharePoint 2013 as it also applies to Microsoft SharePoint 2010. However, it is of significant importance and therefore deserves mention again.

The purpose of using multiple accounts is to ensure proper separation of responsibilities and activity auditing. Best practices recommend that least privilege user accounts are used for specific deployment and management functions. In other words, specific user accounts are created for very specific functions and those accounts are granted only the privileges required to perform that function—nothing more.

There are varying views on how many user accounts are necessary when deploying Microsoft SharePoint, but most experts agree that at minimum 3 different accounts are necessary to deploy SharePoint to enterprise environments.

1.Setup User Account

This account will be used specifically for running the SharePoint setup wizard, the product configuration wizard and for installing any patches, service packs, cumulative updates or hot fixes. You must login with this account when running the SharePoint setup and configuration wizards, or if you are installing any updates.

This account must be a domain user account and added to the local Administrators group on each server in the SharePoint farm. An example of how this account is often named is: domain\sp_setup_user

The Setup User Account should not have any special administrative privileges on the SQL Server system as long as SQL Server is on a separate system or VM from the SharePoint servers. When running the SharePoint setup and configuration wizards, these processes will use the Setup User Account credentials to create databases and SQL logins for other SharePoint accounts. However, despite the lack of administrative privileges to the SQL Server system (as recommended above), before starting to setup SharePoint, you must assign the Setup User Account to the securityadmin and dbcreator roles in SQL Server.

2.SQL Server Service Account

This account is used specifically by SharePoint when it tries to access data from SQL Server. The SharePoint setup wizard will request this account during the setup process, so you should create it before you begin the SharePoint setup. It needs to be assigned to MSSQLSERVER and SQLSERVERAGENT services when you install SQL Server. An example of how this account is often named is: domain\SQLService

The account requires no special domain permissions. This account will be given all appropriate rights to SQL Server during the SQL Server setup process. Best practices dictate that this account needs to be a user account in the Active Directory domain and it should be secured according to your IT security policies.

3.SharePoint Farm Account

This account is the farm administrator’s account and it is all powerful within SharePoint. This account will be used by the Farm Administrator to login to the SharePoint Central Administration console. This account is used to actually run the SharePoint farm. For example, during the setup and configuration process, several critical SharePoint services (including the timer service) will be configured to use the Farm Account as the identity under which they run. An example of how this account is often named is: domain\sp_farm_user

When running the Product Configuration Wizard, you will be asked to specify this account. The wizard will use the credentials you are logged in as (that is the Setup User Account) to give the Farm Account ownership of the Config database.

There are some exceptional cases where additional user accounts are needed when deploying SharePoint. For example, if specific SharePoint services require their own account for specific auditing and security purposes. For each SharePoint deployment accounts, there are some general best practices to consider:

All accounts should be Active Directory domain accounts, so that credentials, password expiry, and general user account management can be centralized. Local user accounts on the servers involved should not be used. This is especially important in the case of critical infrastructure like SharePoint.

Do not use personal accounts when deploying SharePoint. The Setup User Account becomes owner of the SharePoint farm. The Farm Account becomes dbowner of the SharePoint Config database. There are many places where the account, and its email address, get integrated into the farm. Ensure that you use a dedicated account for the Setup User Account in particular, so that the farm isn’t owned by your personal account which has privileges on other systems. In addition, personal accounts change if your role changes, so it is important that a personal user account is not left owning the SharePoint farm.

Configure one centralized email account for all managed service accounts—do not use a personal email address. The setup user account (and other service accounts) should have an email addresses reflecting that they are part of the SharePoint infrastructure. For example, assign all accounts the address “sharepointservice@company.com” as the email address in Active Directory. When SharePoint sends out periodic notifications related to server health and maintenance, with just one centralized email address, all notifications related to SharePoint will go to a single email inbox that can be monitored by the entire SharePoint team.

User account best practices are also covered in great depth in the Microsoft SharePoint 2013 Deployment Guide, which can be downloaded from here:

No comments:

Post a Comment

About Me

Antonio Maio is an information security architect with over 25 years of experience in cyber security practices and systems, product management, software development and leadership. Antonio is currently a Senior Manager and Senior SharePoint Architect with Protiviti. He has been awarded a Microsoft Most Valuable Professional award for 5 consecutive years, from 2012 to 2016, specializing in Microsoft SharePoint Server, Office 365 and Office Services. His background includes implementing cryptography and PKI systems, information security technologies, and both information governance and cybersecurity best practices. His experience with Microsoft SharePoint and Office 365 extends over the last 10 years. When he’s not helping enterprise, military or government organizations solve security challenges, you can catch him speaking at conferences or contributing to the community through this blog. In his spare time, Antonio likes to oil paint, run, make wine, read and spend time with his family.