none
Раздача прав сервисным учётным записям при установке SQL Server 2016 RRS feed

  • Вопрос

  • Здравствуйте.

    Устанавливаю 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 ведёт к тому, что для наших сервисных учётных записей в системе неверно выдаются привилегии и нам требуется дополнительная ручная их корректировка?

    30 сентября 2018 г. 6:06

Ответы

  • Нашёл интересную статью 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$<InstanceName>" для именованных инстансов и создаётся по умолчанию в современных версиях Windows Server на ровне со всеми другими службами. Активность этого аккаунта, а также его локальный SID можно узнать командой типа "sc showsid MSSQLSERVER" или "MSSQL$<InstanceName>"  

    3) Инсталлятор SQL Server 2016 при развёртывании экземпляра в основном выдаёт в системе права именно для виртуального аккаунта службы "NT Service\MSSQLSERVER" (или "NT Service\MSSQL$<InstanceName>"). Если в процессе установки для запуска службы 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, от имени которой работает инстанс), которая одинаково будет работать на всех компьютерах домена.

    Поправьте меня, если где-то наврал.

    7 октября 2018 г. 9:28

Все ответы

  • Вопрос неподъёмный?
    5 октября 2018 г. 10:40
  • Я вот не понимаю, из-за чего вы считаете, что инсталлятор не верно выдает права? Почему вас тогда не смущают права на NTFS?
    Как по мне - так все правильно...

    5 октября 2018 г. 14:07
  • Вопрос был не по ACL NTFS. Не нужно сваливать всё в одну кучу.
    Вопрос конкретно по назначению привилегий через локальные политики безопасности. Как можно считать "правильным" то, что экземпляр SQL Server фактически выполняется от имени отдельно взятой сервисной учётной записи, а права инсталлятором выданы не этой учётке, а какому-то Virtual Account, который, как я понимаю, в ОС в нашем случае не используется в принципе. Именно это я и прошу прояснить.
    5 октября 2018 г. 18:17
  • Это не "какой-то Virtual Account" а вполне конкретная учетная запись инстанса и она очень даже используется и в том числе при раздаче прав ntfs на каталоги с данными sql
    6 октября 2018 г. 9:47
  • Евгений, скажите пожалуйста, каким образом можно удостовериться в том, что "очень даже используется", ведь экземпляр инстанса, то есть процесс sqlservr.exe, выполняется в контексте пользователя сервисной учётной записи, которую мы у казали в ходе установки. В нашем случае это учётная запись gMSA s-MS001$

    Я понимаю так, что если в ходе установки мы не указали выделенную сервисную учётную запись для запуска службы SQL Server DB Engine, то при её выполнении будет использоваться контекст локальной виртуальной учётной записи (Virtual Account) вида NT Service\MSSQL&<имя экземпляра>.
    Если же в ходе установки мы указали выделенную сервисную учётную запись для запуска службы SQL Server DB Engine, то, соответственно, служба выполняется от имени этой учётной записи и виртуальный аккаунт вида NT Service\MSSQL&<имя экземпляра> в таком случае не задействован.
    Это не так?



    7 октября 2018 г. 7:29
  • Нашёл интересную статью 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$<InstanceName>" для именованных инстансов и создаётся по умолчанию в современных версиях Windows Server на ровне со всеми другими службами. Активность этого аккаунта, а также его локальный SID можно узнать командой типа "sc showsid MSSQLSERVER" или "MSSQL$<InstanceName>"  

    3) Инсталлятор SQL Server 2016 при развёртывании экземпляра в основном выдаёт в системе права именно для виртуального аккаунта службы "NT Service\MSSQLSERVER" (или "NT Service\MSSQL$<InstanceName>"). Если в процессе установки для запуска службы 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, от имени которой работает инстанс), которая одинаково будет работать на всех компьютерах домена.

    Поправьте меня, если где-то наврал.

    7 октября 2018 г. 9:28