I have been asked this question a lot lately so I thought I would throw something up. Now I can tell you I am not in love with writing this yet because 2010 RTM is still fresh on the streets and I am never happy until I have at least 50 clients running 2010 farms to get a feel for what is really going on. But Shane you have been using the early builds forever why don’t you have this all worked out? Because until the bits went RTM some of the account issues were touch and go so I used test farms with one account way too often. It was a crutch but got me through those early builds. So get over it.
Now when I was first asked the question I did the responsible thing and started asking questions of people that were smarter and to be honest better looking than me if they had any ideas. Unfortunately none of them did so I then I asked Todd who had actually also been talking to Spence about said topic. (For the record neither of them is better looking than me.) They had some input that went along with what I was thinking. I also got real crazy and read the TechNet article on Account Permissions. While it looks really good it is way too detailed and most of you aren’t going to read it. So here is what I am doing these days.
- Running setup.exe/farm configuration wizard(grey wizard) – In 2007 this account was crucial for you to get correct. You needed a dedicated account. In 2010 this is not as important thanks to the introduction of the passphrase. The key thing about this account is it must be a domain user and a local administrator on all of your SharePoint servers. For the SQL Server it needs the SQL roles of securityadmin and dbcreator. It does not need to be a domain administrator and it does not need to be a SQL server administrator. This account could be your account but I still like to defer to my 2007 style and create a dedicated sp_admin type account for this.
- When you get to this screen:
You need to specify what we call the farm account. I like to use domain\sp_farm but you can do as you like. This account needs to just be a regular domain user. This account for right now doesn’t need any other access. SharePoint will use the install account you are logged in with to make this account a member of some local server groups and give it the dbcreator and securityadmin SQL roles. This account is then used as the central administration application pool account and the SharePoint timer service. Now something to keep in mind. If you are going to configure profile imports read my last blog article, this account has to be a local administrator on the SharePoint server when you provision the service and needs some weird AD permissions to get your started. Akward.
- When Central Admin opens for the first time you will probably use the initial farm configuration wizard (white wizard) and you will be prompted to setup a managed account as shown here.
This account will be the default account for the different service applications and will be the identity of the service applications app pool account. This account is just a regular domain user with nothing special for you to do.
- Now when you create your first web application you will need to create a new application pool. I recommend that when you do this you create a dedicated account for your application pool. Every unique app pool I create I always use a unique account. This account is just a regular domain user. SharePoint will give it the permissions it needs.
- When you start to configure your Search service application you should change the default content access account, you do this from the manage service applications screen and click on the search service app you want to change. By default it will be the account you used in step 3. What you want is to change it to a dedicated account that has read, and ONLY READ access, to all of the content you want to crawl. If you don’t you will end up with trash in your index you don’t want.
- In the same train of thought when you configure your user profile service application connection you will need to specify an account. This account will need some funky AD rights so using a dedicated account isn’t a bad idea.
That should be more than enough to build a decently segregated farm from an account perspective. Some people will use less some more so take this for what it is.
One struggle people run into when they do least privilege type installs is they struggle how to get Windows PowerShell to work properly. They do cmdlets like get-spsite and get weird access denied responses. The reason is a lack of rights in SQL Server. Instead of me telling you how to get those rights I will give you a link to Zach’s post on the topic. It is a quick read and will make your life easier.
Anyway, I hope that helps. If you have any feedback let me know. I am sure I will insult someone with my over simplicity of this post. Or I missed something simple.
Shane – SharePoint Consulting