Получаем право SeDebugPrivilege для успешной установки Microsoft SQL Server 2012 при ограниченной доменной политике "Debug programs"

В свете недавних событий с повышением вирусной активности многие организации стали уделять больше внимания вопросам всестороннего усиления мер безопасности в собственных ИТ-инфраструктурах. При этом некоторые из применяемых мер могут создать дополнительные сложности в работе самих ИТ-специалистов.

Как известно, в последних вариациях вирусов-шифровальщиков, таких как Petya, используются такие инструменты компрометации учётных данных, как Mimikatz. Одним из методов защиты от Mimikatz является запрет на получение в Windows-системе привилегии SeDebugPrivilege. В инфраструктуре Active Directory настроить такое ограничение можно глобально для всех компьютеров домена с помощью параметра групповой политики "Debug programs" в разделе Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment:

Если в данной политике явно задать доменную группу безопасности, то только члены данной группы смогут получить привилегию SeDebugPrivilege на всех компьютерах домена, на которые будет действовать данная групповая политика. Однако данная политика может осложнить жизнь не только инструментам типа Mimikatz, но и вполне легитимным приложениям, которые в своей работе могут использовать привилегии отладки. Например, после включения данной политики программа установки SQL Server 2012 может завершаться с ошибкой проверки правила "Setup account privileges" …

The account that is running SQL Server Setup does not have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights.

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

Если заглянуть в отчёт SystemConfigurationCheck_Report.htm, который создаётся в процессе установки SQL Server в каталоге типа "C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\<отметка времени>\"…

  …, то мы увидим, что срабатывает правило HasSecurityBackupAndDebugPrivilegesCheck, которое и выполняет проверку наличия прав доступа SeSecurityPrivilege, SeBackupPrivilege и SeDebugPrivilege. Как я понял, если хотя бы одна из перечисленных привилегий не будет доступна пользователю, от имени которого запущен процесс установки SQL Server, то ошибка при проверке правила HasSecurityBackupAndDebugPrivilegesCheck неизбежна.

Как же быть в такой ситуации тем пользователям, которые являются локальными администраторами серверов, но не могут при этом установить SQL Server не прибегая к помощи администраторов безопасности уровня домена? Неужели каждый раз придётся терзать доменную группу безопасности, определённую в политике "Debug programs"?

Возникла идея "поковырять" вопрос того как, обладая правами локального администратора на сервере, но не входя при этом в группу безопасности из политики "Debug programs", успешно выполнить установку SQL Server. После некоторых экспериментов в этой области на платформе Windows Server 2012 R2 Standard с установщиком SQL Server Standard 2012 SP2 удалось добиться желаемого результата. В решении задачи помогла старенькая утилита ntrights.exe из пакета Windows Server 2003 Resource Kit Tools. Примеры использования утилиты можно найти в статье How to Set Logon User Rights with the Ntrights.exe Utility

Чтобы получить необходимую нам привилегию SeDebugPrivilege, достаточно выполнить команду типа:

C:\WinSrv2003RKTools\ntrights.exe +r SeDebugPrivilege -u KOM\Vasya

 Granting SeDebugPrivilege to KOM\Vasya   ... successful

где KOM\Vasya имя доменного пользователя, от имени которого мы будем выполнять установку SQL Server. После выполнения этой команды, соответствующему пользователю необходимо выполнить logoff/logon и запросить информацию о текущем наборе прав, например с помощью утилиты whoami:

C:\Windows\system32>whoami.exe /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                  Description                               State
=============================== ========================================= ========
...
SeSecurityPrivilege             Manage auditing and security log          Disabled
...
SeBackupPrivilege               Back up files and directories             Disabled
...
SeDebugPrivilege                Debug programs                            Disabled
...

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

Однако помните про то, что после очередного применения групповой политики право SeDebugPrivilege будет снова изъято (согласно настроек доменных GPO) и уже после следующего logoff/logon данная привилегия у нашего пользователя перестанет работать.

На мой взгляд, такое поведение системы можно расценивать, как уязвимость, которую помимо легитимного локального администратора может эксплуатировать и вредительское ПО с уровнем прав локального администратора. То есть, даже с глобально включённой в домене политикой "Debug programs", по факту остаётся риск получения права SeDebugPrivilege со стороны вредоносного ПО, использующего такие инструменты, как Mimikatz.

Дополнительные источники информации:

• KB2000257 - SQL Server installation fails if the Setup account doesn't have certain user rights
• Fort SQL - Installing SQL Server 2008 Services in a High-Security Domain (Part I),
  (Part II)
• Esoteric - SQL 2012 Setup Rules – The ‘Missing Reference’