Précédent   Forum des professionnels en informatique > Systèmes > Windows > Windows Serveur
Windows Serveur Forum d'entraide professionel pour Windows Serveur : NT, 2000, 2003 , Longhorn...
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 16/12/2010, 17h17   #1
Invité de passage
 
Antoine
Inscription : juillet 2009
Messages : 11
Détails du profil
Informations personnelles :
Nom : Antoine
Localisation : France, Ille et Vilaine (Bretagne)

Informations forums :
Inscription : juillet 2009
Messages : 11
Points : 1
Points : 1
Par défaut Service sous le compte "Local system" et accès à Internet

Bonjour à tous,

Je suis en train de configurer un serveur de build sur un WS 2008 virtualisé. J'ai donc installé Tomcat 6, Hudson par dessus (1.388), et j'ai configuré mes jobs. Il ne me reste qu'une erreur à corriger :

Dans notre processus de build, nous devons signer un certain nombre d'exécutables et de setup (avec l'utilitaire signtool.exe de Microsoft). Ensuite nous devons appliquer un timestamp. Tout ceci se fait avec la commande :
Code :
signtool sign /v /f certif.pfx /p our_passwd /t http://timestamp.verisign.com/scripts/timestamp.dll fichier_a_signer.exe
Cette commande répond la chose suivante :
Citation:
The following certificate was selected:
Issued to: xxxx
Issued by: Thawte Code Signing CA
Expires: 21/03/2011 13:45:48
SHA1 hash: xxxxx
Done Adding Additional Store
Attempting to sign: fichier_a_signer.exe
Number of files successfully Signed: 1
Number of warnings: 1
Number of errors: 0
SignTool Error: The specified timestamp server could not be reached.
SignTool Warning: Signing succeeded, but an error occurred while attempting to
timestamp: fichier_a_signer.exe
Et ce message s'accompagne d'un code de retour négatif, ce qui fait que le build complet est invalide.

Après plusieurs recherches, il s'avère que :
- Ce n'est pas le pare-feu qui bloque l'accès
- Ce n'est pas le proxy non plus, puisque la commande fonctionne bien à la main dans un invite de commande (sous le compte administrateur)

J'en déduis donc que le compte qui exécute Tomcat en tant que service (Local System) ne peut pas accéder au web, ce qui est confirmé par exemple ici : http://technet.microsoft.com/fr-fr/l.../bb680595.aspx
Citation:
Le compte de système local ne dispose pas de droits d'accès au réseau. Lorsque l'accès au réseau est requis, le système local utilise le compte Domain\nomordinateur$.
J'ai essayé de configurer Tomcat pour qu'il utilise le compte Local Service ou Network Service, mais ces comptes ne disposent pas des autorisations nécessaires pour écrire sur tout le système (et notamment dans C:\.hudson\jobs\...).

J'ai fini par configurer Tomcat pour qu'il démarre sous le compte Administrateur, ça fonctionne, les builds passent bien, mais je me pose quelques questions :
Est ce que faire tourner Tomcat avec le compte Administrateur est dangereux ? Existe-t-il un moyen d'autoriser le compte Local System à accéder à Internet, ou au moins à 1 adresse autorisée ?

Merci d'avance à ceux qui me liront, et aussi à ceux qui pourront me répondre
Tawane est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 11/01/2011, 10h11   #2
Membre expérimenté
 
Avatar de suchiwa
 
Homme Vincent
Consultant en technologies
Inscription : avril 2010
Messages : 383
Détails du profil
Informations personnelles :
Nom : Homme Vincent
Âge : 32
Localisation : France, Paris (Île de France)

Informations professionnelles :
Activité : Consultant en technologies
Secteur : High Tech - Opérateur de télécommunications

Informations forums :
Inscription : avril 2010
Messages : 383
Points : 536
Points : 536
Citation:
Envoyé par Tawane Voir le message
Bonjour à tous,

Je suis en train de configurer un serveur de build sur un WS 2008 virtualisé. J'ai donc installé Tomcat 6, Hudson par dessus (1.388), et j'ai configuré mes jobs. Il ne me reste qu'une erreur à corriger :

Dans notre processus de build, nous devons signer un certain nombre d'exécutables et de setup (avec l'utilitaire signtool.exe de Microsoft). Ensuite nous devons appliquer un timestamp. Tout ceci se fait avec la commande :
Code :
signtool sign /v /f certif.pfx /p our_passwd /t http://timestamp.verisign.com/scripts/timestamp.dll fichier_a_signer.exe
Cette commande répond la chose suivante :

Et ce message s'accompagne d'un code de retour négatif, ce qui fait que le build complet est invalide.

Après plusieurs recherches, il s'avère que :
- Ce n'est pas le pare-feu qui bloque l'accès
- Ce n'est pas le proxy non plus, puisque la commande fonctionne bien à la main dans un invite de commande (sous le compte administrateur)

J'en déduis donc que le compte qui exécute Tomcat en tant que service (Local System) ne peut pas accéder au web, ce qui est confirmé par exemple ici : http://technet.microsoft.com/fr-fr/l.../bb680595.aspx


J'ai essayé de configurer Tomcat pour qu'il utilise le compte Local Service ou Network Service, mais ces comptes ne disposent pas des autorisations nécessaires pour écrire sur tout le système (et notamment dans C:\.hudson\jobs\...).

J'ai fini par configurer Tomcat pour qu'il démarre sous le compte Administrateur, ça fonctionne, les builds passent bien, mais je me pose quelques questions :
Est ce que faire tourner Tomcat avec le compte Administrateur est dangereux ? Existe-t-il un moyen d'autoriser le compte Local System à accéder à Internet, ou au moins à 1 adresse autorisée ?

Merci d'avance à ceux qui me liront, et aussi à ceux qui pourront me répondre
Bonjour,

Faire tourner un service sous le compte adminsitrateur est dangereux pour les raisons suivantes :

1\ Accès à tout le système.
2\ Ce n'est pas un comtpe de service, c'est un compte d'administration, ce n'est pas son rôle de faire tourner un service.
3\Si un jour tu changes le mot de passe ou le lock pour une raison quelconque, ton service ne fonctionnera plus.

Je pense qu'il faut travailler en profondeur au niveau des comptes de service.
Es tu dans un domaine ? Si oui, un compte de domaine est le plus approprié pour le cas actuel. Un compte de service doit compporter une convention de nommage comme Application_SVC, SVC_App... Sinon un comtpe local que tu nommes de la même façon.

Ensuite, pour avoir travaillé sur un cluster Microsoft, tu dois spécifier soit par GPO (Group Policy Object, les stratégies de domaine), soit en local (stratégies locales) avec secpol.msc, les User Rights
Assigments, qui détermient si le compte à tel ou tel droits sur le système.

Elles se présentent de cette façon :

Tapez secpol.msc dans démarrer\exécuter, s'ouvre la mmc Local Security Policy, puis aller dans Security Settings\Local Policies\User Rights Assigments\

Chercher les droits suivants :

Log as a service
Log as a batch job
Act as part of the operating system
Create a token object
Lock pages in memory
...
...

Double cliquez sur l'object puis Add Users or Groups, sélectionner l'ordinateur ou le domaine, ensuite ajouter le compte de service que vous avez créé pour l'occasion. Apply et ok.

Suivant les prérequis de ton application qui doivent se trouver dans les premières pages du manuel d'utilisation, tu adaptes les droits demandés pour ton compte de service.

Tu relances ton serveur ou ta machine. Tu devrais voir apparaitre dans les process ton application et le compte de service approprié.

Tiens moi au courant, je suis curieux de savoir si ça va t'aider.

Vincent
suchiwa est déconnecté   Envoyer un message privé Réponse avec citation 10
Vieux 11/01/2011, 15h00   #3
Expert Confirmé
 
Avatar de vpourchet
 
Homme Valentin POURCHET
Integrateur Systemes & Virtualisation
Inscription : avril 2008
Messages : 1 130
Détails du profil
Informations personnelles :
Nom : Homme Valentin POURCHET
Âge : 24
Localisation : France, Paris (Île de France)

Informations professionnelles :
Activité : Integrateur Systemes & Virtualisation
Secteur : Conseil

Informations forums :
Inscription : avril 2008
Messages : 1 130
Points : 2 526
Points : 2 526
Envoyer un message via MSN à vpourchet Envoyer un message via Skype™ à vpourchet
Enorme +1 pour vincent.

Ne jamais laisser un service tourner sous le compte admin

Creer un compte dedie avec 'juste' les autorisations necessaires est une des best practices a respecter.
__________________
Mon blog consacré aux solutions de Virtualisation

VMware vExpert 2012, VMware Technical Sales Professional, VMware Sales Professionnal
Citrix Certified Sales Professional
DataCore Sales Certified Professional
vpourchet est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/01/2011, 16h24   #4
Invité de passage
 
Antoine
Inscription : juillet 2009
Messages : 11
Détails du profil
Informations personnelles :
Nom : Antoine
Localisation : France, Ille et Vilaine (Bretagne)

Informations forums :
Inscription : juillet 2009
Messages : 11
Points : 1
Points : 1
Merci d'avoir pris un peu de temps pour m'aider. J'ai donc créé un User Local, et je lui ai attribué les droits que tu m'a conseillé :
Citation:
Envoyé par suchiwa Voir le message
Chercher les droits suivants :

Log as a service
Log as a batch job
Act as part of the operating system
Create a token object
Lock pages in memory
...
...
Je l'ai aussi autorisé à accéder au réseau pour qu'il puisse faire des requêtes sur le net (Onglet Dial-in des propriétés de l'utilisateur).

Ensuite, après un test, j'ai dû modifier les droits d'accès à deux répertoires du serveur (le repertoire temp de Tomcat et le répertoire de travail de Hudson, l'appli d'intégration continue) -> j'ai ajouté mon utilisateur SVC_app et je l'ai autorisé à faire des modifs dans les deux répertoires.

Pour ces deux répertoires, l'user dispose donc des droits Modify, Read & Execute, List folder contents, Read et enfin Write.

Citation:
Envoyé par suchiwa Voir le message
Suivant les prérequis de ton application qui doivent se trouver dans les premières pages du manuel d'utilisation, tu adaptes les droits demandés pour ton compte de service.
Les premières pages du manuel de Tomcat indiquent ça :
Citation:
For optimal security, the service should be run as a separate user, with reduced permissions (see the Windows Services administration tool and its documentation).
je n'ai trouvé nulle part dans la doc une liste des droits requis par Tomcat. De même pour Hudson, la doc explique comment faire tourner l'appli en tant que service, et on voit dans les exemples qu'elle est exécutée sous le compte Local System.

Malgré tout ça, mes builds sont toujours stoppés à l'étape de signature des exécutables, qui nécessite une connexion extérieure à internet, par l'intermédiaire de signtool.exe (outil Microsoft). Or sous Windows server 2008, le compte Local System ne peux pas accéder au net. Donc j'aimerais pouvoir trouver LE "User Right Assignement" qui me permettra d'autoriser Local System à aller récupérer un timestamp de temps en temps sur le site de Verisign...

Merci encore pour tes conseils
Tawane est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/01/2011, 10h10   #5
Membre expérimenté
 
Avatar de suchiwa
 
Homme Vincent
Consultant en technologies
Inscription : avril 2010
Messages : 383
Détails du profil
Informations personnelles :
Nom : Homme Vincent
Âge : 32
Localisation : France, Paris (Île de France)

Informations professionnelles :
Activité : Consultant en technologies
Secteur : High Tech - Opérateur de télécommunications

Informations forums :
Inscription : avril 2010
Messages : 383
Points : 536
Points : 536
Citation:
Envoyé par Tawane Voir le message
SignTool Error: The specified timestamp server could not be reached.
SignTool Warning: Signing succeeded, but an error occurred while attempting to timestamp: fichier_a_signer.exe
Bonjour Tawane,

J'ai une question sur le SignTool Error, "could not be reached" indique qu'il y a un problème pour atteindre la page

Code :
1
2
signtool sign /v /f certif.pfx /p our_passwd /t http://timestamp.verisign.com/scripts/timestamp.dll fichier_a_signer.exe
As tu pinger le site, testé cette même ligne de commande avec un compte qui fonctionne (je crois que oui) ? Autoriser sous IE cette page ?

Comme le compte administrateur lui permet d'y accéder (dixit ton 1er message), on peut faire un test empirique : Ajouter ton compte utilisateur SVC_App dans les mêmes User Right Management que l'administrateur, de tester que ça fonctionne et ensuite de les retirer un par un... Je sais, c'est fastidieux car je crois qu'il faut fermer la session et la réouvrir pour prendre en compte les changements et relancer le service.

Cependant si ton timestamp est à la bonne adresse, faut s'y mettre tout de suite...

Vincent.
__________________
Dans le doute, reboot...

https://mcp.microsoft.com/authenticate/validatemcp.aspx
931584 | Micr0s0ft
suchiwa est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 03/06/2011, 21h39   #6
Invité de passage
 
Homme
Inscription : juin 2011
Messages : 1
Détails du profil
Informations personnelles :
Sexe : Homme

Informations forums :
Inscription : juin 2011
Messages : 1
Points : 1
Points : 1
Par défaut Faut faire attention

Il faut utiliser le correct URL de Verisign. Notez que timstamp.dll n'a pas de 'e'!

signtool sign /v /f certif.pfx /p our_passwd /t http://timestamp.verisign.com/scripts/timstamp.dll fichier_a_signer.exe

Meilleur regards,

Friedrich Brunzema
brunzefb est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 02h57.


 
 
 
 
Partenaires

Hébergement Web