Получаем право 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 » …

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

Если заглянуть в отчёт 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, достаточно выполнить команду типа:

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

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

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

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

Debug a program that needs administrator rights under Windows 7

I’m running Visual Studio 2008 on Windows 7 64-bit. I’m logged in as administrator, and I’m running it as administrator, but the program I’m working on fails with access denied when I call a restricted API. If run the program from Explorer with «Run as Administrator» it works.

I was under the belief that Visual Studio 2008 debugs programs with whatever rights Visual Studio 2008 itself is running with. As it stands I can’t debug my application due to this, and I’m at a loss as to what’s going on.

6 Answers 6

This works for Visual Studio 2012.

• Create a manifest file: right click on the project and select «Add New Item», select «Application Manifest File». This will add a file named app.manifest to the project.
• Edit manifest file: set attribute level for tag requestedExecutionLevel to requireAdministrator .

Now your program will always require admin privileges, wherever it is executed. If launched by Visual Studio debugger, it will prompt you for restarting Visual Studio as administrator, if needed.

It’s best to run Visual Studio 2008 as administrator. Moreover, it’s good to change your application’s manifest settings to require administrator privileges. You will be prompted by the system to elevate to system administrator each time you start your application, and when running under Visual Studio 2008 the IDE will offer you the elevation before start of debugging.

To change the setting, open project properties and go to Configuration Properties → Linker → Manifest file → UAC Execution Level.

I found the answer. It turns out that it is, in fact, a manifest issue: by default if you have a manifest you need to set the appropriate administrator privilege.

The default is asInvoker , but that doesn’t work if you need elevated privileges; you instead have to set it to requireAdministrator in the manifest properties.

Run Visual Studio 2008 as administrator.

I had a case where I put in the

settings (described by another answer at this post). and did not work.

I found another tip (seen below). and unchecking that option allowed my code to work.

Try going into the project properties, and under the «debug» tab, uncheck «enable the Visual Studio hosting process» and see if that fixes your problem.

So I needed the app.manifest settings AND the «uncheck».

My testing with Windows Vista and Visual Studio 2005 showed that when you use a host process, the behavior under the debugger depends only on how you launched Visual Studio and not on the manifest (or lack of manifest) of your application. When Visual Studio is launched elevated, the behavior depends only on the use (or not) of a host process, not on the manifest. This is probably still true with Windows 7 and Visual Studio 2008.

Also, have you tried launching the application outside Visual Studio and using Attach to Process?

Windows debug privilege are you admin

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

We are following the instructions found here: http://forum.sysinternals.com/printer_friendly_posts.asp?TID=1264
in an attempt to give debug privileges to a user in one of our Windows Server 2003 sp2 boxes.

When we open the properties of the ‘Debug Programs’ policy in the server’s Local Security Settings, the ‘Add User or Group’ button and ‘Remove’ buttons are greyed out. Somehow three users are currently listed, but we can’t add more.

Our theory is that these priviliges are being populated by Active Directory (a different 2003 sp2 server on our network), but we’re not sure how.
We see a Group called «Debugger Privileges» in our Active Directory server, and added the user there, but it doesn’t appear to be propogating to the other servers on the domain.

Can anyone help?
Let me know if you need more information.

Answers

To set the «Debug Programs» policy in other member servers in your domain, you need to assign a domain group policy to these servers. You can follow the steps below:

1. In Active Directory Users and Computers, right-click the target server’s container (OU) to which you want to link the GPO, click Properties, and then click the Group Policy tab.
2. Create a new GPO for giving debug privileges on servers, and then give the new GPO a descriptive name.
3. While the new GPO is selected, click Edit. This starts the Group Policy Object Editor.
4. Open and then right-click Computer Configuration | Windows Settings | Security Settings | Local Policies | User Rights Assignment | Debug Program in the GPO, and then click Add new user or group button.
5. Click the Advanced button.
6. Click the find now button.
7. Select your user logon name and then click the ok button.
8. Click the ok button 2 more times.
9. Run «gpupdate /force» on the target servers.
10. Run «rosp.msc» to verify whether the «Debug Programs» group policy has been applied.

If you want to configure this policy for DCs, you need to modify the above policy in ADUC’s default domain controller policy.

Best regards,
Wilson Jia

This posting is provided «AS IS» with no warranties, and confers no rights.

How to run application as administrator in debug with Visual Studio?

I have a c# application where I have to have read/write access to the root of the C drive. I realize I can compile the code and run the executable as administrator and it works. But I need to debug it and I am unsure as to how one would start the app within Visual Studio.

I have tried adding:

to my manifest but I still get access denied error.

Here is the line of code that fails:

For now I have a work around but I’d like to know for the future.

6 Answers 6

Just run visual studio itself as an administrator. Any program you debug from there will also be run as an administrator.

VS must be run with admin right. however, a more elegant way is in the requiredExecutionLevel in manifest should set to ‘requireAdministrator’.

When you open the project and try to debug, the VS2012 will warn about the admin right and restart itself to admin right. And also the exe file will be marked as requiring admin right at the first place therefore when deploy you don’t need to configure admin right requirement in file properties.

You can also set this administrator option automatically:

To answer the question in your title, you can just select Run as Administrator from the context menu when starting VS.

Now the checked answer will not working.

You should find an option for this in project properties Linker -> Manifest File -> UAC Execution Level. Set this to requireAdminstrator.

This will cause the default generated manifest to include the requestedExecutionlevel that you need, so that your users will be prompted automatically to elevate their privileges if they are not already elevated.

The «This task requires the application to have elevated permissions» error occurs because of The current user didn’t have a sufficient privilege to open Visual Studio.

As a temporary solution

You can overcome this issue by right-clicking on visual studio and select run as administrator at every time you intend to open it

As a permanent solution,

You can check the compatibility troubleshooting

• Right, Click on Visual Studio > select Troubleshoot compatibility.
• Select Troubleshoot Program.
• Check The program requires additional permissions.
• Click on Test the program.
• Wait for a moment until the program launch. Click Next.
• Select Yes, save these settings for this program.