La tâche planifiée de Server 2016 échoue sur un modèle de 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é depuis quelques semaines maintenant. Ces tâches échouent à s'exécuter sur certains serveurs, mais fonctionnent sur d'autres qui sont exécutés sur différentes plateformes 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 un minimum de changements par rapport à la configuration 'out of box'. J'ai en fait créé un fichier batch de 5 lignes pour apporter des changements minimes à une installation propre afin de le configurer, 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 appartiennent à la même OU sur Active Directory et ont le même ensemble de politiques appliqué.
• Nous créons un utilisateur local avec un mot de passe répondant aux exigences de complexité définies par le domaine, et nous le rendons membre du groupe Administrateurs local.
• Nous accordons à le compte utilisateur les droits de sécurité locaux 'Ouvrir en lot' et 'Ouvrir en service'.
• Planifier une tâche basique, 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 est 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 Admin.
• Toutes les tâches sont créées par le même utilisateur Admin.

Le matériel qui fonctionne

Nous avons construit des VMs 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 eux utilisent des disques SAS 10k/15k, bien qu'un des serveurs HP que j'ai construit utilise des SSDs SATA en RAID 10 à titre de test.

Le matériel qui ne fonctionne pas

Nos nouveaux serveurs ont cependant des problèmes. Ce sont des nouveaux Dell Poweredge R540s. Ils ont des contrôleurs RAID 1 BOSS intégrés (SSDs RAID 1 M.2 en gros), avec des SSDs SAS comme stockage rapide additionnel via un contrôleur PERC.

Le problème

Avec l'ancien matériel, vous pouvez voir la tâche planifiée s'exécuter si vous la déclenchez manuellement, bien sûr vous ne voyez pas notepad s'ouvrir en fait s'il s'exécute en tant qu'utilisateur différent.

Cependant, sur les R540s Poweredge, la tâche échoue à démarrer, donnant le code d'erreur 2147943726 (0x8007052e). Je crois que c'est une erreur de "nom d'utilisateur inconnu ou mot de passe incorrect", malgré que les informations d'identification sont correctes et que le compte utilisateur a été fraîchement créé.

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

La tâche échoue à s'exécuter manuellement, et l'événement de sécurité suivant est auditée dans le journal des événements de 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 :  Connexion
Niveau :          Informations
Mots clés :       Échec de l'audit
Utilisateur :       N/A
Ordinateur :       
Description :
Un compte a échoué à se connecter.

Sujet :
    ID de sécurité :        SYSTEM
    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'erreur :
    Raison de l'échec :     Nom d'utilisateur inconnu ou mot de passe incorrect.
    État :           0xC000006D
    Sous-état :       0xC0000064

Informations sur le processus :
    ID de 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'authentification détaillées :
    Processus de connexion :      Advapi  
    Package d'authentification :   Négociation
    Services transités :       -
    Nom du package (uniquement NTLM) :   -
    Longueur de la clé :     0

Hier, j'ai reconstruit 2 R540s, 2 VMs et 1 serveur HP, et seuls les R540s avaient 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 construits dans l'OU 'ordinateurs' sur AD, ce qui signifie qu'ils n'obtiennent pas notre politique de Sécurité de base. 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 cessent de fonctionner. Replacer l'objet en dehors de l'OU dans l'OU ordinateurs ne fait pas fonctionner à nouveau les tâches. Clairement quelque chose est modifié, mais je ne vois pas quoi, et je ne sais pas pourquoi cela affecterait uniquement les R540s de cette façon 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 qui fonctionnent et celles qui ne fonctionnent pas pour vérifier les différences. Celles qui existent sont mineures, et lorsque la politique de sécurité en place fonctionnelle est importée sur une machine défectueuse, elle reste défectueuse. De même, l'importation de la politique en place depuis une machine défectueuse sur une machine qui fonctionne ne la rend pas défectueuse.

Si je change la tâche planifiée pour que "Ne pas stocker le mot de passe" soit coché, la tâche s'exécute, mais cela ne fonctionnera pas pour nous en production car la tâche a besoin d'accéder à des ressources non locales.

Si je change la tâche planifiée pour s'exécuter dans le contexte de mon compte admin de domaine (tout en me donnant les droits 'ouvrir en lot' et 'ouvrir en service'), cela fonctionne même avec 'Ne pas stocker le mot de passe' décoché. Donc, quoi qu'il en soit que cela casse, semble être lié uniquement aux comptes d'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 des privilèges les plus élevés
• Utilisateur local avec l'option 'le mot de passe n'expirera pas' activée/désactivée
• Force et longueur du mot de passe de l'utilisateur local augmentées/diminuées
• J'ai modifié le type de tâche de 'Vista/2008 (par défaut)' à '2016' sans changement.
• J'ai vu une suggestion de passer de 'ne pas lancer une nouvelle instance' dans la configuration de la tâche, mais cela n'a pas aidé.
• J'ai construit une autre machine physique avec du stockage SSD rapide au cas où les machines s'imageraient trop rapidement, causant une sorte de condition de course due à l'accès plus rapide au disque sur les R540s. Je ne pense pas que ce soit le cas.
• Les pilotes, micrologiciels et BIOS sont tous à jour sur les R540s depuis hier.

La conclusion

Je pense que quelque chose doit être modifié par notre politique de groupe qui empêche cela de fonctionner - probablement la configuration de sécurité d'une certaine manière. Ce que je suis totalement incapable d'expliquer, c'est pourquoi cela semble uniquement casser le fonctionnement des tâches planifiées sur un certain modèle matériel, qui devraient 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 ça.

Est-ce que quelqu'un sait si les tâches planifiées ou l'authentification de sécurité de base utilise les fonctionnalités matérielles d'une quelconque manière? Est-ce qu'un TPM a quelque chose à voir avec cela? Y a-t-il quelque chose d'autre que je peux faire pour retracer 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é d'utiliser un 'runas' depuis une ligne de commande 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!