Share via

Remote Debugging without domain accounts

  • Article

This blog has been on my todo list forever. I am now sitting in an airport, so I guess it is time for the procrastination is over… I want to talk about remote debugging in the following network situations:

  • Two domains without two-way trust
  • Two computers on a workgroup
  • One computer on a workgroup, and the other on a domain
  • Running the Remote debugging monitor (msvsmon) or Visual Studio as a local account

But first an introduction.

Introduction to remote debugging security

In VS 2005, remote debugging works by having Visual Studio communicate with the Remote debugging monitor (msvsmon.exe). All communication is authenticated and communication goes both ways. This means that it is not only important what user runs Visual Studio, but it is also important what user runs msvsmon.exe.

To be able to connect to msvsmon, Visual Studio must either be run as the same user as msvsmon, or must be run as an administrator. You can also configure msvsmon to accept connections from other users.

Visual Studio will accept the connection from msvsmon as long as msvsmon is run as a user that can authenticate with the Visual Studio computer.

The main event

Regardless of what situation you are in, you need to get the user account running Visual Studio to map to a user account on the Msvsmon machine, and you need to get the user account running msvsmon to map to a user account on the Visual Studio machine. The way you do this is to create a local user account on both computers with the same user name and password. If you need to run msvsmon as a different user then Visual Studio, then you will need to create two user accounts on each computer.

If you have one of the machines on a domain, it should be noted that a domain account can map to a local account. However, I haven't yet found a way for a local account to a domain account. What this means is that you will still have to create a local user account on both computers, but as long as you pick the same user name and password as your domain account, you can still run Visual Studio as a domain account.

For Windows XP machines on a workgroup, another concern is a security option entitled 'Network security: Shared and security model for local accounts'. This can be configured via the 'Local Security Policy' administrative tool. If this option is set to 'Guest only – local users authenticate as guest', then remote debugging is not going to work. This is not a problem for computers running Windows 2000, Server 2003, or Windows XP computers that are joined to a domain.

Lastly, if one or both computers are on a domain with IPSEC policy, you may have to work around that as well. I am not an expert on IPSEC, but I no have one suggestion – if you connect from the domain to the workgroup computer first, then connections going the other way might start working.

Comments

  • Anonymous
    October 27, 2004
    The comment has been removed

  • Anonymous
    October 27, 2004
    These instructions apply for XP and Win2k.

  • Anonymous
    March 08, 2006
    I got to spend the day out at the Sydney Security Seminar on Wednesday

    The day kicked off with a keynote...

  • Anonymous
    February 12, 2007
    PingBack from http://dotnetdebug.net/2007/02/12/remote-debugging-with-visual-studio-2005/

  • Anonymous
    November 01, 2007
    Introduction This FAQ can be used to narrow down the problems associated with debugging any type of solution

  • Anonymous
    May 15, 2008
    I was asked today -- Why does the Visual Studio Remote Debugger Service need to be run as an administrator?

  • Anonymous
    October 25, 2008
    PingBack from http://sevcik.tk/2008/10/26/remote-debugging-across-domains.html