Il semble qu'il existe une stratégie de groupe qui définit les comptes auxquels on accorde le droit de se connecter en tant que service. Comme vous êtes administrateur, vous êtes autorisé à accorder ce privilège, mais lorsque la stratégie de groupe sera réappliquée, ce privilège sera supprimé. La prochaine fois que le service s'arrêtera, il ne pourra pas démarrer.
Vous devez soit modifier le champ d'application / le filtrage de la politique pour que cette machine en soit exemptée, soit utiliser la politique pour accorder le privilège nécessaire.
DES INFORMATIONS PROVENANT DES COMMENTAIRES : Pour vérifier si une stratégie de groupe applique le paramètre, utilisez l'ensemble de stratégies résultant de l'assistant de stratégie (rsop.msc).
Si vous souhaitez appliquer ce paramètre à de nombreux ordinateurs ou si vous ne pouvez pas supprimer une stratégie existante qui définit ce paramètre, utilisez la stratégie de groupe pour le définir. Il existe un article de technet qui explique comment faire.
Pour vérifier les paramètres de sécurité locaux actuels, utilisez secpol.msc - développez les stratégies locales, puis sélectionnez User Rights Assignments. Vous verrez alors les paramètres actuellement appliqués. Si vous disposez d'un accès suffisant et qu'aucune stratégie de groupe n'est en vigueur, vous pourrez modifier la stratégie actuelle. Si les boutons d'ajout et de suppression sont désactivés, cela signifie qu'une stratégie définit actuellement ce paramètre.
S'il n'y a pas de politique en vigueur, alors permettre à Windows d'accorder ce droit à l'utilisateur est parfaitement acceptable et n'est qu'une fonction de commodité fournie par Windows. Comme Jez l'a découvert, si une politique EST en vigueur, il est inutile de la combattre. La politique se réapplique généralement toutes les quelques heures et continuera à annuler tous les changements que vous avez réussi à faire. (Bien que le service continue à fonctionner jusqu'à ce qu'il s'arrête pour une autre raison). Jez a mentionné que, selon lui, un service est identifié par un LUID généré au moment de l'installation. Je ne sais pas si c'est le cas ou non, mais le droit d'utilisateur Log On As A Service n'est pas restreint à un service particulier. Il n'y a donc pas de différence entre le service sous lequel vous voulez vous connecter et celui sous lequel vous voulez vous connecter. Si vous laissez Windows attribuer le droit pour vous, vous risquez d'oublier de supprimer les comptes précédents et de vous retrouver avec une énorme liste de comptes qui ont le privilège de connexion en tant que service et qui n'en ont pas besoin.
Pour répondre un peu plus directement au commentaire de Jez, si une politique est en vigueur, il est inutile de trouver des moyens de contourner l'interface utilisateur secpol.msc désactivée. L'interface utilisateur est désactivée pour vous avertir que toute modification que vous parviendrez à effectuer ne sera pas conservée. Dans ce cas, la modification de la stratégie est la voie à suivre, soit pour accorder le privilège, soit pour cesser d'effectuer ce réglage afin qu'il puisse ensuite être attribué localement.
EDIT : Vous semblez penser que le fait d'accorder ce privilège à un utilisateur du domaine est en quelque sorte différent de celui accordé à un utilisateur local. Ce n'est pas le cas. Si le PC/Serveur en question n'a pas de stratégie de groupe appliquée, alors vous ouvrez secpol.msc, allez sur le privilège en question, double-cliquez, cliquez sur ajouter et ensuite sélectionnez le compte que vous voulez. Je viens d'essayer cela sur un ordinateur portable relié à un domaine et la boîte de dialogue d'ajout d'utilisateur a en fait choisi par défaut le domaine. Si je voulais choisir un groupe local, il faudrait que je modifie l'emplacement.
Si vous double-cliquez sur le privilège, je suppose que vous voyez la liste et les boutons d'ajout et de suppression, mais les boutons sont désactivés et vous ne pouvez pas modifier la liste. Cela ne peut pas être dû au fait que vous ajoutez un compte de domaine, car vous n'avez pas encore choisi d'ajouter un compte local ou de domaine.
J'ai rencontré exactement ce problème au travail, le service que j'installais n'allait que sur un seul PC, donc changer de politique n'était pas une option. Nous avons déplacé le PC en question dans une OU où aucune politique ne s'appliquait, et j'ai pu accorder le privilège sans problème.
La raison pour laquelle vous pouvez accorder le privilège de manière détournée est que la politique ne fait que désactiver l'interface utilisateur, elle ne modifie pas réellement les autorisations dont vous disposez. Elle se réapplique cependant périodiquement, c'est pourquoi le paramètre est écrasé.
