Cuenta de servicio de SQL Server Privilegios y derechos de Windows

Mi pregunta es, si crea una nueva cuenta de usuario de dominio para cada uno de los procesos de SQL Server, ¿qué permisos deben establecerse para cada cuenta? ¿O el administrador de configuración de SQL realmente se encarga de esto y acabo de tener un problema imprevisto?

A menudo tengo que configurar Microsoft SQL Server y me pregunto si alguien puede proporcionar consejos sobre cómo configurar las cuentas en las que los servicios deberían ejecutarse. En mi opinión, esto ha sido vagamente documentado por Microsoft, mientras te señalan en la dirección correcta, nunca he podido encontrar ningún ejemplo concreto.

Para resumir lo que he visto hasta ahora:

Para implementaciones simples \ entornos de desarrollo, está bien usar los valores predeterminados de la cuenta virtual que usa el instalador: por ejemplo NT SERVICE\MSSQLSERVER

Evite usar la SYSTEMcuenta, esto no es seguro.

Para producción y en entornos de dominio, se recomienda utilizar una cuenta de servicio administrado o crear una cuenta de usuario de dominio (no un administrador) para cada servicio. Supuestamente, si usa una cuenta de dominio en el momento de la instalación, el instalador establecerá los permisos necesarios para usted.

Si cambia la cuenta de servicio en una instalación existente de una cuenta virtual a una cuenta de dominio, la recomendación es usar el administrador de configuración de SQL Server para configurar las nuevas cuentas de servicio. Supuestamente, esto establecerá los permisos necesarios para usted.

Acabo de intentar cambiar la cuenta de servicio en una instalación existente a una cuenta de dominio y me daría un error de inicio de sesión hasta que otorgue el log on as servicepermiso de la cuenta , lo que contradice la parte en la que el administrador de configuración de SQL Server establecerá los permisos necesarios. (Aunque no estoy seguro de si un GPO puede haber interferido con la configuración de esta política de seguridad local)

Microsoft proporciona una lista de los permisos que otorga la instalación de SQL Server en esta página .

Pero no me queda claro si eso es algo que debería hacer manualmente para que el usuario que creo ejecute el servicio, o si usar el administrador de configuración de SQL debería establecer automáticamente estos permisos.

SQL Server 2014, el controlador de dominio está en Windows Server 2008 R2.

A menudo tengo que configurar MS SQL Server y me pregunto si alguien puede dar consejos sobre cómo configurar las cuentas en las que los servicios deberían ejecutarse. En mi opinión, esto ha sido vagamente documentado por Microsoft, mientras te señalan en la dirección correcta, nunca he podido encontrar ningún ejemplo concreto.

En realidad, está bastante documentado: http://msdn.microsoft.com/en-us/library/ms143504.aspx

¿Hay alguna parte de eso de la que no estés seguro?

Para implementaciones simples \ entornos de desarrollo, está bien usar los valores predeterminados de la cuenta virtual que usa el instalador: por ejemplo, NT SERVICE \ MSSQLSERVER

Esto va a depender del medio ambiente. Personalmente, odio encontrar un servidor que alguien configure usando una cuenta local y pedir tener acceso a los recursos de la red en algún momento en el futuro, entre otros problemas.

Para producción y en entornos de dominio, se recomienda utilizar una cuenta de servicio administrado o crear una cuenta de usuario de dominio (no un administrador) para cada servicio.

De nuevo, depende, pero en general estaría de acuerdo (un ejemplo contrario sería grupos de disponibilidad en los que tiene sentido usar una sola cuenta de dominio en todas las instancias).

Supuestamente, si usa una cuenta de dominio en el momento de la instalación, el instalador establecerá los permisos necesarios para usted.

A menos que haya una falla, etc., lo hará. No estoy seguro de por qué la parte "Supuestamente".

Si cambia la cuenta de servicio en una instalación existente de una cuenta virtual a una cuenta de dominio, la recomendación es usar el administrador de configuración de SQL Server para configurar las nuevas cuentas de servicio. Supuestamente, esto establecerá los permisos necesarios para usted.

Al cambiar cualquiera de los servicios para SQL Server, use siempre SSCM. Siempre. Período. Establecerá los permisos para la nueva cuenta en lo básico. Si antes se usaba la cuenta del sistema local y se tenía un permiso sin restricciones para todo el sistema, esperaría que algo fallara en los permisos después del cambio debido a una seguridad controlada más estricta. Eso no es un error de SQL Server SSCM, es un error de administrador de no otorgar permisos EXTRA adecuados (como acceder a un recurso compartido de red, carpetas restringidas, elementos fuera del ámbito de instalación de SQL Server, etc.)

Acabo de intentar cambiar la cuenta de servicio en una instalación existente a una cuenta de dominio y me daría un error de inicio de sesión hasta que otorgue el permiso de 'iniciar sesión como servicio' de la cuenta, lo que contradice la parte donde el administrador de configuración de SQL Server establecerá cualquier requisito permisos (Aunque no estoy seguro de si un GPO puede haber interferido con la configuración de esta política de seguridad local)

Parece que un GPO está causando un problema (en mi humilde opinión). No sería la primera vez :)

Entonces, mi pregunta es, si crea una nueva cuenta de usuario de dominio para cada uno de los procesos de SQL Server, ¿qué permisos deben establecerse para cada cuenta?

Establecería explícitamente cualquier permiso fuera de los establecidos en el enlace msdn que tengo arriba (también dado por @joeqwerty y en su OP). Por ejemplo, en una carpeta de "copia de seguridad" en un recurso compartido de red, en una nueva unidad agregada para contener nuevas bases de datos (donde la configuración ya se ejecutó pero la unidad no existía), etc.

Pero no me queda claro si eso es algo que debería hacer manualmente para que el usuario que creo ejecute el servicio, o si usar el administrador de configuración de SQL debería establecer automáticamente estos permisos.

A menos que algo esté extremadamente roto con el servidor, no debería tener que darse manualmente.