У мене є заплановане завдання (у Windows Task Scheduler), яке підключається до SQL Server за допомогою SMO (Windows Authentication) та створює резервну копію бази даних. Поки це завдання працювало під обліковим записом адміністратора, і я хотів змінити його, щоб замість цього використовувати обліковий запис SYSTEM.
Я змінив заплановане завдання і, на моє повне здивування, воно вийшло нестандартно.
Я хотів би зрозуміти, чому це так. Система - Windows Server 2012 R2, а база даних - SQL Server 2012 (SP1) Express Edition. Це стандартна установка з доданим одним користувачем SQL Auth.
У SSMS це входи в систему та пов'язані з ними ролі сервера:
MS_PolicyEventProcessingLogin ## (вимкнено)
MS_PolicyTsqlExecutionLogin ## (вимкнено)
- MyServer \ Administrator (загальнодоступний, sysadmin)
- MySqlAuthUser (загальнодоступний)
- BUILTIN \ Користувачі (загальнодоступні)
- NT AUTHORITY \ SYSTEM (загальнодоступний)
- NT SERVICE \ MSSQLSERVER (public, sysadmin)
- NT SERVICE \ SQLWriter (public, sysadmin)
- NT SERVICE \ Winmgmt (public, sysadmin)
- sa (public, sysadmin)
Сама база даних має таких користувачів та їх ролі:
- MySqlAuthUser (Вхід MySqlAuthUser) (db_owner)
- dbo (Вхід sa) (db_owner)
- гість (інвалід)
- INFORMATION_SCHEMA (вимкнено)
- sys (відключено)
Перегляд "ефективних дозволів" користувача NT AUTHORITY \ SYSTEM дає такий результат:
- ВСІМ ГРУПІ НАЛИЧНОСТІ
- ПІДКЛЮЧИТИ SQL
- СТВОРИТИ ГРУПУ ДОСТУПНОСТІ
- ГОЛОВНУЙТЕ БУДЬ-ЯКІ ДАНІ
- ПОГЛЯД ДЛЯ СЕРВЕРА
Чому NT AUTHORITY \ SYSTEM має дозвіл на резервне копіювання баз даних? Я радий, що це так, але мені б дуже хотілося зрозуміти, чому ...