I recently read a story in a germany magazine about developing with Visual Studio under a non-Admin account. I am happy that this topic gets more and more press coverage so that people start to think about it.

But there still seems to be some confusion regarding the Debug privilege.

The article states that you need this privilege to attach to processes that run under a different account (that’s right) and further says that the “Debugger Users” group, that gets generated by VS.NET install, has this privilege granted. So everyone who needs this privilege has just to be added to “Debugger Users”.

That’s not true. The “Debugger Users” group serves only one purpose. It gets checked by the Machine Debug Manager. Let me quote shaykatc:

“Visual Studio uses a service to do debugging called the MDM or Machine Debug Manager. This is one of the components installed by the remote debugging components. This is needed only by Visual Studio – so if you have the framework on your machine, or cordbg this doesnt apply. The MDM is the first gatekeeper – only two people are allowed to talk to it. Admins on the machine + members of the Debugger Users group (a group created on the machine when the mdm installs). The Debugger Users group is often misunderstood. It serves one function only – its members are allowed access to the MDM. It gives no other permission or privilege to you.”

That would clarify why you still can’t debug ASP.NET apps while being a member of this group.

“So lets say you add yourself to the Debugger users group and you are’nt an admin on the machine. Now comes the second test – the runtime rule for managed debugging. The rule is simple – if the managed process is running as you, or you are an admin on the machine, you can managed debug it. So now the debugger tries to attached to aspnet_wp.exe (which almost always runs as ASPNET/Network Service). You are’nt an admin so that check fails. You arent ASPNET/Network Service so that check fails too and you cant attach.”

Granting SeDebugPrivilege to the developer would help here – but i wouldn’t recommend it.

So why do i want to get rid of SeDebugPrivilege?
SeDebug is a very powerful privilege, it allows you to read the memory of other processes (including the Local Security Authority) and let’s you even inject code in those processes.
The famous “LSADUMP” tool only needs this privilege to dump out all LSA Secrets.

My Home Office/Laptop Scenario
I mainly run as non-Admin to shield myself from some malware and to “self discipline” myself when writing code. I am running on my own hardware in my own domain. So it’s my own choice

Corporate Scenario
Imagine a domain environment where you may have services running on the development machines that need a password (e.g. backup agent or remote admin software) of a local admin or even worse domain admin account. LSADUMP is your friend and shows you this password. A developer holding that privilege can do all sorts of other nasty things to the machine, believe me.
So running as non-Admin or not granting SeDebugPrivilege helps save the user from viruses, trojans etc – but also shields the Domain Environment from a malicious user (i recently had a customer which policy included the handling of SeDebugPrivilege for the Development Appartment – sadly, they got it wrong, too).

So how do i get rid of SeDebugPrivilege?

Well – that’s not always easy. The main situation where debugging fails is when developing ASPX or ASMX projects.
I use the following solution (which only works on IIS 6)

• Create a AppPool. Set the Identity of this AppPool to your account
• Add your account to the IIS_WPG group
• Add the ASP.NET Project to this AppPool

Now the Worker Process runs under your account and the Debugger has no problems attaching to it, even if you are not Admin – have SeDebugPrivilege.

The story is a little bit different under IIS5/5.1. You could make ASP.NET run under another account as ASPNET – you can configure that in machine.config – i assume this involves some testing and i haven’t tried it yet – but it should work.

When you are doing Enterprise Services/COM+ development, you can run the COM+ Application under the interactive (your) account – or specifiy another account. so this works too.