Как управлять входом в систему как сервисным правом для виртуальной учетной записи в условиях групповой политики домена?

Я хотел бы использовать настройку SQL Server по умолчанию, которая запускает службу SQL Server с виртуальной учетной записью NT SERVICE\MSSQLSERVER. Это гарантирует, что мой SQL Server имеет ограниченный доступ на собственной машине и не имеет доступа к сетевым ресурсам, если он должен быть взломан. Тем не менее, наш домен также имеет групповую политику, которая устанавливает права входа в систему как службы для нескольких других (домен).

Вы, наверное, уже догадались или, возможно, даже испытали мою проблему:

Когда объект групповой политики домена применяется к серверу (как минимум ежедневно), он отменяет назначение прав входа в систему как службы, которое было выполнено с помощью установки SQL Server (или конфигурации SQL Server Config Mgr, или другой конфигурации политики локального компьютера). Затем для этапа устанавливается ошибка "Служба не запущена" при следующем перезапуске службы SQL Server, что может произойти через несколько часов или месяцев.

Вот что я знаю до сих пор:

  • Я не могу добавить виртуальную учетную запись в GPO домена, потому что это SID локального компьютера.
  • Групповая политика домена переопределяет групповую политику локального компьютера, поэтому мне придется что-то делать с групповой политикой домена.

Вызывает сожаление тот факт, что элемент "Назначение прав пользователя" находится в разделе "Параметры компьютера" \ "Параметры Window s" \ "Параметры безопасности" \ "Параметры локальной политики", поскольку он не может ссылаться на учетные записи локального компьютера. Может быть, это даже ошибка.

Вот подходы, которые я рассматриваю:

  • Я мог бы исключить элемент GPO домена, который применяет право "Вход в систему как служба", и выполнить эту операцию с помощью локальной групповой политики (на нескольких серверах).
  • Я мог бы переместить сервер в OU, к которому не применен этот элемент GPO. В настоящее время нарушающий GPO является моей политикой домена по умолчанию, поэтому мне придется провести рефакторинг.
  • Я мог бы запустить какой-либо инструмент на каждом компьютере с SQL Server, чтобы восстановить функцию "Вход в систему как сервис" сразу после запуска групповой политики домена или достаточно часто, чтобы меня редко ловили.

У кого-нибудь есть другие предложения или рабочие решения, чтобы предложить мне?

Источник

4 ответа

Решение

В конечном итоге я сделал следующее: удалил объект групповой политики, который использовал вход в систему в качестве права службы, и полагался на отдельные машины, чтобы предоставлять права по мере необходимости при установке служб на этих машинах.

Это довольно саморегулирующееся решение, так как services.msc предоставит право со страницы свойств при установке пароля учетной записи службы. И что-то эквивалентное, по-видимому, происходит, когда вы устанавливаете приложения, которым нужен сервис.

Источник

Если вы добавите консоль управления групповой политикой на рассматриваемый SQL-сервер, вы можете изменить параметр групповой политики, о котором вы говорите, включив в него «NT Service\MSSQLSERVER» или любое другое имя учетной записи «NT Service\xxxx». Если вы откроете объект групповой политики на другом сервере, вы увидите большой длинный SID вместо красивого псевдонима «NT Service\xxxx». Вы можете добавить gpmc.msc из сеанса PowerShell администратора с помощью:

      Install-WindowsFeature GPMC

Решение, которое работает еще лучше для добавления этих учетных записей «NT SERVICE\xxxx», заключается в добавлении вместо этого встроенной группы «NT SERVICE\ALL SERVICES» — тогда вам не придется добавлять их по отдельности, и она будет отображаться в удобочитаемый формат в других системах, а также при просмотре в GPMC. Я столкнулся с этим при работе со службой синхронизации Azure AD, а затем снова с внутренней базой данных Windows, которая устанавливается для развертываний RDS. Я мог добавить группу «NT SERVICES\ALL SERVICES» только на машине, на которой уже были некоторые из этих учетных записей «NT SERVICE\xxxx». Несколько статей, которые помогли объяснить, как это работает, находятся здесь:

Изменяет ли Install-ADSericeAccount «NT SERVICE\ALL SERVICES» https://docs.microsoft.com/en-US/windows/security/identity-protection/access-control/security-identifiers

Как сказал Аарон Д., вероятно, лучше всего создать учетную запись службы в Active Directory вместо использования встроенных локальных учетных записей службы NT. Вот несколько дополнительных статей об использовании управляемых учетных записей служб Active Directory, если вы хотите пойти по этому пути:

Использование управляемых учетных записей служб с SQL Server
Настройка управляемых учетных записей служб для SQL Server

Источник

Я вижу, что никто еще не ответил, поэтому я дам вам 2 цента.

Вот что я думаю, я бы попробовал:

  1. Создайте новую OU под названием SQL Servers
  2. Переместите компьютерный объект SQL в эту OU
  3. Создайте новый объект групповой политики с именем SQL Logon As A Service.
  4. Добавить все из политики домена по умолчанию
  5. Создать управляемую учетную запись службы в Active Directory
  6. Добавьте управляемую учетную запись службы в список "Вход в систему как служба".

Вот пара ссылок, которые я нашел, которые также могут вам помочь:

Настройте учетные записи служб Windows и разрешения
Учетная запись службы SQL Server Windows привилегии и права

Источник

Перейдите в свой объект групповой политики и добавьте "NT SERVICE\ALL SERVICES". Это позволит всем учетным записям виртуальных служб работать.

Источник
Другие вопросы по тегам