Securing your SharePoint Farm

I think there is a lot of confusion out there on just what a properly secured SharePoint farm is supposed to look like. Having seen lots of farms, hearing all the security concerns and building a bunch myself I've seen all levels of secure farms. Microsoft has taken great measures to document the steps for securing a SharePoint farm. The documentation has many, many pages and many, many links so I won't recreate all that work here. Just remember, SharePoint touches and is touched by a lot of the company infrastructure. Properly securing a farm is important and shouldn't be ignored. This is the best place to start your security adventure. https://technet.microsoft.com/en-us/library/hh377941.aspx I'm going to cover what permissions to give what groups of users in order to complete their daily jobs.

I can build my farm with one account but should I?

A respected member of the SharePoint users group here in Atlanta says it best "Microsoft has made their products too easy to install" It's very easy for me to stick a SharePoint CD in the drive and click next a bunch of times and in a few minutes I have a farm set up and running. I understand that in learning the product you have to start somewhere and a single account farm for development isn't such a bad thing. What I tend to see is a development farm gets used by a department somewhere to test something. Next thing you know, this farm is promoted to a production farm. Someone then builds a company intranet on your single account SharePoint farm. Then someone hires a consultant. The consultant comes in and you give him or her the password to your single account SharePoint farm (probably via email). When the consultant leaves you are too afraid to change the password of the single account SharePoint farm because you have no idea what may break. Remember, this is now a production farm.

Wow, that sounds like my situation, what do I do next?

If you have the resources, I suggest doing what you initially intended. Convert the farm you have back into a development farm and build a new production farm. Get all new service accounts. Create a new OU in active directory and call it something meaningful like "SharePoint accounts". I like to keep my SharePoint accounts grouped together. That way new admins and such know what they are. The table below is what I consider the minimum number of accounts needed. It actually corresponds with the accounts that the Autospinstaller project group uses for their installation scripts. Autospinstaller and Autospinstallergui are amazing projects and you should check them out. When filling out the xml file or web form, you will be interviewed and you provide the information needed.

Name	Description	Local Rights	Domain Rights	Notes
SP_Install	The server install account is used to perform the following tasks: -Setup -SharePoint Products Configuration Wizard	Local Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL Instance	Domain User	This account is the account you log into the machine with to start the installation. This account will provision the farm account.
SP_Farm	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.	SecurityAdmin and DB_Creator rights on the SQL Instance	Domain User	This account will be the farm account. this account by default should not have access to the hardware except to provision the UPS.
SP_Portal	The SP_Portal account is used to run the Web Application Pools.	None	Domain USer	This is for the web application that is added by default. You can use it for more than one web app or create more for each web app. Do not add too many or the server could bog down.
SP_MySite	The SP_MySite account is used to run the MySite application Pool	None	Domain User	Mysite app pool.
SP_Services	The Services Account is used to run the Service Application Pool	None	Domain User
SP_Crawl	The Default Content Access Account for the Search Service Application	None	Domain User
SP_Search	Service Account to run the SharePoint Search “Windows Service”	None	Domain User
SP_UserProfiles	The User Profile Synchronization Account	None	Replicate Directory Changes permission on the domain. http://technet.microsoft.com/en-us/library/hh296982.aspx
SP_CacheAdmin	Web application Policy Full Control. So items can be cached by ASP.Net to improve the performance	None	Domain User
SP_CacheReader	Web application Policy Read Control. So items can be cached by ASP.Net to improve the performance	None	Domain User

My farm is now secured, how do I keep it that way?

*All of the screen shots are for 2010 but the process is exactly the same in 2013 and 2016.

Good question! you might say "I still have to give the installation or farm password to my consultant to get something done." The methods I'm going to demonstrate are pretty easy to implement. The first thing to do is create a group in active directory where you will house your consultants. I called mine SharePoint_Consultants and I will add James Cragle to the group.



Next I have to decide what level of access the consultant needs. Do they need access to a site, site collection, web application, farm admin or PowerShell (Shell access)?

Web application: This access is an easy way to give access to all content. Log into central admin and add the group to User Policy for the web application.

• Log into central admin
• Select Manage web applications
• Highlight the web app you want to give access to
• Click the User Policy icon
• Click Add users
• Choose a zone (I usually leave it at all zones)

• Add the group and decide what level of permissions to give.

• The group now has permissions

This gives access to every element under that web application so make sure it's what you want. This access includes all site collections, sites, lists, workflows and documents.

Central Admin Access: You may want to assign a particular group of people to manage components of SharePoint, for example the User Profile Service. If you want to give your consultant group access to central admin, you add them to the farm admins group. Remember, this gives the group access just to central admin, not to content in web applications.

• Click on Security
• Choose Manage the farm administrators group
• Click New then Add Users



• Enter the group name and select OK

Shell Access: This is a little more involved. This requires the highly privileged SharePoint Install account to log into a SharePoint server and run a PowerShell command. Those of you familiar with scripting tools like JAMS can script these changes and push them so you don't need to log in. Shell access is given to individuals, not groups. You might be able to hack it to accept a group but is it worth the maintenance risk?

The script is a few simple lines.

• Log into SharePoint as the Install account
• Open SharePoint management shell
• To review a list of shell admins, type get-spshelladmin
• There might be users, there might not be.
• type in add-spshelladmin -UserName username
• User is now listed with shell access

• To remove shell access, type Remove-SPShellAdmin -UserName username

In conclusion, you can manage your farm a lot easier with AD groups. When it comes to security, we should all be diligent and understand what impact our changes have on the systems we maintain.

Forget me not, love is a Wiki Page

When i first started this post, i though "Why isnt anyone using gif to show the steps instead of individual images?" I see it now, sorry if the page makes you dizzy.

Sometimes the easy solutions are the ones that elude us. I was recently asked to take an Employee Handbook and make it available to all employees on the SharePoint Intranet portal. The handbook was a nice PDF document with all sorts of useful information like vacation policies, company holidays and who to call if there is an emergency. I placed the document in the HR department site, waited for the next crawl to run and made sure it was showing in search results. Job well done, time to kick back and relax with Diet Coke! About a week later the calls started to come in.

“Hey James, I cant find the policy on maternity leave.”
“Hey James, where is the policy on training?”
“Is there a policy on working from home?”

I went to SharePoint search and queried for those terms and it returned my Employee Handbook. I called my co-worker back and asked for more details. The problem he was having wasn't search being broken, it was usability. The co-worker says to me “If I search for the training policy, I shouldn't just be taken to the document but instead I should be taken to the content inside the document.” Now I understand the problem! The PDF wasn't going to cut it. How was I going to provide all this content, make it search-able, make it easy to locate specific details and make sure it's secure? Enter my dear old friend the Wiki Page. When it comes down to it, the Employee Handbook is just a collection of chapters and subjects. I can leverage these chapters and natural breaks for my new Employee Handbook. On the HR site, I created a new Wiki Page Library and I called it Employee Handbook.

The HR team is concerned about security and accountability of the content in the handbook. I will add content approval to the items in the library. This gives the HR team the ability to make changes to pages and it will require the content to be reviewed before it is made available to employees. This means I next have to alter the default security settings. I do this by

• Click on Page
• Click on Library Settings
• Click on Permissions for this document library
• Click on Stop Inheriting Permissions
• Add the HR Group with Contributor rights, everyone else with read only.

Now our permissions are set, but how is content to be updated? The next step is to set up versioning and content approval. Versioning allows us to make changes to a document and it acts like a draft. The draft can be altered as many times as needed until it is then committed as a published version. The content approval piece allows a final reviewers' approval before the item is available to all consumers.

• Click on Page
• Click on Library Settings
• Click on Versioning Settings
• Click Yes on require content approval for submitted items
• Click the radio button for “Create major and minor (draft) versions.
• Optionally select the maximum number of drafts and major versions to keep
• Optionally choose if the page needs to be checked out prior to editing.

Next we need to set up the approval process. We will use an out of the box workflow for this. (Make sure you have activated Workflows in your site collection features)

• Open library settings
• Click on Workflow Settings
• Add a workflow.
• Choose OOB (Out of the Box) workflow
• Assign a name and check the box to start when major version is published.
• You only need to add an “assigned to”. I also chose to add Request description.
• At the bottom, choose the Enable Content Approval check-box. When approval is granted, this will publish your page when approved.

When a page is created or modified, it will email the HR manager (Playing the role is me) and I can review the page and approve it. Now that the “plumbing” is done we can actually get to work creating our handbook. When I create a wiki library, a page called “how to use this library” is created and I recommend reading it. I won't go through content creation here because its already well written in the “How to use this library” section. Next I will walk through creating a page and approving the content.

• I have my Hours of Operation page staged. (see the page “How to use this library” to stage a page)
• Create the page.
• The information panel shows me that the file is currently a minor version (0.1) and that the page is checked in.
• I added my content and now I need the boss to approve it.
• I click Save and Publish.
• I fill in the required information and start the Workflow.
• The workflow will send an email asking for the item to be reviewed and to approve the content. At this point the document is waiting in a holding pattern.

Now the approver has their job to do.

• In Outlook, I receive an email alerting me to content that needs approval.
• Clicking the top line in the email takes me to the content.
• I review the changes and choose the “Publish” tab.
• From here, I can approve, reject or cancel the approval process. (I will approve)
• I can Add Comments if needed.
• I chose to require several levels of approval. This approval will be the final approval that goes out before the content is available to all consumers. If I had a department with multiple people I could assign this task to an HR VP for example. It's just me so I received the task to approve the changes. At this point I can review the page and request additional changes to be made or assign the task to another person. I will choose to approve the page as is.
• My content is now published, searchable and viewable to the entire company.

Now when I search, I get the exact page, a preview and the content I want to see and not some PDF document.

Starting a SharePoint Designer site WorkFlow from PowerShell

I had to schedule a SharePoint Designer site workflow with a “no code” solution. Normally, when I need to set a scheduled workflow I will create a SharePoint timer job and schedule it to run. The requirement for this particular client meant I couldn't add any SharePoint code. This ruled out using a SharePoint timer job. A search on the Internet yielded no results and no one already had a PowerShell script created so I wrote one.

 Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue
function start-siteworkflow{
Param(
[Parameter(Mandatory = $true, HelpMessage="Enter the Site URL that contains the site workflow")][string]$RootSite,
[Parameter(Mandatory = $true,HelpMessage="Enter the name of the site workflow")][string]$workFlowName,
[Parameter(Mandatory = $false, HelpMessage="Leave Blank")][AllowEmptyString()][string]$location


)
$site = get-spsite $RootSite
$web = $site.OpenWeb()
$assoc = $web.WorkflowAssociations.GetAssociationByName($workFlowName, [CultureInfo]::'InvariantCulture')
$params = [xml]""

$site.WorkFlowManager.StartWorkflow($location, $assoc, $params, 'Asynchronous')

}


start-siteworkflow 

The script requires two parameters, the root site where the workflow is saved and the name of the workflow. There is a third parameter that is not mandatory and is only there to send a Null to the StartWorkflow method. When the script is run, if that is missing the workflow will fail. start-siteworkflow -RootSite http://site -workFlowName “Workflow Name” The workflow will run with the SharePoint Timer service which is usually within 5 minutes. Enjoy!