Autorité NT \ System & SDDL Erreur

Question

Un client qui installe le progiciel de mon entreprise n'a aucun problème pour installer le progiciel en mode silencieux lorsqu'il s'exécute en tant que compte administrateur. Le logiciel et le service s'installent correctement et démarrent après l'installation. Cependant, ils doivent pousser cette application sur tous les ordinateurs d'un groupe particulier.

Ils utilisent SCCM (je ne connais pas la version) et le progiciel est un fichier .msi InstallShield .exe. Lorsqu'ils tentent d'utiliser l'utilisateur NT Authority \ System pour envoyer le package à leur périphérique de test, l'installation échoue peu de temps après la fin du package logiciel tiers inclus. Le journal des erreurs affiche qu'il s'agit d'une erreur SDDL 1943. Vous avez une idée de la raison pour laquelle cela se produirait sur le compte NTA \ System et non sur un compte d'administrateur local pour une machine donnée?

La chaîne d'installation silencieuse que nous utilisons est setup.exe/s/v "/ qn AgreeToLicense = Oui SetupType = typique"

Je ne suis pas un dev, donc je n'ai pas accès direct à un code le logiciel, simplement un support technique de niveau 3 travaillant avec les clients.

Answer 1

Des sons comme votre MSI utilisent la table MsiLockPermissionsEx pour spécifier une chaîne SDDL sur une ressource lors de son installation ou de sa configuration (fichier, répertoire, service ou entrée de registre). Soit la chaîne SDDL est mal configurée (peu probable si cela fonctionne d'un compte mais pas un autre) ou la liste de contrôle d'accès sur le répertoire/service/clé de registre cible est corrompue, ce qui n'est pas complètement inconnu.

Vous pouvez essayer d'obtenir que le client déploie un compte de domaine en tant qu'administrateur local sur les ordinateurs, puis paramétrer SCCM pour qu'il exécute le package avec ce compte. Je ne recommanderais pas cela car il comporte des risques inhérents à la sécurité. Je crains que vos développeurs (ou ceux qui ont créé le MSI) aient besoin de travailler avec les clients pour savoir quelles sont les failles et faire progresser le diagnostic.

Désolé je ne pourrais pas être d'aide supplémentaire.

Answer 2

Je pense avoir trouvé le problème. Pendant l'installation, le fichier .msi écrit un fichier sur le bureau à lire pour les paramètres de configuration du service en cours d'installation. J'ai eu le fichier (et je suis sûr que le client a fait ainsi) déjà écrit sur le bureau lorsque j'ai essayé d'appeler l'utilisateur du système pour l'installation. Cela semble être un problème d'ACL, en référence à la lecture/écriture de l'utilisateur système sur un bureau d'utilisateur local. Lorsque le fichier a été supprimé, j'ai reçu l'erreur 1406, qu'il ne pouvait pas écrire la valeur d'une clé. En regardant sur le bureau, le fichier n'a jamais été écrit sur le bureau local. Lorsque le fichier était déjà là (en tant que tel avec une installation précédente), je reçois l'erreur dans le message d'origine. À ce stade, je suis en train de tester cela comme une erreur ACL et de notifier les devs de mes conclusions.