La tâche planifiée du serveur 2016 échoue sur un modèle matériel spécifique avec l'erreur 0x8007052e

J'ai un problème étrange lié aux tâches planifiées de base de Windows qui m'a déconcerté pendant quelques semaines maintenant. Ces tâches échouent à s'exécuter sur certains serveurs, mais fonctionnent sur d'autres qui fonctionnent sur différentes plates-formes matérielles/VMs. Initialement, c'était un problème que nous avons repéré profondément au sein de l'un de nos systèmes de production, mais j'ai réussi à le simplifier pour qu'il fonctionne avec des modifications minimales par rapport à la configuration standard. En fait, j'ai créé un fichier de commandes de 5 lignes pour apporter des modifications minimales à une installation propre afin de configurer cela, pour m'assurer que chaque machine de test est identique.

La configuration

• Toutes les machines exécutent des installations fraîches de Server 2016 avec les dernières mises à jour appliquées.
• Toutes les machines résident dans la même OU sur Active Directory et ont le même ensemble de règles appliquées
• Nous créons un utilisateur local avec un mot de passe répondant aux exigences de complexité fixées par le domaine, et nous le rendons membre du groupe Administrateurs locaux
• Nous accordons à ce compte utilisateur les droits de sécurité locaux 'Ouvrir une session en mode batch' et 'Ouvrir une session en tant que service'.
• Planifier une tâche de base, s'exécutant en tant qu'utilisateur, pour ouvrir 'notepad.exe'.
• La tâche doit être configurée pour s'exécuter que l'utilisateur soit connecté ou non, et le mot de passe doit être enregistré dans la tâche.
• Toutes les machines sont images à partir de la même séquence de tâches, par le même utilisateur Administrateur.
• Toutes les tâches sont créées par le même utilisateur administrateur.

Le matériel qui fonctionne

Nous avons construit des VM sur VMware, XenServer, et sur des serveurs physiques HP et d'autres modèles de serveurs Dell (Poweredge R730, R720, R430). La plupart d'entre elles utilisent des disques SAS à rotation de 10k/15k, bien qu'un des serveurs HP que j'ai construit utilise des SSD SATA en RAID 10 à titre de test.

Le matériel qui ne fonctionne pas

Nos nouveaux serveurs posent cependant problème. Il s'agit de nouveaux Dell Poweredge R540s. Ils disposent de contrôleurs RAID 1 BOSS intégrés (pratiquement des SSD RAID 1 M.2), avec des SSD SAS comme stockage rapide supplémentaire via un contrôleur PERC.

Le problème

Avec le matériel plus ancien, vous pouvez voir la tâche planifiée fonctionner si vous la déclenchez manuellement, bien entendu vous ne voyez pas notepad s'ouvrir si elle s'exécute en tant qu'un autre utilisateur.

Cependant, sur les Poweredge R540s, la tâche échoue à démarrer, donnant le code d'erreur 2147943726 (0x8007052e). Je crois qu'il s'agit d'une erreur de type 'nom d'utilisateur inconnu ou mot de passe incorrect', malgré des identifiants corrects, et le compte utilisateur ayant été créé récemment.

Ici, vous pouvez voir l'historique de la tâche montrant l'échec de la tâche

La tâche échoue à s'exécuter manuellement, et l'événement de sécurité suivant est enregistré dans le Journal des événements Sécurité:

Nom du journal :      Sécurité
Source :        Microsoft-Windows-Security-Auditing
Date :          12/10/2018 17:30:00
ID de l'événement :      4625
Catégorie de la tâche :    Ouverture de session
Niveau :         Information
Mots clés :      Échec de l'audit
Utilisateur :        N/A
Ordinateur :      
Description :
Un compte n’a pas réussi à se connecter.

Objet :
    ID de sécurité :        SYSTÈME
    Nom du compte :       $
    Domaine du compte :     
    ID de connexion :       0x3E7

Type de connexion :         4

Compte pour lequel la connexion a échoué :
    ID de sécurité :        SID NULL
    Nom du compte :       @@CyBAAA.....
    Domaine du compte :     

Informations sur l'échec :
    Raison de l'échec :     Nom d’utilisateur inconnu ou mot de passe incorrect.
    Statut :         0xC000006D
    Sous-Statut :     0xC0000064

Informations sur le processus :
    ID du processus appelant :  0x590
    Nom du processus appelant :    C:\Windows\System32\svchost.exe

Informations sur le réseau :
    Nom du poste de travail :   
    Adresse réseau source : -
    Port source :        -

Informations détaillées sur l'authentification :
    Processus de connexion :      Advapi  
    Package d'authentification : Négocier
    Services transmis : -
    Nom du package (NTLM uniquement) :   -
    Longueur de la clé :     0

Hier, j'ai reconstruit 2x R540s, 2x VM et 1x serveur HP, et seuls les R540s ont eu ce défaut. C'est prévisible - nous avons essayé de réimager toutes nos machines de test et à chaque fois le résultat est le même.

Autres résultats pertinents

Je peux faire fonctionner les R540s correctement s'ils sont directement intégrés dans l'OU 'ordinateurs' sur AD, ce qui signifie qu'ils ne reçoivent pas notre politique de Sécurité Baseline. Les tâches s'installent et s'exécutent parfaitement. Si je déplace ensuite l'objet de l'ordinateur dans la même OU que toutes les autres machines avec lesquelles nous faisons des tests, les tâches ne fonctionnent plus. Replacer l'objet hors de l'OU dans l'OU 'ordinateurs' ne fait pas fonctionner les tâches à nouveau. Manifestement, quelque chose est modifié, mais je ne vois pas quoi, et je ne sais pas pourquoi cela n'affecterait que les R540s de cette manière et pas les VMs ou d'autres modèles de matériel.

Nous avons exporté et comparé la politique de sécurité locale sur les machines fonctionnelles et non fonctionnelles pour rechercher des différences. Les différences qui existent sont mineures, et lorsque la série de règles de sécurité fonctionnelles est importée sur une machine défectueuse, elle reste défectueuse. De même, l'importation de la série de règles de sécurité d'une machine défectueuse sur une machine fonctionnelle ne casse pas la machine fonctionnelle.

Si je modifie la tâche planifiée de manière à cocher 'Ne pas stocker le mot de passe', la tâche s'exécute, mais cela ne fonctionnera pas pour nous en production car la tâche nécessite un accès à des ressources non locales.

Si je modifie la tâche planifiée pour qu'elle s'exécute dans le contexte de mon compte administrateur de domaine (en me donnant les droits 'Ouvrir une session en mode batch' et 'Ouvrir une session en tant que service'), elle fonctionne même si 'Ne pas stocker le mot de passe' n'est pas coché. Donc, quoi que ce soit qui casse, semble être lié uniquement aux comptes utilisateur locaux.

D'autres choses que j'ai essayées et qui n'ont pas fait de différence:

• Tâche exécutée avec les privilèges les plus élevés
• Utilisateur local configuré avec 'le mot de passe n'expire pas' activé/désactivé
• Force et longueur du mot de passe de l'utilisateur local augmentée/diminuée
• Je suis passé du type de tâche 'Vista/2008 (par défaut)' à '2016' sans changement.
• J'ai vu une suggestion de passer de 'ne pas démarrer une nouvelle instance' dans la configuration de la tâche, mais cela n'a pas aidé.
• J'ai construit une autre machine physique avec un stockage SSD rapide au cas où les machines seraient imagées trop rapidement, et qu'il y aurait un genre de problème de concurrence causé par un accès plus rapide au disque sur les R540s. Je ne pense pas que ce soit le cas.
• Les pilotes, le micrologiciel et le BIOS sont tous à jour sur les R540s à partir d'hier.

La conclusion

Je pense que quelque chose doit être modifié par notre stratégie de groupe qui empêche cela de fonctionner - probablement la sécurité baseline d'une manière ou d'une autre. Ce que je suis totalement incapable d'expliquer, cependant, c'est pourquoi cela semble ne casser que le fonctionnement des tâches planifiées sur un certain modèle de matériel, qui devrait avoir des configurations identiques aux machines fonctionnelles créées en même temps, de la même manière. Je ne vois pas ce qui pourrait causer cela.

Est-ce que quelqu'un sait si les tâches planifiées ou l'authentification de base utilisent de quelque manière les fonctionnalités matérielles? Le TPM a-t-il quelque chose à voir avec cela? Y a-t-il autre chose que je puisse faire pour remonter à la source de ce qui fait échouer le compte utilisateur au moment où la tâche s'exécute? J'ai épuisé mes idées.

Aussi, au cas où quelqu'un poserait la question, j'ai essayé de faire un 'runas' à partir de l'invite de commandes pour prouver que le compte utilisateur local que j'ai créé fonctionne et que le mot de passe que j'ai utilisé est correct.

Merci!