Les fonctionnalités de Débogage à distance sont véritablement pratiques pour savoir ce qui se passe sur un poste distant. Microsoft fournit l’installation d’un Remote Debuger (http://www.microsoft.com/downloads/fr-fr/details.aspx?familyid=60ec9d08-439b-4986-ae43-0487eb83c09e), une version « light » de ce que propose Visual Studio, pour permettre de déboguer des machines distantes, notamment des serveurs.

L’installation est on ne peut plus simple; on a le choix d’exécuter le Remote Debugger sous la forme d’un service (tournant sur un compte et pouvant aller jusqu’à accepter tout type d’utilisateur distant. Dans ce dernier mode, on ne peut toutefois que faire du debugage natif) ou sous la forme d’un programme.

Nous conseillons vivement cette dernière option pour du debugage sur des serveurs car cela ne devrait être que très occasionnel.

 

Configuration du Remote Debuger

 

Lors de l’installation/configuration, une seule option est disponible: configurer ou non le Remote Debugger en tant que service. Dans ce mode, le Remote Debugger est toujours actif et accessible à distance.

Le compte par défaut proposé est LocalSystem, ce qui est judicieux mais en même temps très ouvert.

Local System est un compte Built-In donnant des privilèges élevés sur l’ordinateur local et qui permet d’agir sur le réseau comme s’il s’agissait de l’ordinateur lui-même. Il n’y a pas besoin de mot de passe.

Lors de la configuration, il vous est possible de configurer un autre compte mais ses privilèges doivent avoir « Ouvrir une session en tant que service ». Microsoft propose par ailleurs que ce compte soit membre du groupe Administrateurs.

 

Options du Remote Debuger

Lancer le programme manuellement, puis allez dans Options. Le serveur porte un nom de la forme user@machine, plus précisément le user précise un domaine.

En mode Authentification Windows, on peut se permettre n’importe quel type de débugage ; le bouton « Autorisations » permet d’indiquer les comptes ayant le droit de deboguer.

Vous noterez l’option « Aucune authentification (natif uniquement) » et « Permettre à tous les utilisateurs de déboguer » qui permet à n’importe qui se connecter et deboguer, mais des applications natives seulement. Ce mode est à proscrire, d’autant plus que votre machine peut se trouver, pardonnez l’expression, en milieu « hostile » et soumise à attaque (en clair, faîtes cela chez vous, pas dans votre entreprise).

Par ailleurs, comme son nom l’indique, le debogage en mode natif

Classiquement, le compte qui debug sur une machine A en remote sur la machine B doit être le même… si possible. Malheureusement, ce n’est absolument pas le cas si A est dans un domaine et B dans un autre.

 

Debogage en interdomaine

Les choses se compliquent lorsque l’on veut déboguer à distance une machine hébergée dans un différent domaine. Rajoutons une contrainte qui a son importance, lorsque les deux domaines en question ne sont pas approuvés. Ce cas de figure qui peut vous sembler bizarre arrive bien plus fréquemment qu’on ne le croit.

Imaginons un environnement de test ou recette possédant son propre domaine, son propre AD, ses propres contraintes de sécurité ; ceci afin d’éviter tout télescopage possible. Il n’y a aucune raison de faire un domaine de production approuver un domaine de test/recette. Mais il est en revanche possible d’imaginer un développeur sur son réseau de développement (donc un environement réel, d’entreprise) nécessitant un débugage sur le domaine test/recette car un bug ne se produit que dans cet environement. Sans cette capacité de débogage, son bug ne peut être résolu et son application ne vas pas en prod.

Bref, lorsque les domaines ne sont pas approuvés, on peut choisir le débogage natif (non intéressant pour du débogage managé) mais celui-ci exige, pour des actions interdomaines de permettre à tout le monde de pouvoir se connecter à machine créant ainsi un trou de sécurité.

Il existe néanmoins une solution, ou plutôt 2 solutions.

Option 1

La première exige de jouer avec les Local Security Policy (Stratégie de sécurité locale). Dans le panneau de configuration, outils d’administration, si on lance l’application, il nous est possible (pour peu que l’on possède les droits suffisants) de changer la façon dont un compte local s’expose à l’extérieur en terme de sécurité.

Dans la section « Local Policies », « Security Options », changer la clé « Network access: sharing and security model for local accounts » de « Guest only – local users authentivcate as Guest » à « Classic – local users authenticate as themselves ».

En faisant ce réglage, on indique qu’un compte local à la machine sur un réseau se présente en tant que lui-même. Cette option est classique lorsque vous faite un Workgroup de machine et non pas un domaine. Pour permettre à un compte d’accéder à un partage par exemple, il suffit de dupliquer ce compte ; même user, même password; pour que l’accès soit autorisé

Le Remote Debuging exigeant une communication dans les deux sens, il vous faut faire ce réglage sur les 2 machines impliquées dans la communication.

Cette option fonctionne bien mais souffre d’une grosse limitation… On se retrouve à modifier des réglages de sécurité sur les 2 machines impliquées. Lorsque l’une d’en être elle est une serveur, c’est une sacré limitation car on augmente la surface d’attaque. Des problèmes peuvent surgir au niveau partage et DCOM et quelqu’un à distance peut s’authentifier avec votre compte plutôt qu’en Guest. Par ailleurs, il faut se soucier d’avoir un compte en double avec un mot de passe similaire pour que cela fonctionne (on peut faire correspondre un compte de domaine, même user/password, à un compte local).

Option 2

L’option 2 est beacoup plus belle… Et beaucoup plus simple aussi (sauf si l’on se met à déplacer le répertoire utilisateur AppData sur le réseau. Nous préciseronts ce point par la suite).

L’astuce consiste à utiliser une seule et unique commande : un runas ! Mais attention, ce runas est lancé dans un mode spécial.

Pour rappel, le runas permet l’exécution d’un programme sous le compte d’un autre utilisateur. Il suffirait a priori de faire un runas en précisant Visual Studio et banco, le remote debugger et VS 2010 se retrouve dans le même domaine et, comme dirait Dora, c’est gagné !!

Malheureusement, ce n’est pas aussi simple. Si on effectue un runas classique en précisant un user sur un autre domaine, malheureusement l’application que l’on lance va s’exécuter avec un compte… d’un autre domaine… et ceci en local .

Bref, vous l’aurez compris, ce n’est pas possible puisque votre machine locale respectera les contraintes de son propre domaine et n’autorisera pas un compte extérieur d’un autre domaine à lancer un programme sur votre machine.

Nous souhaiterions non seulement pourvoir utiliser notre poste local, dans son domaine et ses crédentials, tout en faisant en sorte que les communications réseaux s’effectuent sous l’identité d’un autre compte.

Si nous vous disions que la commande runas a été modifiée en ce sens par Microsoft en lui attribuant l’option netonly ?

Pour preuve, notez l’appel suivant (ligne de commande) qui permet de lancer Visual Studio sous le compte local de l’utilisateur et qui fait en sorte que les appels réseaux s’effectuent avec un autre compte sous un autre domaine.

 

runas /netonly /user:domain\user « C:\localapp\Apps\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe »

Le programme vous lancera une invite de commande vous permettant d’indiquer le mot de passe.

Votre Visual Studio va se lancer sous votre propre compte, mais tout appel réseau se déroulera sous le compte/domaine ayant été précisé via la balise netonly.

 

Attention, un bug peut se produire.

Ce bug peut se produire si votre ordinateur local, un ordinateur d’entreprise, a été configuré pour que votre profil soit sauvegardé sur le réseau. Dans ce cas de figure spécifique, Visual Studio se connectera au partage réseau avec le compte fourni par /netonly et pas votre compte de domaine.

Il en résultera l’erreur suivante :

 

Don’t panic… Là aussi il y a une astuce, modifier dans la registry le répertoire AppData

Dans « HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders », il suffit de renseigner un répertoire local temporaire de votre machine. Pensez bien à modifier cette clé de registre après coup….

Pourquoi choisir l’option 2 vis-à-vis de l’option 1 ? Ou l’inverse ?

Parce que vous ne créez pas un deuxième compte et parce que vous ne modifiez pas les stratégies de sécurité locale des machines que vous souhaitez déboguer, l’option 2 est nettement plus intéressante que l’option 1. Une simple ligne de commande…

Toutefois, dans le cas d’un répertoire AppData sauvegardé sur le réseau, c’est une histoire de préférence car les 2 solutions ont leurs inconvénients et avantages. L’option 2 reste locale mais exige des modifications de clé de registre (ce qui est sensible pour un non averti). L’option 1 demande des modifications de part et d’autre, augmente le risque de sécurité, mais aucune action sensible en base de registre n’est requise… A vous de juger.

 

Comment deboguer à distance

Toute les possibilités de debug à distance sont maintenant activées.

Lancez Visual Studio, puis vous pouvez par exemple cliquer sur Debug, puis Attach To Process

 

 

Noter le qualifier. Il correspond au compte et à l’adresse de la machine sur laquelle on souhaite se connecter.

Plus précisément, on notera qu’il s’agit de l’adresse proposée par le msvmon (le remote debugger).