Netwrix recognized in Gartner's 2020 Market Guide for File Analysis Software
Microsoft SharePoint is the premier information management and sharing platform. It provides organizations with the information management, collaboration, workflow and data integration capabilities they need to drive their business forward. However, in order to be effective, the SharePoint solution has to be properly configured and secured. Here are the SharePoint best practices that will help you to achieve these goals and get the most from your investment.
Design your farm architecture well
Here are the primary factors to consider when deciding on a farm architecture:
SharePoint Server can represent a significant monetary cost. Hardware requirements are on the upper end of many document management systems. Each SharePoint Server must be licensed, along with each SharePoint user. Plus, since SharePoint Server does not support SQL Express, you’ll need to pay for a licensed edition of SQL Server.
Maintaining a highly available SharePoint farm also involves ongoing operational costs. The more servers and services there are to manage, the more expensive the farm becomes over time.
What services are provisioned on the farm will also impact costs and performance. If your farm has over 500 million items to crawl, you’ll need to provision a new Search Service application. If you have multiple Search Service applications, you might need to provision additional SharePoint servers to handle the load.
Use network load balancers with your SharePoint site if it is heavy loaded
Network load balancers are essential to high availability of SharePoint for your end users. One feature to pay attention to is SSL Offloading. Although many load balancers offer it, you should avoid using it whenever possible because it removes the encryption on the load balancer and sends the resulting request in clear text to the target services, such as SharePoint. Moreover, SSL Offloading no longer provides an advantage in performance in terms of CPU utilization on a server with a modern AMD or Intel processor.
Define a proper topology for your SharePoint farm
Here are the most common SharePoint topology strategies:
With this configuration, you can maintain availability even if any one particular role suffers a single SharePoint Server failure or there are multiple server failures across roles. If you use shared MinRole, you need only four servers.
Configure the SharePoint Server BIOS properly to improve performance
Making a few changes to your server before you install SQL Server and SharePoint can improve its performance:
Understand SharePoint web architecture
A SharePoint environment has three different site levels: web applications, site collections and webs (sites and subsites). The first two are actually simply containers that do not store any content directly; all content is stored in the webs.
Web applications can be created only by SharePoint administrators who have Farm Administrator privileges as well as Local Administrator permissions on the SharePoint Server. Creating a web application will create a new site in IIS on every server running the Microsoft SharePoint Foundation Web Application service, as well as a new database in SQL. While two SharePoint web applications can be hosted in the same IIS application pool, they cannot have the same URL or be hosted in the same database. A web application can have one or more content databases attached to it. All the site collections created in that web application will go to one of those content databases.
Every web application needs to have a root site collection, which is the site collection with the same URL as the web application. This is not created automatically, but is a requirement for supportability and stability of your SharePoint system. A site collection can be placed into its own content database, and can be moved between content databases that are attached in the same web application.
Under the site collection, we find webs. Those webs can either be at the root of the site collection, meaning they have the same URL as the site collection, or they can be a subsite of the root web. Those webs cannot be moved to a different content database individually; they all reside in the same site collection container.
Use object cache account to improve rendering speeds
SharePoint publishing sites use two Object Cache Accounts to improve page rendering speeds on publishing pages, and reduce load on the SQL Server. Those accounts are often referred to Portal Super User and Portal Super Reader accounts. The Portal Super User account will have Full Control on the Web Application, while the Portal Super Reader account will only have Full Read on the Web Application. SharePoint will use those cache accounts, to create two versions of the object cache, one with the Portal Super Reader account, which will only see published items, and one with the Portal Super User account, which will see both published items and drafts. When a user queries a publishing page, the object cache will check that user’s permissions, and will return the appropriate cached object depending if he can see draft items or not. The Object Cache accounts are only needed for Web Applications that will run publishing sites, but there is no harm in setting them on all your Web Applications.
Implement high availability for SharePoint
Farms must have a 99% 1 ms round-trip time on average over 10 minutes; otherwise, you might encounter object synchronization issues, including timer job failures. Farms also must have 1 Gbps connectivity between all farm members and SQL servers that are serving the farm in a read-write capacity or are in a synchronous form of replication with the read-write SQL Server. In practice, this means that each farm member or SQL Server in synchronous replica mode must be within a radius of approximately 186 miles (300 km).
Create a disaster recovery plan for your SharePoint site
Here are the disaster recovery options for the SQL Server databases supporting your SharePoint farm:
Use the SharePoint Recycle Bin
SharePoint includes a Recycle Bin that can be used to review and, if necessary, restore items previously deleted from SharePoint. Items that can be restored include documents, list items, document libraries, lists, folders and sites. Deleted items are placed in the Recycle Bin for the number of days defined by the SharePoint administrator. The SharePoint Recycle Bin has two levels of functionality:
Define your site’s taxonomy
Choose a set of naming rules to use on your site. Be clear and consistent; by looking at the names of subsites, menu options and other things, users should immediately understand what's in front of them. If these titles are misleading, users can get lost on the site regardless of their experience. Similarly, parallel content should share naming conventions. If the intranet gives a user the same options on separate pages, the taxonomy should be the same. If separate pages have identical sub-pages, the naming conventions should be similar.
Monitor and maintain your SharePoint regularly
SharePoint Server can be monitored with a variety of logs and tools, including the following:
Use SharePoint document versioning
Enable document versioning to store a complete version history that allows users to track document changes and restore previous versions if required. You should limit how many major and minor versions are to be kept to control storage use. 10 major and 10 minor versions is often a good choice.
Tag Content with Metadata
Metadata is very useful for all content on your SharePoint site. When you add metadata to site content, you give it tags that indicate its content and value. When you use metadata in your SharePoint lists and libraries, your site’s information is much easier to find and interact with. SharePoint offers some default tags, called terms. You can also create new terms to better suit your purposes.
Disable insecure transport security protocols
SharePoint Server 2016 introduced support for Transport Layer Security (TLS) 1.2. It is highly recommended to disable previous protocols, including Secure Socket Layer (SSL) 3.0, TLS 1.0, and TLS 1.1. TLS encrypts data as it is sent between services or between the end user and services, which helps protect sensitive data in transit over the network.
Use Kerberos or SAML for authentication
Kerberos is a modern authentication protocol that is used in every Active Directory implementation. Instead of passing password hashes to and from services, Kerberos passes tickets. Tickets are created upon user login to the client machine by Ticket Granting Service (TGS) and are retrieved from the Kerberos Distribution Center (KDC), which is an Active Directory domain controller. When a user makes a request to an external sharing service, such as SharePoint, the user’s ticket is sent to the target service for validation. In a mutual authentication scenario, the service sends information back to the client confirming the identity of the service. Each ticket has a specific lifetime, but it is generally long enough that users do not have to reauthenticate to the KDC to get a new ticket.
Security Assertion Markup Language (SAML) is a modern form of authentication that presents claims about a user to a service. Based on the identity claim contained in the SAML assertion, the service will authorize the user to the service. SAML is a favorite with modern services due to its ability to federate with disparate services that do not have a dependency on the authentication service the user authenticates with. For example, a user might authenticate against a local Active Directory Federation Services server using NTLM or Kerberos, and due to federation, assert their identity to a SharePoint farm running within a separate organization. Based on rules within the federation trust, SharePoint will authorize the user to have access to SharePoint resources. This configuration is significantly easier to manage than an Active Directory forest trust over the internet.
Patch your SharePoint servers regularly
Patching SharePoint is vital for its security and functionality, since as soon as you install the latest updates, you are secure from the latest known exploits. To upgrade a farm without taking it offline, you need to use “highly available upgrades” functionality that takes only one server in a farm offline at a time.
Track changes to your SharePoint sites
Every change to the configuration of your SharePoint farm should be documented and logged, and it is recommended to log all content changes as well. In order to configure content auditing in a SharePoint site, refer to our SharePoint auditing how-to’s and SharePoint Auditing Quick Reference Guide.
Identify and classify the data you store in SharePoint
To properly protect the data on your SharePoint, you need to identify all valuable assets stored there, such as health service numbers and credit card numbers, and classify them using data classification best practices. For this purpose, you can use third-party tools like Netwrix Data Classification. The data discovery and classification process will help you limit access permissions in accordance with principle of least privilege. It can also help you identify stale data on your SharePoint site so you can archive or delete it.
Manage site security properly
Site owners are responsible for assigning rights to users within their own sites. Rights can be assigned either directly to a user or to a group that users (or other groups) are members of. Security must be configured for every root site within SharePoint. When a new root site is created, the user who created it will specify the site collection administrators for the site, and by default, those individuals will be the only people with access to the new site. These site collection administrators will then identify the users who are to be granted rights to the site and provide them with the appropriate levels of user access.
Subsites will either inherit their rights from the site in which they are contained or have unique permissions, as determined by the permission settings configured within the subsite. If security for a subsite is configured to be inherited from the parent site, security is not managed for the site directly; instead, security will be based on rights assigned in the parent site. If security for the subsite is configured to be unique, a site administrator will be required to assign the appropriate rights to individuals needing limited access to the site.
When you create your own site, it is important to understand the security needs of the individuals who will be using SharePoint and assign them the appropriate permissions to work with materials in the site. To better understand SharePoint permissions and permission inheritance, please refer to this guide.
Following these configuration and security best practices will help you keep your Microsoft SharePoint environment highly available and secure, driving adoption and enabling you to make the most of your investment in the collaboration platform.
