Publié
vendredi 20 février 2009 11:16
par
Rui
Pour ceux qui utilisent IIS pour hoster une partie de leurs services WCF ou même lorsque vous lancez des services WCF à partir de Visual Studio sous Vista (ou Server 2008), vous avez certainement rencontré des problématiques de droits.
En effet il n'est pas possible nativement pour des raisons de sécurité évidentes d'ouvrir une Uri à l'écoute sur un Windows récent (ça ne résoud pas tous les trous de vers mais bon ;-)). La plus part du temps on résoud cela rapidement en augmentant les privilèges du service. Ce qui peut se traduire par:
Sous IIS, lancer l'application pool du site hébergeant le WCF en mode Local System:
![]()
Sous Visual Studio: redémarre en mode [Run as Administrator] ...
C'est une bonne solution en développement ou en dépannage, mais un peu légère du point de vue d'un Admin Sys.
La solution la plus propre consiste tout simplement à accorder des droits de publication à un utilisateur X sur une Uri Y. Pour cela deux utilitaires,
httpcfg sous Windows 2003 ou
netsh sous Vista et Windows Server 2008.
Pour info, httpcfg se trouve dans l'installation des SupportTools du CD de Windows Server 2003 et netsh est livré nativement avec Vista et +.
En ligne de commande pour voir la liste des droits actuellement définis sur une machine vous pouvez taper:
- httpcfg query acl
- netsh http show urlacl
Ce qui vous donnera une liste du type:

Pour ajouter alors une uri (http://localhost:1234/MyService) à un utilisateur(Network Service) sous netsh il suffira de taper la commande suivante (avec des droits administrateur bien sur):
netsh http add urlacl url=http://+:1234/MyService user="NETWORK SERVICE" listen=yes delegate=yes
Sous httpcfg, c'est un peu plus pénible car il faut rentrer l'acl directement...Je vous conseille donc d'utiliser l'excellent petit utilitaire
HttpConfig.
C'est une petite interface très simple qui fonctionne à la fois sous 2003 et Vista qui permet à la fois d'afficher les Uri actuelles avec leurs droits et d'en ajouter/supprimer:

Bref, c'est assez pratique (surtout si une fois sur deux vous oubliez comme moi de lancer Visual Studio en mode Admin cela peut vous éviter quelques relances de solution...)
Bien sur tout cela est surtout à voir dans un cadre de production avec les Administrateurs qui eux sauront adapter leur politique de sécurité.
Bons services
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :