I’ve been getting a lot of questions on Twitter and during my netcast about permissions. People seem to really be taking security seriously these days. It seems gone are the days of installing SharePoint as a domain administrator, running everything as domain administrator and logging in as domain administrator to administrate SharePoint. I think this is a great move, and I’ll admit to slacking a little when I install and demo SharePoint 2010. I normally do everything as sp_install or sp_farm (service account explanation) because that’s easiest. Of course that’s horrible idea, and I do feel suitably ashamed of myself. I was asked about this during a netcast a couple of weeks ago, and again in a comment on my blog this week. I decided to break down and go through the process of setting up an account you can use to administrate your SharePoint 2010 without leaning on the sp_farm crutch. Here we go.
Create the account
The first step is to create the account in active directory. Do NOT use your regular user. You don’t want to accidently delete something in SharePoint because it’s available logged in as an admin user. Also, having a non privileged account makes it possible for you to see problems the same way a regular user would. It’s also a good idea for your admin account to have a different password than your regular account. I know, I know, having another username and password to remember sucks. I feel your pain. You’ll be a better person for it though.
My normal account is contoso\todd, and I created contoso\todd_admin for this exercise. I didn’t do anything special in ADUC or give it an elevated permissions. I put the account’s description in all capital letters so it would stick out. It looks like this in ADUC:
One of the companies I used to work at used this convention and I liked it so much I stole it for my very own.
Giving it permissions
Now that the account is created, let’s start giving it some permissions. Before we do that though, let’s verify what works and what doesn’t. I was able to log into my SharePoint servers without any changes, but I couldn’t do anything to SharePoint once I got in there. Here’s what happened when I try to run the SharePoint Management Console:
If I try to sneak into Central Admin I’m greeted warmly with this:
So we know this account really doesn’t have the permissions to do anything. Since we’re already in Central Admin let’s log in as a privileged user and take care of it first. The first step we need to take is to add our todd_admin account to the Farm Administrators group. In Central Admin this is under Security > Manage the farm administrators group. Central Admin is just a site collection, and all we’re doing is giving our todd_admin account permission to log into it. It looks like this:
No need to send yourself an email, you already know you’re in there. Now if you try to get into Central Admin as your admin account you get this:
Hurray! We’re almost there. You will find that while most of Central Admin is available to you, a few things still won’t work, like creating a new web application or service application. I’ll cover that later.
While getting into Central Admin is fun, we still can’t get in to where the real fun is, PowerShell. The key to fixing this is the PowerShell cmdlet Add-SPShellAdmin. This cmdlet does a couple of things. First, it adds our admin account to a database role (SharePoint_Shell_Access) that gives us permission to do things that require changes to the database. It also adds our account to a local group (WSS_ADMIN_WPG) on the SharePoint server to give us permissions to make changes there too. Because of that granularity you have to run Add-SPShellAdmin against every database you want it to change, and on all of your SharePoint servers. To meet the first requirement, and to show off a little, I used Get-SPDatabase to get all the databases in my farm, and then I piped it through Add-SPShellAdmin. It looks something like this:
That didn’t go well, did it? Like I said before, Add-SPShellAdmin makes changes to each database’s permissions, so the account you run it as has to have permission to do that. Even though sp_install has the securityadmin role on the SQL server, it doesn’t have permission to change this security. Before you run Add-SPShellAdmin make sure the account running it (in my case sp_install) either is in the db_owner group on each databsae, or is in the sysadmin role in SQL. I added sp_install to the sysadmin role and ran my command again:
Like they say, no news is good news. To verify it really worked I checked the local machine permissions and the database permissions. Local machine:
Good, good. Now SQL.
Yup, I’m there too. Let’s fire up PowerShell and see if I have any better luck.
I think that counts as a win.
From my screenshots you might think it’s all fixed and that nothing stands in the way of contoso\todd_admin and pure SharePoint administrative bliss. We’re close, we’re really, really close. There are a couple of stumbling blocks though. For instance, I still can’t create web applications or service applications. The option is just greyed out. Also, firing up Central Admin on the server or firing up PowerShell is problematic because they require the administrative token to open up, and todd_admin doesn’t have that. I was able to open Central Admin from my workstation (and let’s be honest, that’s probably where you should be doing it anyway) and I assume PowerShell remoting would have worked, but I didn’t try it. To get those last two pieces to work correctly I had to put todd_admin in the local admin group. I’m not proud of that, but it worked. Again, that was only necessary for that account to create new web apps and service apps, and to access PowerShell and Central Admin locally on the server.
There you have it. Now you know how to make a dedicated SharePoint admin account and you can stop logging in as sp_farm and sp_install.
tk
shorturl: https://www.toddklindt.com/StopUsingSPFarm