Discussion :

[Luc1an0]

Bonjour à toutes et tous,

Je sens déjà que certains vont me dire que le sujet a été abordé un milliard de fois, d'ailleurs je connais la réponse à mon problème. Du moins je connais une réponse possible et malheureusement ce n'est pas celle là que je cherche.

Je suis en train de développer un programme qui tournera en tant que service sur du windows 2000/XP voir meme 2003. J'utilise les outils "instsrv" et "srvany" du "Resource kits" pour installer mon application en tant que service.

Pour le déploiement je travaille en ce moment sur un fichier de commande windows, dont voici les étapes :
- création d'un nouvel user
NET USER MonUser MonPass /EXPIRES:NEVER /PASSWORDCHG:NO
- Ajout de cet user dans le groupe admin :
NET LOCALGROUP Administrateurs MonUser /ADD
- Retrait de l'user du groupe Utilisateurs
NET LOCALGROUP Utilisateurs MonUser /DELETE

Ensuite je lance la commande d'install de mon service avec "instsrv"
INSTSRV MonService x:\Chemin\d\acces\de\l\application -a .\MonUser -p MonPass

Tout se passe bien, sauf que j'ai la traditionelle erreur 1069 due à une impossibilité d'ouvrir la session. La manipulation "manuelle" je la connais...
Je voudrais pouvoir attribuer le privilège à cet user de démarrer une session en tant que service. Le tout en ligne de commande car ce déploiement sera sur beaucoup de machines, donc faire des "clic" dans la console MMC, non merci.

Sinon j'ai aussi vu que "SC" offrait les memes possibilités (et plus encore en fait) que "instsvr"/"srvany". Ca m'a l air plus "propre" comme méthode de fonctionnement, mais même erreur

Merci de votre attention

[Luc1an0]

Je continu de poursuivre mes recherches car je pense que ça peut intéresser certains d'entre vous.

Mon ancien professeur d'administration Windows m'a conseillé d'utiliser l'utilitaire "subinacl". Il permet entre autre l'attribution de privilèges diverse et variés. Il faudra tout de même télécharger la dernière version de cet utilitaire car la version distribuée sur Windows ne fonctionne pas correctement.

J'ai continué aussi certaines manipulations comme l'installation du service "en tant que" mon utilisateur créé avec la commande RUNAS. D'ailleurs si quelqu'un sait pourquoi l'automatisation ne marche pas je suis prenneur :
J'écris le mot de passe dans un fichier puis j effectue cette commande

RUNAS /profile /user:Machine\User "Commande d'installation de mon service" < X:\fichier\avec\le\pass

Cette opération marche dans certains cas où le prompt demande une information (oui/non par exemple), mais dans ce cas là, non.

J'ai aussi essayé de donner tous les droits à mon user sur le service, et je l'ai aussi rendu propriétaire avec SUBINACL. Toujours pareil...

[Luc1an0]

Bon et bien je vais finir par me répondre moi même.
J'ai finis par trouver une solution, hélas encore manuelle, pour autoriser un utilisateur à ouvrir une session en tant que service.

Panneau de configuration >> Outils d'administration >> Stratégie de sécurité locale.

Dans la MMC, branche Stratégie locale >> Attributions des droits utilisateurs >> Ouvrir une session en tant que service.

Propriétés de la stratégie, puis rajouter l'utilisateur concerné.

C'est pas mal, Mais maintenant si quelqu'un sait comment le faire en ligne de commande... Je vois bien un secedit pour manipuler, mais je suis pas assez calé pour çà

[Luc1an0]

Bonsoir à tous, voila ma recherche touche à sa fin et comme promis je viens poster ma réponse

Pour pas ne pas reprendre les différents éléments, je vais juste expliquer comment autoriser un utilisateur à pouvoir démarrer un service de ses pleins droits, en utilisant la ligne de commande.

Pour Windows 2003 Server, la méthode n'est pas dur car les stratégies locales sont stockées au sein de fichier de données sdb. L'utilitaire "secedit" peut alors suffire dans la version livrée avec le système.

Pour les version XP, ces données ne sont pas stockées de la mème manière. Elles pourraient être injectées directement dans le registre, mais je ne suis pas allé jusque là. Il faut se munir d'un correctif fournit à la demande auprès de Microsoft.
Pour les curieux, lire cet article sur la différence des fonctionnements.
Le correctif en question est : WindowsXP-KB897327-x86-FRA.exe

La manip à faire est d'abord d'exporter la configuration de cette branche :
secedit /export /cfg x:\Chemin\d\un\fichier.ini /areas USER_RIGHTS
Vous obtenez un fichier :
[Unicode]
Unicode=yes
[Privilege Rights]
SeNetworkLogonRight = *S-1-1-0,Administrateurs,Utilisateurs,Utilisateurs avec pouvoir,Opérateurs de sauvegarde
SeBackupPrivilege = Administrateurs,Opérateurs de sauvegarde
SeChangeNotifyPrivilege = *S-1-1-0,Administrateurs,Utilisateurs,Utilisateurs avec pouvoir,Opérateurs de sauvegarde
SeSystemtimePrivilege = Administrateurs,Utilisateurs avec pouvoir
SeCreatePagefilePrivilege = Administrateurs
SeDebugPrivilege = Administrateurs
SeRemoteShutdownPrivilege = Administrateurs
SeAuditPrivilege = *S-1-5-19,*S-1-5-20
SeIncreaseQuotaPrivilege = *S-1-5-19,*S-1-5-20,Administrateurs
SeIncreaseBasePriorityPrivilege = Administrateurs
SeLoadDriverPrivilege = Administrateurs
SeBatchLogonRight = SUPPORT_388945a0
SeServiceLogonRight = Administrateur
SeInteractiveLogonRight = Invité,Administrateurs,Utilisateurs,Utilisateurs avec pouvoir,Opérateurs de sauvegarde
SeSecurityPrivilege = Administrateurs
SeSystemEnvironmentPrivilege = Administrateurs
SeProfileSingleProcessPrivilege = Administrateurs,Utilisateurs avec pouvoir
SeSystemProfilePrivilege = Administrateurs
SeAssignPrimaryTokenPrivilege = *S-1-5-19,*S-1-5-20
SeRestorePrivilege = Administrateurs,Opérateurs de sauvegarde
SeShutdownPrivilege = Administrateurs,Utilisateurs,Utilisateurs avec pouvoir,Opérateurs de sauvegarde
SeTakeOwnershipPrivilege = Administrateurs
SeDenyNetworkLogonRight = SUPPORT_388945a0
SeDenyInteractiveLogonRight = SUPPORT_388945a0,Invité
SeUndockPrivilege = Administrateurs,Utilisateurs,Utilisateurs avec pouvoir
SeManageVolumePrivilege = Administrateurs
SeRemoteInteractiveLogonRight = Administrateurs,Utilisateurs du Bureau à distance
SeImpersonatePrivilege = Administrateurs,*S-1-5-6
SeCreateGlobalPrivilege = Administrateurs,*S-1-5-4,*S-1-5-6
[Version]
signature="$CHICAGO$"
Revision=1


Travaillez ensuite les informations avec le code que vous voulez pour obtenir ça :

[Unicode]
Unicode=yes
[Privilege Rights]
SeServiceLogonRight = Administrateur,votreUtilisateur
[Version]
signature="$CHICAGO$"
Revision=1

Ensuite réimporter cette stratégie :
secedit /configure /db secedit.sdb /cfg x:\chemin\du\fichier.ini

Avec tout ça je n'ai pas retenu cette stratégie. Trop d'inconvénients.
J'utiliserai NSIS.

Si un modérateur estime que la question peut faire l'affaire d'une "question/réponse" dans la FAQ, qu'il me le dise en PM.

Bonne soirée.

[fkuchta]

Salut !

Je réponds à ce post, ayant moi-même cherché la meilleure solution.

J'ai choisi NTRights.
Cet utilitaire est disponible dans le "Windows Resource Kit Tools" officiel de Microsoft. Perso, j'ai utilisé et testé celui de Windows 2003, mais ce n'est évidemment pas le plus récent :
http://www.microsoft.com/download/en....aspx?id=17657


Celui-ci fonctionne parfaitement sur Windows XP, Windows Vista et Windows 7, en plus des serveurs à compter de Windows 2003.

Une fois le "Windows Resource Tools" installé, il suffit de récupérer le logiciel ici sur son poste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

%PROGRAM FILES%\Windows Resource Kits\Tools\ntrights.exe

A noter que c'est un .exe standalone, il n'a pas besoin d'autre chose pour fonctionner.


Exemple de syntaxe qui donne le droit de se connecter en tant que service au login courant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ntrights +r SeServiceLogonRight -u %USERDOMAIN%\%USERNAME%

Bon codage à tous !

Fabrice, Toulouse