Discussion :

[zooffy]

Bonjour à tous.

Je me pose une question de sécurité : si je mets l'utilisateur LOCAL SERVICE comme utilisateur de IIS, qu'est de que je risque ?

Et si je met le NETWORK SERVICE ?

Je parle de risque autant en terme de sécurité anti intrusion que fonctionnement de la machine.

Merci pour votre aide.

[suchiwa]

Bonjour à tous.

Je me pose une question de sécurité : si je mets l'utilisateur LOCAL SERVICE comme utilisateur de IIS, qu'est de que je risque ?

Et si je met le NETWORK SERVICE ?

Je parle de risque autant en terme de sécurité anti intrusion que fonctionnement de la machine.

Merci pour votre aide.

Zooffy,

Justement, tu risques rien avec ces comptes, car ils sont limités en terme de droits.

Le Local Service et le network service n'ont pas de droits administrateurs.
Donc l'apllication qui tourne avec ce compte ne peut faire que le stricte minimum.

D'où leur utilité pour IIS, SQL, les applications métiers...

Vincent

[zooffy]

Merci pour ton aide.

Bon, ben voilà un problème de résolu, déjà.
Avec le Local Service, je peux modifier mon fichier de liaison dans IIS et envoyer ma commande DOS sans plus de souci.

Mais ça n'empêche pas que j'aimerais bien finir par comprendre le powerShell.

Bonne continuation.

[zooffy]

Oooopss, j'ai gouré de compte !!!

Alors le compte que je voudrais mettre est LOCALSYSTEM.

Là, je pense que ça doit pas être pareil, non ?

[suchiwa]

Oooopss, j'ai gouré de compte !!!

Alors le compte que je voudrais mettre est LOCALSYSTEM.

Là, je pense que ça doit pas être pareil, non ?

Bonjour Zooffy,

Non, c'est pas la même chose....

http://blogs.msdn.com/b/esiu/archive...19/eugene.aspx

Vincent

[zooffy]

Ok, je vois, c'est donc assez dangereux.

L'ennui c'est que pour mon histoire de Liaison dans IIS, avec le compte LocalSystem ça marche.

Je pense que c'est une histoire de droit sur un ficher de config. Le User de base de IIS ne peux pas l'ouvrir, le Local Service et le NetWork Service non plus.
Mais le Local System oui, il peut l'ouvrir et le modifier.

Du coup, je ne sais plus trop quoi faire.

De surcroit, j'ai pu capter les principes de l'exlication dans le lien que tu me donne, mais pas le détail profond puisque je ne suis pas anglophone. J'ai cru compendre qu'il donne une solution intermédiaire, mais j'ai pas compris.

[suchiwa]

Ok, je vois, c'est donc assez dangereux.

L'ennui c'est que pour mon histoire de Liaison dans IIS, avec le compte LocalSystem ça marche.

Je pense que c'est une histoire de droit sur un ficher de config. Le User de base de IIS ne peux pas l'ouvrir, le Local Service et le NetWork Service non plus.
Mais le Local System oui, il peut l'ouvrir et le modifier.

Du coup, je ne sais plus trop quoi faire.

De surcroit, j'ai pu capter les principes de l'exlication dans le lien que tu me donne, mais pas le détail profond puisque je ne suis pas anglophone. J'ai cru compendre qu'il donne une solution intermédiaire, mais j'ai pas compris.

Pas anglophone... et le metal, c'est pas anglophone ?
"C'est pas du fer, c'est du metal..." Je me perds...

Bref les meilleurs docs sont en anglais, j'y peux rien, et les traductions sont dangereuses...

Retourne sur l'un des post avec les user rights management.
La différence entre ce comptes sont les droits autorisés pour ces derniers.
Log as a service
Act as part of the system
...

Tu identifies les différences entre chaque, tu fais un tableau avec d'un coté les comptes (localsystem, localnetwork...) en relation avec tes droits (log as a service, log as a batch...) et tu analyses les points suivants :

• LocalSystem fait tourné ton service mais ne doit/devrait pas l'utiliser, car trop de privilèges.
• tu modifies les autres groupes avec les droits jusqu'à ce que ça marche
• c'est long car tu dois tester chaque étape par un redémarrage de service entre chaque changement

Vincent