Microsoft Office Tutorials and References
In Depth Information
Local users and groups will be used to give users access to SharePoint in that scenario, rather than
going through a domain controller. You can still support incoming email in that scenario by enabling
SMTP in IIS and then setting it up in Central Administration.
It just goes to show that SharePoint is scalable down as well as up.
Setup Account (Complete Install) In a domain server farm install, the setup account
should be a domain admin (you can use local administrator accounts to install SharePoint
on each individual server, but it is easier simply to use one setup account that is a domain
admin). This account should be allowed to install SharePoint on any server in the domain,
and it must be able to access the SQL server that SharePoint will be using to build databases.
On the SQL server, the setup account must have these SQL server security roles on the target
SQL server: Login, SecurityAdmin, and DBCreator.
Farm Account Also known as the configuration database account , this account is powerful
and critical to SharePoint. It does not need to have administrative privileges, but it should
be a domain account. All other rights for this account will be configured automatically by
the setup account during installation. The setup account adds the farm account to the SQL
server’s Logins, DBCreator, and SecurityAdmin roles. This is why the farm account ends up
being the owner (DBO) of most of the SharePoint databases.
This account is the Central Administration application pool identity. This means that it is the
account that accesses and changes the configuration database for the server farm. It is also
the account used to power the SharePoint Timer service, which is in charge of any jobs that
need to be started and stopped at different times (such as getting incoming mail, managing
quotas, and managing alerts). This account should be guarded and not used for anything
else (except for the one rare occasion of setting up a super-admin account in PowerShell).
THE DBO EXCEPTION
Oddly enough, the farm account does not become the DBO of the configuration database for the
server farm, because the setup account creates that database during installation and then assigns
ownership of it to the database access account. This means that, by default, the setup account is the
DBO, but the farm account holds an owner role. This also means that, in a pinch, the setup account
can be used to do farm administration in PowerShell, if necessary.
Content Database Access Account Also known as the content database account , web
application account , or web application application pool account , this is the account that uses the content
database(s) of a web application. There should be one of these per web application—although
under some circumstances (as is the case in businesses with security policies that limit
service accounts), web applications can share an account. This account should be a domain user
and otherwise is given (and requires) database ownership of all content databases associated
with the web application it is working for.
If you are going to have more than one web application, you may want to consider creating a
content database access account for each of them. This helps give the account least privilege
(if it is compromised, it can only affect that web application; if it fails, it causes only one web
application to fail), and it is easier to troubleshoot if each web application has its own content