Security on the farm: Accounts and permissions

In the tenth instalment of Robert Schifreen's SharePoint 2010 circumnavigation, he finds out what doesn't work as advertised, and begins to think hard about the security of his farm.

Sharepoint_config is SharePoint's most important database. It holds everything that the system needs to know about the farm configuration.

It's rather like the registry in Windows. Without sharepoint_config, your farm is irreparably broken. Therefore it seemed vital to me that, in a production service, we should use the full recovery model for sharepoint_config and back it up often.

However, I was wrong. From speaking to someone at a SharePoint Saturday event, it turns out that fixing a broken farm by restoring from a backup of sharepoint_config isn't actually supported by Microsoft and rarely works in practice.

So keeping meticulous backups of that database is, frankly, pointless. The only sensible way to fix a drastically broken farm is to rebuild it from your notes, then restore the backed-up content databases. It's discoveries like this that make me glad we have been putting in the time to find them out now rather than later.

Office Web Apps

One of Microsoft's much-heralded moves recently has been the transition of its Office apps from desktop-only to also being available online. Microsoft offers hosted Office in the form of Office 365 (presumably it takes a day off during leap years).

There's also been a great deal of publicity around the Office Web Apps (OWA) feature, which companies can host in-house to provide browser-based access to applications that closely resemble Word, Excel and PowerPoint.

What Microsoft doesn't always make clear is that you require SharePoint to deliver this, and that the feature isn't built into SharePoint out of the box but needs installing separately.

Installation is nowhere near as straightforward as you might expect for a product that Microsoft is trying to make a big splash about. It's certainly not all point and click.

You'll need PowerShell, for example, to configure all your SharePoint sites to make the feature available to users. The full installation document runs to around 15 pages, and the end result is not always a complete success if web forum postings (and my own experience) are anything to go by.

In my initial testing, the thing didn't work at all.

My first failure to make Office Web Apps work properly was, it turned out, down to a dodgy permission. The account under which I'd installed OWA didn't have full access to the SharePoint configuration database, mainly because no one had told me that it needed it.

Accounts and permissions

When you start building and running a SharePoint farm, you will come across dozens of seemingly unsolvable problems that turn out to be merely down to permissions.

When you start building and running a SharePoint farm, you will come across dozens of seemingly unsolvable problems that turn out to be merely down to permissions.

This situation is significantly hindered by Microsoft's recommendation that you use lots of different accounts for your SharePoint set-up. The account under which you first install SharePoint becomes the default all-powerful Farm Admin account. Best practice is then to use separate accounts for installing various underlying services, databases, and so on.

Needless to say, the error messages that arise when one account doesn't have the right permission to do what it's trying to do are brief at best and downright misleading at worst.

SharePoint does have a useful facility to help make it easier to use multiple accounts. It's known as Managed Accounts. Just add an account, plus its password, to the list of managed accounts and, from now on, you can just choose it from the list whenever it's required.

This is yet another of those features which, if you neglect to use it from the start, you'll spend the rest of your career wishing you had.

Security concerns 

The most tempting option, of course, is to forget best practice and just use one account for running all the SharePoint internal stuff. The upside is that things will work a little better, with fewer permission-related errors.

There are two downsides. First, if a hacker manages to penetrate the account he'll have access to the entire farm rather than just a half or a third of it. Secondly, splitting everything across multiple accounts can actually aid troubleshooting in some cases because, by glancing at the server's security log, the account that caused the problem will give you a clue as to why things are going wrong.

If you do choose to go down the single account route, bear two more things in mind. Firstly, for some inexplicable reason, perfectly sane people on the web often talk about creating an account called sp_farmadmin as the Farm Administrator account. I'm no advocate of security by obscurity, but something so obvious makes no sense whatever. Pick something totally innocuous that looks like just another user, so it won't excite any wannabe hacker if they hear it mentioned or see it written down.

Secondly, if the farm admin role is routinely going to be carried out by more than one person, give each person the necessary rights within their own account rather than allowing them all to use the generic farm admin account. It will keep your auditors happy, and helps to ensure that everyone in the admin team knows who did what (and that their actions can be traced back to them).

Next: Security gets more complex as we get closer to live data

Robert Schifreen has reported on and implemented online technology since the early 1980s. His latest project has been a large SharePoint 2010 installation in tertiary education. We will be serialising his experiences, positive and negative, in getting it to the stage where it's ready for action; the entire series will also be available as a downloadable white paper.