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

Je rencontre un problème étrange lié aux tâches planifiées de base de Windows qui me laisse perplexe depuis quelques semaines maintenant. Ces tâches échouent à s'exécuter sur certains serveurs, mais fonctionnent sur d'autres, qui tournent sur des plateformes matérielles/VMs différentes. Initialement, c'était un problème que nous avons repéré au cœur de l'un de nos systèmes de production, mais j'ai réussi à le simplifier pour le faire fonctionner avec des modifications minimales par rapport à la configuration "sortie de l'emballage". J'ai en fait créé un fichier batch de 5 lignes pour apporter des modifications minimales à 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 se trouvent dans la même OU sur Active Directory, et ont le même ensemble de règles 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 plaçons dans le groupe Administrateurs locaux.
• Nous accordons à ce compte utilisateur les droits de sécurité locaux 'Se connecter en tant que lot' et 'Se connecter en tant que 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 imaginées à 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 de 10k/15k tr/min, bien qu'un des serveurs HP que j'ai construit utilisait des SSD SATA en RAID 10 à titre de test.

Le matériel qui ne fonctionne pas

En revanche, nos nouveaux serveurs posent problème. Ce sont de nouveaux Dell Poweredge R540s. Ils sont équipés de contrôleurs RAID 1 BOSS intégrés (des SSD RAID 1 M.2 essentiellement), avec des SSD SAS pour un stockage rapide supplémentaire 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, même si vous ne voyez évidemment pas le bloc-notes s'ouvrir si elle s'exécute en tant qu'utilisateur différent.

Sur les Poweredge R540s en revanche, la tâche échoue à démarrer, renvoyant le code d'erreur 2147943726 (0x8007052e). Je pense que c'est une erreur d''utilisateur inconnu ou de mot de passe incorrect', malgré des identifiants corrects, et que le compte utilisateur ait é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é 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 :         Information
Mots-clés :      Échec de l'audit
Utilisateur :        N/D
Ordinateur :      
Description :
Un compte a échoué à se connecter.

Sujet :
    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 réseau :
    Nom de la station de travail :   
    Adresse réseau source : -
    Port source :        -

Informations d'authentification détaillées :
    Processus de connexion :       Advapi  
    Package d'authentification : Negotiate
    Services transmis : -
    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 présentaient 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 à 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 ordinateur dans la même OU que toutes les autres machines avec lesquelles nous effectuons des tests, les tâches cessent de fonctionner. Replacer l'objet hors de l'OU vers l'OU 'ordinateurs' ne fait pas fonctionner les tâches de nouveau. Il est clair que quelque chose est modifié, mais je ne vois pas quoi, et je ne sais pas pourquoi cela n'impacte que les R540s de cette manière et pas les VMs ou les 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 détecter des différences. Celles qui existent sont mineures, et lorsque le jeu de politiques fonctionnel est importé sur une machine défaillante, elle reste défectueuse. De même, importer le jeu de politiques d'une machine défaillante sur une machine fonctionnelle ne dérange pas la machine en état de marche.

Si je configure 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 configure la tâche planifiée pour s'exécuter en contexte de mon compte admin de domaine (en me donnant les droits 'se connecter en tant que lot' et 'se connecter en tant que service'), cela fonctionne même si 'Ne pas stocker le mot de passe' n'est pas coché. Donc, quoi qu'il en soit qui empêche, il semble que cela soit lié uniquement aux comptes utilisateurs locaux.

D'autres choses que j'ai essayées et qui n'ont pas fonctionné:

• Tâche exécutée avec les privilèges les plus élevés
• Activation/désactivation de 'le mot de passe n'expire pas' pour l'utilisateur local
• Augmentation/diminution de la force et de la longueur du mot de passe de l'utilisateur local
• J'ai changé le type de tâche de 'Vista/2008 (par défaut)' à '2016' sans effet.
• 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 étaient image trop rapidement, et qu'il puisse y avoir un genre de condition de course causée par l'accès plus rapide au disque sur les R540s. Je ne pense pas que ce soit le cas.
• Les drivers, le firmware 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 politique de sécurité d'une certaine manière. Ce que je ne parviens absolument pas à expliquer, cependant, c'est pourquoi cela semble uniquement bloquer le fonctionnement des tâches planifiées sur un certain modèle de matériel, qui devrait avoir des configurations identiques aux machines de travail 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 sécurité de base utilisent en quelque sorte les fonctionnalités matérielles? Le TPM y est-il pour quelque chose? Y a-t-il autre chose que je peux faire pour remonter à ce qui cause l'échec du compte utilisateur au moment de l'exécution de la tâche? J'ai épuisé mes idées.

Aussi, au cas où quelqu'un le demanderait, j'ai essayé de faire un 'runas' à partir d'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!