Tengo una tarea programada (en el Programador de tareas de Windows) que se conecta a SQL Server usando SMO (Autenticación de Windows) y crea una copia de seguridad de la base de datos. Hasta ahora, esta tarea se estaba ejecutando bajo la cuenta de administrador y quería cambiarla para usar la cuenta SYSTEM en su lugar.
Cambié la tarea programada y, para mi gran sorpresa, funcionó de manera inmediata.
Me gustaría entender por qué este es el caso. El sistema es Windows Server 2012 R2 y la base de datos es SQL Server 2012 (SP1) Express Edition. Es una instalación estándar con un usuario de autenticación de SQL agregado.
En SSMS, estos son los inicios de sesión y sus roles de servidor asociados:
MS_PolicyEventProcessingLogin ## (deshabilitado)
MS_PolicyTsqlExecutionLogin ## (deshabilitado)
- MyServer \ Administrator (público, administrador del sistema)
- MySqlAuthUser (público)
- BUILTIN \ Usuarios (público)
- NT AUTHORITY \ SYSTEM (público)
- NT SERVICE \ MSSQLSERVER (público, administrador del sistema)
- NT SERVICE \ SQLWriter (public, sysadmin)
- NT SERVICE \ Winmgmt (público, administrador del sistema)
- sa (público, administrador de sistemas)
La base de datos tiene los siguientes usuarios y sus roles:
- MySqlAuthUser (Iniciar sesión MySqlAuthUser) (db_owner)
- dbo (Iniciar sesión sa) (db_owner)
- invitado (discapacitado)
- INFORMATION_SCHEMA (deshabilitado)
- sys (deshabilitado)
Ver los "permisos efectivos" del usuario NT AUTHORITY \ SYSTEM produce el siguiente resultado:
- ALTERAR CUALQUIER GRUPO DE DISPONIBILIDAD
- CONECTAR SQL
- CREAR GRUPO DE DISPONIBILIDAD
- VER CUALQUIER BASE DE DATOS
- VER ESTADO DEL SERVIDOR
¿Por qué NT AUTHORITY \ SYSTEM tiene permiso para hacer copias de seguridad de bases de datos? Me alegro de que así sea, pero realmente me gustaría entender por qué ...