Права учетной записи программы установки ошибка sql
Устанавливаю SQL Server 2016 и обнаружил такую вещь, которую объяснить для себя пока никак не могу.
Инсталлятор SQL Server 2016 в ходе установки экземпляра настраивает в ОС ряд параметров, в том числе и параметры безопасности, для учётных записей, от имени которых будут работать службы SQL Server.
Однако несмотря на то, что в ходе установки в качестве учётных записей служб нами могут быть заданы определённые сервисные учётные записи (обычный доменный пользователь/ учётка MSA или gMSA), инсталлятор SQL Server выдаёт привилегии используемым по умолчанию виртуальным учётным записям (Virtual Account) вида NT Service\MSSQL& , NT Service\SQLAgent& и т.п., а не тем учётным записям которые мы указали.
В частности, если после установки SQL Server, мы проверим в консоли Local Security Policy (secpol.msc) в разделе Local Policies > User Rights Assignment назначения прав для учётных записей, например:
- Bypass traverse checking
- Adjust memory quotas for a process
- Replace a process level token
. то мы не уидим там наших учётных записей. Вместо них там будут присутсвовать NT Service\MSSQL& и NT Service\SQLAgent&
В тоже время в политике "Log on as a service" наши учётные записи есть.
Поясните пожалуйста, правильно ли я понимаю, что фактически поведение инсталлятора SQL Server 2016 ведёт к тому, что для наших сервисных учётных записей в системе неверно выдаются привилегии и нам требуется дополнительная ручная их корректировка?
Ответы
Нашёл интересную статью DBA Travis Gan, дающую некоторые разъяснения по моим вопросам в этом направлении: SQL Server Service Account and Per-Service SID
По итогам ознакомления с данной статьёй, тезисно могу сделать следующие выводы:
1) Механизм виртуальных аккаунтов для служб Windows предполагает создание виртуального имени вида NT Service\%Service% и локального идентификатора SID (per-service SID), связанного с этим именем. Такой виртуальный аккаунт по умолчанию создаётся для каждой службы и был введён в оборот для повышения безопасности и возможности гранулированной настройки прав доступа исполняемого процесса службы.
2) Виртуальный аккаунт для служб SQL Server DB Engine имеет имя формата "NT Service\MSSQLSERVER" для дефолтного инстанса или "NT Service\MSSQL$" для именованных инстансов и создаётся по умолчанию в современных версиях Windows Server на ровне со всеми другими службами. Активность этого аккаунта, а также его локальный SID можно узнать командой типа "sc showsid MSSQLSERVER" или "MSSQL$"
3) Инсталлятор SQL Server 2016 при развёртывании экземпляра в основном выдаёт в системе права именно для виртуального аккаунта службы "NT Service\MSSQLSERVER" (или "NT Service\MSSQL$"). Если в процессе установки для запуска службы SQL Server DB Engine указана выделенная сервисная учётная запись (обычный доменный пользователь/MSA/gMSA), то некоторые виды прав доступа могут быть выданы инсталлятором дополнительно к основному набору прав виртуального аккаунта для этой сервисной учётной записи. В качестве примера такой "смешанной" выдачи прав инсталляторо можно привести локальную политику "Log on as a service" (secpol.msc > Local Policies > User Rights Assignment).
4) В рамках локальной системы управлять правами доступа службы экземпляра SQL Server в разных ACL с одинаковым успехом можно и с помощью виртуального аккаунта службы и с помощью сервисной учётной записи . Если правильно понял Travis Gan, то предпочтительно управлять правами доступа (в рамках одной системы или кластера) именно используя виртуальный аккаунт. Практическая проверка SID виртуального аккаунта для кластеризованной службы SQL Server DB Engine на двух узлах кластера SQL Server показала, то что этот SID на двух разных системах . одинаковый . Таким образом, в рамках этого кластера управлять правами доступа можно с помощью этого виртуального аккаунта с таким же успехом, как и с помощью сервисной учётной записи. Если же речь идёт о каких-то разделяемых ресурсах вне рамок кластера, например, когда нужно дополнительно настроить права доступа к сетевому каталогу другом компьютере (например для резервного копирования на файловый сервер), то для назначения прав доступа конечно придётся использовать сервисную учётную запись (доменный пользоваитель/MSA/gMSA, от имени которой работает инстанс), которая одинаково будет работать на всех компьютерах домена.
Эта статья поможет вам решить проблему, возникаюную при установке или обновлении Microsoft SQL Server после ужесточения безопасности.
Применяется к: SQL Server
Симптомы
Рассмотрим сценарий, в котором вы Microsoft SQL Server в Windows. Чтобы усилить безопасность, необходимо удалить некоторые права пользователей по умолчанию из группы локальных администраторов. Чтобы настроить SQL Server в системе, добавьте учетную запись установки в группу локальных администраторов.
Эта проблема возникает SeSecurityPrivilege из SQL Server учетной записи установки не имеет разрешений на файловом сервере, на котором размещена сеть.
Причина
Если вы управляете установкой в качестве локального администратора, для успешного запуска необходимы следующие права пользователя:
Локальное имя объекта групповой политики | Право пользователя |
---|---|
Резервные файлы и каталоги | SeBackupPrivilege |
Программы отлаговки | SeDebugPrivilege |
Управление журналом аудита и безопасности | SeSecurityPrivilege |
Дополнительные сведения о разрешениях, необходимых для установки SQL Server, см. в разделе "Необходимые условия" в следующих статьях:
Если параметр хранения для каталога данных или других каталогов (каталог базы данных пользователей, каталог журналов баз данных пользователей, каталог TempDB, каталог журналов TempDB или каталог резервного копирования) использует файл SMB share, учетная запись Установки требует следующих дополнительных разрешений на сервере файлов SMB, как описано в install SQL Server с хранилищем SMB-файлового обмена файлами.
Папка sMB Network share | ПОЛНЫЙ КОНТРОЛЬ | SQL учетная запись установки |
---|---|---|
Папка sMB Network share | ПОЛНЫЙ КОНТРОЛЬ | SQL Server и SQL Server учетная запись службы агентов |
Сервер SMB File | SeSecurityPrivilege | SQL учетной записи установки |
Решение
Чтобы добавить права в учетную запись установки, выполните следующие действия:
Чтобы добавить учетную запись пользователя для программ отлаговки и управления политиками аудита и журналов безопасности, выполните шаги от 1 до 6 .
Часто задаваемые вопросы (часто задаваемые вопросы)
Почему на SeSecurityPrivilege файловом сервере требуется файл для резервного каталога в share UNC?
Это разрешение необходимо для получения списков управления доступом (ACLs) в каталоге резервного копирования по умолчанию, чтобы убедиться, что учетная запись SQL Server службы имеет полные разрешения на папку. Учетная запись службы также задает ALS, если отсутствуют разрешения для учетной записи SQL службы, чтобы можно было запустить резервное копирование каталога. Программа установки выполняет эти проверки для каталога резервного копирования по умолчанию, чтобы при выполнении резервного копирования после установки ошибки (из-за отсутствующих разрешений) не было.
SeSecurityPrivilege необходимо изменить каталоги get/set ACLs и подстановки. Это справедливо, даже если пользователи, у которых есть разрешения на get/set OWNER полный контроль в каталогах, не имеют разрешений на проверку и проверку сведений из каталога.
Почему ошибка, описанная в сценарии 3, возникает только в Microsoft SQL Server 2012 и более поздних версиях?
Начиная с SQL Server 2012 г. Корпорация Майкрософт предоставляет поддержку данных и файлов журналов в файле SMB-файла. В рамках этого улучшения повышается возможность установки для ужесточения проверок безопасности, чтобы клиенты не сталкивались с ошибками или ошибками из-за недостаточного количества разрешений после установки. В версиях SQL Server 2012 года пользователи по-прежнему могут настроить путь сетевого обмена для каталога резервного копирования, если у учетной записи службы SQL нет разрешений на выполнение резервного копирования. Однако в этой ситуации эти пользователи будут испытывать ошибку после установки. Эти сценарии теперь предотвращены при запуске проверки SQL 2012 г. на сетевой совместной основе.
Дополнительная информация
Чтобы проверить список привилегий, которые в настоящее время связаны с учетной записью установки, используйте AccessChk.exe . Чтобы скачать этот инструмент, см . в рубрике AccessChk v6.13.
Рассмотрим следующую ситуацию. Чтобы усилить безопасность, удалите некоторые права пользователей по умолчанию в группу локальных администраторов операционной системе Windows. В процессе подготовки к настройке Microsoft SQL Server на этом компьютере добавьте учетную запись для установки в группу локальных администраторов.
Отказано в доступе
2009-01-02 00:13:17 SQLEngine:--SqlServerServiceSCM: Ожидание событий nt «NIIT$ Global\sqlserverRecComplete» должен быть создан
2009-01-02 13:00:20 SQLEngine:--SqlServerServiceSCM: Ожидание событий nt «NIIT Global\sqlserverRecComplete$» или дескриптор процесса sql сигнала
2009-01-02 13:00:20 Slp: сбой действия конфигурации для функции SQL_Engine_Core_Inst во время ConfigRC и сценарий ConfigRC.
2009-01-02 13:00:20 Slp: доступ запрещен
2009-01-02 13:00:20 Slp: сбой действия конфигурации для функции SQL_Engine_Core_Inst во время ConfigRC и сценарий ConfigRC.
2009-01-02 13:00:20 Slp: в System.Diagnostics.ProcessManager.OpenProcess (Int32 processId, доступ Int32, Boolean throwIfExited)
2009-01-02 13:00:20 Slp: в System.Diagnostics.Process.GetProcessHandle (доступ к Int32, Boolean throwIfExited)
2009-01-02 13:00:20 Slp: в System.Diagnostics.Process.OpenProcessHandle()
2009-01-02 13:00:20 Slp: в System.Diagnostics.Process.get_Handle()
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlEngine.SqlServerServiceBase.WaitSqlServerStart (процесс processSql)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlEngine.SqlServerServiceSCM.StartSqlServer (String [] parameters)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlEngine.SqlServerStartup.StartSQLServerForInstall (строка sqlCollation, masterFullPath строка, логическое isConfiguringTemplateDBs)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.ConfigSQLServerSystemDatabases (EffectiveProperties свойства, логическое isConfiguringTemplateDBs, логическое useInstallInputs)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.DoCommonDBStartConfig (ConfigActionTiming время)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.Install (ConfigActionTiming времени, словарь "2 actionData, PublicConfigurationBase spcb)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlConfigBase.PrivateConfigurationBase.Execute (ConfigActionScenario сценарий, ConfigActionTiming времени, словарь "2 actionData, PublicConfigurationBase spcbCurrent)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlConfigBase.SqlFeatureConfigBase.Execute (ConfigActionScenario сценарий, ConfigActionTiming времени, словарь "2 actionData, PublicConfigurationBase spcbCurrent)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction (строка actionId)
2009-01-02 13:00:20 Slp: в Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.Execute (строка actionId, TextWriter errorStream)
2009-01-02 13:00:20 Slp: источник: системы.
2009-05-27 17:50:20 SQLEngine:: механизм проверки контрольной точки "GetSqlServerProcessHandle_1" 2009-05-27 17:50:20 SQLEngine:--SqlServerServiceSCM: Ожидание событий nt «Global\sqlserverRecComplete$ SQL10» в created2009-05-27 17:50:22 SQLEngine:-- SqlServerServiceSCM: Ожидание событий nt «Global\sqlserverRecComplete$ SQL10» или дескриптор процесса sql для signaled2009-05-27 17:50:22 SQLEngine:--FacetSqlEngineHealthCheck: Engine_SqlEngineHealthCheck: ошибка: доступ запрещен
Scenario3: Сбой установки Microsoft SQL Server 2012 или Microsoft SQL Server 2008 R2
Сбой правила «Настройка учетной записи права». Счет, на котором выполняется программа установки SQL Server не имеет одно или все следующие права: право архивировать файлы и каталоги, право на управление аудитом и журнал безопасности и право на отладку программ. Чтобы продолжить, воспользуйтесь учетной записью с обоих этих прав.
Учетную запись для установки SQL Server не имеет право SeSecurityPrivilege на сервере указанный файл в папке < расположение архива UNC >. Эта привилегия необходима в действие параметра безопасности папки программы установки SQL Server. Чтобы предоставить эту привилегию, добавить учетную запись для установки SQL Server в политику «Управление аудитом и журналом безопасности» с помощью консоли локальной политики безопасности на файловом сервере. Этот параметр доступен в разделе «Назначение прав пользователя» в разделе локальные политики в консоли локальной политики безопасности.
Примечание. Эта проблема возникает, так как учетная запись для установки SQL Server не имеет права SeSecurityPrivilege на файловом сервере, на котором размещается общий сетевой ресурс.
Причина
Данное поведение является особенностью. Помимо добавления учетной записи пользователя, на котором выполняется программа установки локального администратора, учетной записи пользователя программы установки требуются следующие права пользователя по умолчанию для успешного завершения установки.
This article helps you resolve a problem that occurs when you install or upgrade Microsoft SQL Server after you tighten security.
Applies to: SQL Server
Symptoms
Consider the scenario where you're running Microsoft SQL Server in Windows. To tighten security, you remove some default user rights from the local administrators group. To set up SQL Server on the system, you add the setup account to the local administrators group.
In this scenario, if you try to install or upgrade SQL Server, the installation process fails, and you might receive an error message that resembles one of the messages that are listed as follows:
Scenario 1: If a new installation fails, you receive the following error message:
You may also receive error messages that resemble the following in the Detail.txt file:
Scenario 2: If a new installation of Microsoft SQL Server 2012 or Microsoft SQL Server 2008 R2 fails, you receive one of the following error messages:
Scenario 3: If the installation of SQL Server 2012 or a later version fails when you specify a network share (UNC path) for the backup directory location, you receive the following error message:
This issue occurs because the SQL Server setup account doesn't have the SeSecurityPrivilege permissions on the file server that hosts the network share.
Cause
If you are running the setup as a local administrator, you require the following user rights for setup to run successfully:
Local Group Policy Object display name | User right |
---|---|
Backup files and directories | SeBackupPrivilege |
Debug Programs | SeDebugPrivilege |
Manage auditing and security log | SeSecurityPrivilege |
For more information about the permissions that are required to install SQL Server, see the "Prerequisites" section in the following articles:
If a storage option for data directory or other directories (user database directory, user database log directory, TempDB directory, TempDB log directory, or backup directory) uses SMB file share, the Setup account requires the following additional permissions on the SMB file server as described in Install SQL Server with SMB file share storage.
SMB Network share folder | FULL CONTROL | SQL Setup account |
---|---|---|
SMB Network share folder | FULL CONTROL | SQL Server and SQL Server Agent Service account |
SMB File server | SeSecurityPrivilege | SQL setup account |
Resolution
To add the rights to the setup account, follow these steps:
- Log on as an administrator.
- Select Start >Run, type Control admintools, and then select OK.
- Double-click Local Security Policy.
- In the Local Security Settings dialog box, select Local Policies, open User Rights Assignment, and then double-click Backup Files and Directories.
- In the Backup Files and Directories Properties dialog box, select Add User or Group.
- In the Select User or Groups dialog box, enter the user account that you want to use for setup, and then select OK two times.
To add the user account for the Debug Programs and Manage auditing and security log policies, perform steps 1 through 6 .
Frequently asked questions (FAQs)
Why is SeSecurityPrivilege required on the file server for the backup directory on the UNC share?
This permission is required to retrieve Access Control Lists (ACLs) on the default backup directory to make sure that the SQL Server service account has full permissions on the folder. The service account also sets the ACLs if permissions are missing for the SQL service account so that a backup of the directory can be run. The setup program runs these checks for the default backup directory so that if a backup is performed post-installation, you won't experience an error (because of missing permissions).
SeSecurityPrivilege is required to change the get/set ACLs from the directories and subfolders. This is true even if users who have FULL CONTROL permissions on the directories don't have permissions to get/set OWNER and audit information from the directory.
Why does the error that's described in scenario 3 occur only in Microsoft SQL Server 2012 and later versions?
Starting in SQL Server 2012, Microsoft provides support for data and log files on the SMB file share. As part of this improvement, the setup experience is further enhanced to tighten the security checks so that customers don't encounter errors or issues because of insufficient permissions post-installation. In pre-SQL Server 2012 versions, users can still set up the network share path for the backup directory if the SQL Service account doesn't have permissions to run a backup. However, those users will experience an error post-installation in this situation. These scenarios are now prevented when you start the SQL 2012 setup check on a network share.
More information
To check the list of privileges that are currently associated with the setup account, use the AccessChk.exe tool. To download this tool, see AccessChk v6.13.
Устанавливаю SQL Server 2016 и обнаружил такую вещь, которую объяснить для себя пока никак не могу.
Инсталлятор SQL Server 2016 в ходе установки экземпляра настраивает в ОС ряд параметров, в том числе и параметры безопасности, для учётных записей, от имени которых будут работать службы SQL Server.
Однако несмотря на то, что в ходе установки в качестве учётных записей служб нами могут быть заданы определённые сервисные учётные записи (обычный доменный пользователь/ учётка MSA или gMSA), инсталлятор SQL Server выдаёт привилегии используемым по умолчанию виртуальным учётным записям (Virtual Account) вида NT Service\MSSQL& , NT Service\SQLAgent& и т.п., а не тем учётным записям которые мы указали.
В частности, если после установки SQL Server, мы проверим в консоли Local Security Policy (secpol.msc) в разделе Local Policies > User Rights Assignment назначения прав для учётных записей, например:
- Bypass traverse checking
- Adjust memory quotas for a process
- Replace a process level token
. то мы не уидим там наших учётных записей. Вместо них там будут присутсвовать NT Service\MSSQL& и NT Service\SQLAgent&
В тоже время в политике "Log on as a service" наши учётные записи есть.
Поясните пожалуйста, правильно ли я понимаю, что фактически поведение инсталлятора SQL Server 2016 ведёт к тому, что для наших сервисных учётных записей в системе неверно выдаются привилегии и нам требуется дополнительная ручная их корректировка?
Ответы
Нашёл интересную статью DBA Travis Gan, дающую некоторые разъяснения по моим вопросам в этом направлении: SQL Server Service Account and Per-Service SID
По итогам ознакомления с данной статьёй, тезисно могу сделать следующие выводы:
1) Механизм виртуальных аккаунтов для служб Windows предполагает создание виртуального имени вида NT Service\%Service% и локального идентификатора SID (per-service SID), связанного с этим именем. Такой виртуальный аккаунт по умолчанию создаётся для каждой службы и был введён в оборот для повышения безопасности и возможности гранулированной настройки прав доступа исполняемого процесса службы.
2) Виртуальный аккаунт для служб SQL Server DB Engine имеет имя формата "NT Service\MSSQLSERVER" для дефолтного инстанса или "NT Service\MSSQL$" для именованных инстансов и создаётся по умолчанию в современных версиях Windows Server на ровне со всеми другими службами. Активность этого аккаунта, а также его локальный SID можно узнать командой типа "sc showsid MSSQLSERVER" или "MSSQL$"
3) Инсталлятор SQL Server 2016 при развёртывании экземпляра в основном выдаёт в системе права именно для виртуального аккаунта службы "NT Service\MSSQLSERVER" (или "NT Service\MSSQL$"). Если в процессе установки для запуска службы SQL Server DB Engine указана выделенная сервисная учётная запись (обычный доменный пользователь/MSA/gMSA), то некоторые виды прав доступа могут быть выданы инсталлятором дополнительно к основному набору прав виртуального аккаунта для этой сервисной учётной записи. В качестве примера такой "смешанной" выдачи прав инсталляторо можно привести локальную политику "Log on as a service" (secpol.msc > Local Policies > User Rights Assignment).
4) В рамках локальной системы управлять правами доступа службы экземпляра SQL Server в разных ACL с одинаковым успехом можно и с помощью виртуального аккаунта службы и с помощью сервисной учётной записи . Если правильно понял Travis Gan, то предпочтительно управлять правами доступа (в рамках одной системы или кластера) именно используя виртуальный аккаунт. Практическая проверка SID виртуального аккаунта для кластеризованной службы SQL Server DB Engine на двух узлах кластера SQL Server показала, то что этот SID на двух разных системах . одинаковый . Таким образом, в рамках этого кластера управлять правами доступа можно с помощью этого виртуального аккаунта с таким же успехом, как и с помощью сервисной учётной записи. Если же речь идёт о каких-то разделяемых ресурсах вне рамок кластера, например, когда нужно дополнительно настроить права доступа к сетевому каталогу другом компьютере (например для резервного копирования на файловый сервер), то для назначения прав доступа конечно придётся использовать сервисную учётную запись (доменный пользоваитель/MSA/gMSA, от имени которой работает инстанс), которая одинаково будет работать на всех компьютерах домена.
Читайте также: