The SQL Server Express 2008 setup allow you to assign different user account for each service.
SQL Server Express 2008安装程序允许您为每个服务分配不同的用户帐户。
For a development environment, would you use a domain user, local user, NT Authority\NETWORK SERCVICE, NT Authority\Local System or some other account and why?
对于开发环境，您会使用域用户，本地用户，NT Authority \ NETWORK SERCVICE，NT Authority \ Local System或其他一些帐户，为什么？
4 个解决方案
#1
33
Local System is not recommended, it is an administrator equivalent account and thus can lead to questionable coding that takes advantage of administrator privileges which would not be allowed in a production system since security conscious Admins/DBA's really don't like to run services as admin.
不建议使用本地系统，它是管理员等效帐户，因此可能导致可疑编码，利用管理员权限，这是生产系统中不允许的，因为安全意识管理员/ DBA真的不喜欢以管理员身份运行服务。
Depending on if the server instance will need to access other domain resources or not should determine which type of low privilege account it should run under.
根据服务器实例是否需要访问其他域资源，应确定应在哪个类型的低权限帐户下运行。
If it does not need to access any (non-anonymous) domain resources than I normally create a unique local, low privilege account for it to run under in order to gain the additional security benefit of not having multiple services running in the same identity context. Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services.
如果它不需要访问任何（非匿名）域资源，那么我通常会创建一个唯一的本地低权限帐户，以便在其下运行，以获得在同一身份上下文中不运行多个服务的额外安全性好处。请注意，SQL Server或SQL Server代理服务不支持本地服务帐户。
If it does need to access non-anonymous domain resources then you have three options:
如果它确实需要访问非匿名域资源，那么您有三个选项：
- Run as Network Service which is also a low privilege account but one that retains the computers network credentials.
- 作为网络服务运行，该服务也是低权限帐户，但保留计算机网络凭据。
- Run under a Local Service Account
- 在本地服务帐户下运行
- Run under a custom domain account with low local privileges. One advantage to running under the developers account is that it is easier to attach debuggers to processes in your own identity without compromising security so debugging is easier (since non-Admin accounts do not have the privilege to attach a debugger to another identities process by default). A disadvantage to using another domain account is the overhead of managing those accounts, especially since each service for each developer should ideally have unique credentials so you do not have any leaks if a developer were to leave.
- 在具有低本地权限的自定义域帐户下运行。在开发人员帐户下运行的一个优点是，更容易将调试程序附加到您自己身份中的进程而不会影响安全性，因此调试更容易（因为非管理员帐户没有权限默认情况下将调试程序附加到另一个身份进程）。使用其他域帐户的一个缺点是管理这些帐户的开销，特别是因为每个开发人员的每个服务理想情况下应该具有唯一的凭据，因此如果开发人员要离开，则不会有任何泄漏。
Most of what I tend to do does not require the service to access domain resources so I tend to use unique local low privilege accounts that I manage. I also run exclusively as a non-admin user (and have done so under XP SP2, Server 2003, Vista and Server 2008 with no major problems) so when I have cases where I need the service to access domain resources then I have no worries about using my own domain credentials (plus that way I don't have to worry the network admins about creating/maintaining a bunch of non-production domain identities).
我倾向于做的大部分内容不要求服务访问域资源，所以我倾向于使用我管理的唯一本地低权限帐户。我还专门作为非管理员用户运行（并且在XP SP2，Server 2003，Vista和Server 2008下都没有出现重大问题）所以当我遇到需要服务来访问域资源的情况时，我无后顾之忧关于使用我自己的域凭据（加上这种方式，我不必担心网络管理员有关创建/维护一堆非生产域身份）。
#2
14
It depends.
这取决于。
- Local System - Never, it's too high a privilege.
- 本地系统 - 从来没有，这是一个太高的特权。
- Network Service - Perhaps, if you need to connect to network resources, but that's doubtful.
- 网络服务 - 也许，如果您需要连接到网络资源，但这是值得怀疑的。
- Local Service - Probably the best choice, limited privileges, do not unlock network connections
- 本地服务 - 可能是最佳选择，有限权限，不解锁网络连接
- Local interactive user? Does it truly need to have login rights, or act as a user?
- 本地互动用户？它真的需要拥有登录权限，还是充当用户？
- Domain user? Goodness no, not unless you're accessing network drives from within it; if SQL runs amok then an attacker is authenticated against the domain.
- 域用户？善良不，除非您从其中访问网络驱动器;如果SQL运行困难，则攻击者将针对域进行身份验证。
#3
4
MS now has a good article on this: http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx
MS现在有一篇很好的文章：http：//msdn.microsoft.com/en-us/library/ms143504（v = sql.105）.aspx
They state that Local Service is not allowed for SQL Server Engine. Personally, I use Local System just to avoid issues during development, but in production, best practice is to create a domain level service account with just the permissions it needs to get the job done.
他们声明SQL Server Engine不允许使用本地服务。就个人而言，我使用本地系统只是为了避免在开发过程中出现问题，但在生产中，最佳做法是创建一个域级服务帐户，仅具有完成工作所需的权限。
#4
-3
Whatever it wants to use as default. Changing that is just asking for trouble later.
无论它想用什么作为默认值。改变这只是以后要求麻烦。
#1
33
Local System is not recommended, it is an administrator equivalent account and thus can lead to questionable coding that takes advantage of administrator privileges which would not be allowed in a production system since security conscious Admins/DBA's really don't like to run services as admin.
不建议使用本地系统，它是管理员等效帐户，因此可能导致可疑编码，利用管理员权限，这是生产系统中不允许的，因为安全意识管理员/ DBA真的不喜欢以管理员身份运行服务。
Depending on if the server instance will need to access other domain resources or not should determine which type of low privilege account it should run under.
根据服务器实例是否需要访问其他域资源，应确定应在哪个类型的低权限帐户下运行。
If it does not need to access any (non-anonymous) domain resources than I normally create a unique local, low privilege account for it to run under in order to gain the additional security benefit of not having multiple services running in the same identity context. Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services.
如果它不需要访问任何（非匿名）域资源，那么我通常会创建一个唯一的本地低权限帐户，以便在其下运行，以获得在同一身份上下文中不运行多个服务的额外安全性好处。请注意，SQL Server或SQL Server代理服务不支持本地服务帐户。
If it does need to access non-anonymous domain resources then you have three options:
如果它确实需要访问非匿名域资源，那么您有三个选项：
- Run as Network Service which is also a low privilege account but one that retains the computers network credentials.
- 作为网络服务运行，该服务也是低权限帐户，但保留计算机网络凭据。
- Run under a Local Service Account
- 在本地服务帐户下运行
- Run under a custom domain account with low local privileges. One advantage to running under the developers account is that it is easier to attach debuggers to processes in your own identity without compromising security so debugging is easier (since non-Admin accounts do not have the privilege to attach a debugger to another identities process by default). A disadvantage to using another domain account is the overhead of managing those accounts, especially since each service for each developer should ideally have unique credentials so you do not have any leaks if a developer were to leave.
- 在具有低本地权限的自定义域帐户下运行。在开发人员帐户下运行的一个优点是，更容易将调试程序附加到您自己身份中的进程而不会影响安全性，因此调试更容易（因为非管理员帐户没有权限默认情况下将调试程序附加到另一个身份进程）。使用其他域帐户的一个缺点是管理这些帐户的开销，特别是因为每个开发人员的每个服务理想情况下应该具有唯一的凭据，因此如果开发人员要离开，则不会有任何泄漏。
Most of what I tend to do does not require the service to access domain resources so I tend to use unique local low privilege accounts that I manage. I also run exclusively as a non-admin user (and have done so under XP SP2, Server 2003, Vista and Server 2008 with no major problems) so when I have cases where I need the service to access domain resources then I have no worries about using my own domain credentials (plus that way I don't have to worry the network admins about creating/maintaining a bunch of non-production domain identities).
我倾向于做的大部分内容不要求服务访问域资源，所以我倾向于使用我管理的唯一本地低权限帐户。我还专门作为非管理员用户运行（并且在XP SP2，Server 2003，Vista和Server 2008下都没有出现重大问题）所以当我遇到需要服务来访问域资源的情况时，我无后顾之忧关于使用我自己的域凭据（加上这种方式，我不必担心网络管理员有关创建/维护一堆非生产域身份）。
#2
14
It depends.
这取决于。
- Local System - Never, it's too high a privilege.
- 本地系统 - 从来没有，这是一个太高的特权。
- Network Service - Perhaps, if you need to connect to network resources, but that's doubtful.
- 网络服务 - 也许，如果您需要连接到网络资源，但这是值得怀疑的。
- Local Service - Probably the best choice, limited privileges, do not unlock network connections
- 本地服务 - 可能是最佳选择，有限权限，不解锁网络连接
- Local interactive user? Does it truly need to have login rights, or act as a user?
- 本地互动用户？它真的需要拥有登录权限，还是充当用户？
- Domain user? Goodness no, not unless you're accessing network drives from within it; if SQL runs amok then an attacker is authenticated against the domain.
- 域用户？善良不，除非您从其中访问网络驱动器;如果SQL运行困难，则攻击者将针对域进行身份验证。
#3
4
MS now has a good article on this: http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx
MS现在有一篇很好的文章：http：//msdn.microsoft.com/en-us/library/ms143504（v = sql.105）.aspx
They state that Local Service is not allowed for SQL Server Engine. Personally, I use Local System just to avoid issues during development, but in production, best practice is to create a domain level service account with just the permissions it needs to get the job done.
他们声明SQL Server Engine不允许使用本地服务。就个人而言，我使用本地系统只是为了避免在开发过程中出现问题，但在生产中，最佳做法是创建一个域级服务帐户，仅具有完成工作所需的权限。
#4
-3
Whatever it wants to use as default. Changing that is just asking for trouble later.
无论它想用什么作为默认值。改变这只是以后要求麻烦。