Est-il possible pour une tâche planifiée de s'exécuter en tant que SERVICE RÉSEAU?


11

Il est assez simple de configurer une tâche pour qu'elle s'exécute en tant que SYSTÈME, mais lorsque vous la définissez sur SERVICE RÉSEAU, elle affiche le message d'erreur «Accès refusé».

Existe-t-il un moyen de faire fonctionner cela? (Le problème est que je ne veux pas créer un nouvel utilisateur de domaine pour cette tâche et j'ai besoin d'accéder à un partage distant à partir de cette tâche.)

Réponses:


13

J'ai posé cette même question . Heureusement, RyanRies a pu fournir une réponse correcte .

Dans Windows Server 2003, vous ne pouvez pas exécuter une tâche planifiée en tant que NT AUTHORITY\NetworkService(alias le compte Service réseau ). Cette fonctionnalité n'a été ajoutée qu'avec le Planificateur de tâches 2.0, qui n'existe que dans Windows Vista / Windows Server 2008.

Bonus Chatter

  • Le compte LocalService est un compte intégré avec des privilèges limités sur l'ordinateur local et accède au réseau de manière anonyme . Vous devez utiliser ce compte pour exécuter vos tâches planifiées
  • Le compte NetworkService est un compte intégré avec des privilèges limités sur l'ordinateur local et accède au réseau en tant que machine (par exempleVADER$). Vous pouvez utiliser ce compte pour exécuter vos tâches planifiées si vous avez besoin d'un accès réseau authentifié
  • Le compte LocalSystem est un compte intégré avec des privilèges étendus sur l'ordinateur local. Vous ne devez jamais utiliser ce compte pour exécuter des tâches planifiées

6

Tu ne peux pas. La fonctionnalité a été introduite dans Task Scheduler 2.0, ce qui signifie Vista / 2008 +.

Dans la documentation de Schtasks.exe:

/ Nom d'utilisateur RU

Valeur qui spécifie le contexte utilisateur sous lequel la tâche s'exécute. Pour le compte système, les valeurs valides sont "", "NT AUTHORITY \ SYSTEM" ou "SYSTEM". Pour les tâches du Planificateur de tâches 2.0, «NT AUTHORITY \ LOCALSERVICE» et «NT AUTHORITY \ NETWORKSERVICE» sont également des valeurs valides.

http://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx :


Il est très utile que le document mentionne spécifiquement le Planificateur de tâches 2.0. Il élimine les conjectures.
Ian Boyd

2

J'ai essayé de le faire de plusieurs manières, mais maintenant je ne pense pas que ce soit possible. Je serais heureux de me corriger sur ce point , mais j'ai essayé tout ce que je pouvais penser, y compris l' ajout NETWORK SERVICEà Administrators, peaufinage toutes sortes de paramètres de stratégie de sécurité locale, etc.

Lorsque j'active l'audit, j'obtiens ceci:

Event Type:     Failure Audit
Event Source:   Security
Event Category: Account Logon 
Event ID:       680
Date:           02/03/2010
Time:           8:49:53 PM
User:           NT AUTHORITY\SYSTEM
Computer:       RESULTANT
Description:
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 Logon account:  NETWORK SERVICE
 Source Workstation: RESULTANT
 Error Code: 0xC0000064

Event Type:     Failure Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:       529
Date:           02/03/2010
Time:           8:49:53 PM
User:           NT AUTHORITY\SYSTEM
Computer:       RESULTANT
Description:
Logon Failure:
     Reason:        Unknown user name or bad password
     User Name:     NETWORK SERVICE
     Domain:        NT AUTHORITY
     Logon Type:    4
     Logon Process: Advapi  
     Authentication Package: Negotiate
     Workstation Name:       RESULTANT

0xC0000064décode en NO_SUCH_USER. C'est un peu idiot, étant donné que je ne suis entré que network service- comment savait-il que le compte qui avait échoué était dans NT AUTHORITY?

Lorsque j'entre un nom d'utilisateur invalide, je ne vois même pas du tout la tentative d'authentification. Il est donc clair que quelque chose convient qu'il NETWORK SERVICEs'agit d'un compte réel.

Si j'embrouille le mot de passe d'un nom d'utilisateur connu (ie Administrator), j'obtiens 0xC000006A( STATUS_WRONG_PASSWORD).


Essayez d'ajouter le Log on as a batch jobdroit à NETWORK SERVICE. Je pense que c'est une idée idiote; vous devriez juste mordre la balle et créer un compte de domaine…


Désolé d'avoir mal tapé dans mon commentaire précédent à Matt, mais j'ai essayé de l'ajouter pour "Se connecter en tant que travail par lots" et sans succès.
Regent

0

Essayez d'ajouter le droit «Se connecter en tant que service» au compte de service réseau. Instructions détaillées ici.


Nan. Il était déjà répertorié dans "Se connecter en tant que service", et l'ajout à "Se connecter en tant que service" n'a pas aidé non plus.
Regent

0

Je veux juste relancer ce fil car il est possible d'utiliser NETWORK SERVICE pour les tâches! Au moins sur Server 2016 et 2019!

Juste une petite bizarrerie après avoir sélectionné le compte de la manière habituelle. En dessous de

Run whether user is logged on or not

Vous devez confusément sélectionner:

Do not store the password. The task will only have access to local computer resources

La deuxième partie doit être prise avec une pelle pleine de sel! Ce que cela signifie ici, c'est que vous n'avez pas d' informations d' identification , mais si vous exécutez quelque chose qui n'a pas besoin du compte pour avoir des informations d'identification, il A accès au réseau!

Exportation d'un travail, la partie principale ressemble à ceci

  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-20</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>

Je l'utilise pour envoyer des messages d'état via smtp, et il contacte très bien le serveur smtp


-1

Le service réseau est un compte local (ordinateur). Il n'aura donc jamais de droits sur un autre ordinateur (où réside le partage).

Si vous souhaitez accéder à un partage en réseau, vous devez utiliser un compte connu sur le réseau, utilisez donc un compte de domaine. Et le service que vous souhaitez exécuter DOIT prendre en charge l'adressage UNC. S'il a besoin d'un accès à une lettre de lecteur réseau, vous avez besoin d'une session utilisateur avec des lecteurs mappés, sinon cela échouera également.

(Je suppose que vous le savez déjà, en regardant la date de votre message. Ma réponse est juste un supplément pour les personnes qui trouveront ce message avec un problème similaire)

Kees


2
Chaque ordinateur joint au domaine possède son propre compte dans Active Directory. Et si je comprends bien, il NETWORK SERVICEs'agit d'un alias local de ce compte, il pourrait donc potentiellement avoir accès à certains partages.
Regent

1
NetworkService aura des droits sur un autre ordinateur. De MSDN : «Il a des privilèges minimum sur l'ordinateur local et agit comme l'ordinateur sur le réseau.»
Ian Boyd

Cette réponse est incorrecte. Comme @IanBoyd le dit également, NETWORK SERVICE est spécifiquement destiné à accéder aux éléments sur le réseau (c'est pourquoi il a "Network" dans le nom, contrairement au compte LOCAL SERVICE) auquel il accédera en utilisant l'identité de domaine de l'ordinateur, DOMAIN \ COMPUTERNAME $, par exemple, MAIN \ WEBSRV2 $.
Nick Jones

Ce n'est pas non plus un compte (local ou autre). C'est un principe de sécurité bien connu.
Falcon Momot
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.