11
votes

Erreur MSI "L'ordinateur doit faire confiance à la délégation" causée par KB2918614

Nous avons un installateur basé sur MSI qui a récemment cessé de travailler sur un environnement Windows 2008 R2. Le programme d'installation est copié sur l'ordinateur cible à l'aide du \\ ServerName \ C $ \ admin par actions UNC, puis est exécuté à distance à l'aide de la méthode Créer sur le Classe Win32_Process . L'exécution à distance échoue maintenant avec le message d'erreur suivant dans la visionneuse d'événements:

La description de l'ID d'événement 10837 à partir de la source MSIInstaller ne peut pas être trouvé. Soit le composant qui soulève cet événement n'est pas installé sur votre ordinateur local ou l'installation est corrompu. Vous pouvez installer ou réparer le composant sur l'ordinateur local.

Si l'événement est originaire d'un autre ordinateur, les informations d'affichage devait être sauvé avec l'événement.

Les informations suivantes ont été incluses avec l'événement:

Produit: Notre nom de produit - L'opération demandée ne peut pas être completé. L'ordinateur doit faire confiance à la délégation et à la Le compte utilisateur actuel doit être configuré pour permettre la délégation .

Après avoir recherché, il semble que ceci est causé par un patch de sécurité pour Windows Installer . Quand je désinstalle KB2918614, le programme d'installation commence à travailler à nouveau, et si je réinstalle KB2918614 le MSI arrête de travailler à nouveau.

Le message d'erreur indique que pour résoudre le problème, nous devrions avoir un administrateur de domaine modifier l'ordinateur cible à l'aide de Utilisateurs et ordinateurs Active Directory pour permettre la délégation, mais le MSI n'utilise aucune ressource distante, je ne vois donc pas pourquoi cela est requis. Le même processus d'exécution MSI et à distance fonctionne correctement sur Windows Server 2012, donc je me demande s'il s'agit d'un problème avec le correctif pour 2008 R2.

Y a-t-il d'autres moyens de contourner ce message d'erreur?

update : cela ne semble pas être un problème avec l'exécution à distance WMI, car elle se produit également lorsque nous essayons d'installer les MSI à distance à l'aide de PowerShell, WinRM et le invoke-commmand -Commandername TargetComputer ... cmdlet. Il y a une modification de la manière dont l'installateur Windows sur 2008 R2 fonctionne après l'installation de KB2918614 qui empêche maintenant l'action personnalisée de terminer sa tâche.


6 commentaires

J'essaierais d'autoriser la délégation, au moins comme une expérience. Je soupçonne que le problème ne concerne pas le MSI accéder aux ressources éloignées, mais quelque chose à voir avec l'impersonnation (ou non) dans les différentes parties d'une installation. Une supposion pure, mais l'installation se déplace entre un compte d'utilisateur et le compte système lors d'une installation et peut-être dans un environnement de domaine quelque chose qui nécessite une délégation de transmettre ou du contrôleur de domaine, quelque chose comme ça de toute façon.


Eh bien, vous utilisez en fait une ressource distante, le fichier est venu d'une autre machine. Windows le connaît et stocke cette information dans un autre flux de données NTFS. Posez des questions à ce sujet à superuser.com


Nous avons conçu le MSI et espérons trouver un moyen de le réécrire pour contourner ce problème pour nos clients. J'ai vérifié si le fichier a été bloqué, mais il ne semblait pas avoir la sécurité: "Ce fichier est venu d'un autre ordinateur" ou d'une option de déblocage dans les propriétés du fichier.


Nous avons également rencontré des problèmes avec l'exécution initiale d'un MSI après l'application de cette mise à jour. J'ai parlé avec un représentant de Microsoft aujourd'hui qui a déclaré que c'était un problème connu. Il m'a dit qu'ils espèrent avoir un patch supplémentaire qui la corrige quelque part dans la plage de temps de mi octobre à début novembre.


Des progrès sur cela? Je me demande si nous voyons un problème similaire sur les serveurs R2 2012.


J'ai suivi avec Microsoft aujourd'hui et ils m'ont dit que la solution trouvée ici devrait résoudre le problème: support2.microsoft. com / kb / 3000988 . Cependant, je vois que dans une réponse ci-dessous qui est à la fois voté. Quelqu'un a-t-il appliqué ce correctif et n'avait-il pas de travail pour eux?


9 Réponses :


1
votes

Je rencontre aussi le problème. J'ai eu un script PowerShell pour installer MSI sur des machines distantes (à l'aide de la cmdlet Invoke-Command et fournissez les informations d'identification avec le script), mais tout à coup, il n'a pas réussi à installer MSI que je suppose également de ce correctif de sécurité.
Après avoir exécuté le fichier d'installation MSI manuellement sur la machine cible à l'aide du compte de domaine (à partir du bureau à distance), le script PowerShell peut soudainement exécuter l'installation MSI à l'aide de compte de domaine, mais n'a toujours pas réussi à installer si j'ai utilisé le compte administrateur local de la machine ciblée.
Je préfère ajouter ceci comme un commentaire, mais je n'ai pas assez de représentant pour le faire. Si l'autre ait une solution ou une explication à cela, j'aimerais aussi le savoir. Merci.


0 commentaires

0
votes

réponse de Microsoft: Cette mise à jour de sécurité résout une vulnérabilité divulguée en privé dans Microsoft Windows. La vulnérabilité pourrait permettre une élévation du privilège si un attaquant exécute une application spécialement conçue qui tente de réparer une application précédemment installée. Un attaquant doit avoir des informations d'identification valides de connexion et être capable de se connecter localement pour exploiter cette vulnérabilité.

Solution de contournement Si vous avez des problèmes d'application de réparation:
  1. désinstaller l'application et réinstallez-la avec la mise à jour de sécurité installée. (Fichier SourceHash généré avec mise à jour de sécurité)

  2. Copiez manuellement le fichier SourceHash dans le dossier C: \ Windows \ installateur. Comme le fichier SourceHash est généré en fonction des fichiers d'application, le fichier sourcehash généré sur ordinateur A peut être utilisé sur ordinateur b.

  3. http://happysccm.com/kb2918614-uac-gate/ - Commandes de le désinstaller.


1 commentaires

Veuillez inclure les commandes requises dans la réponse elle-même. La liaison pour des informations supplémentaires est autorisée, mais fronça les sourcils lors de la divulgation d'un lien direct vers l'autre partie. Mais assurez-vous que chaque réponse elle-même est entièrement autonome.



5
votes

de ce que je comprends,

avec KB2918614, MS a apparemment essayé de réparer quelque chose dans le service d'installateur Windows.

Nouveaux trucs:
  • Ils créent un fichier par nom "SourceHash {produit-guid}" sous % Windir% \ Windows \ installateur. Ceci est fait pour chaque produit installé sur la machine (avec KB2918614 déjà installé).
  • Secrepair - Ils calculent "valeur hachage stockée" et "Hash actuel" pour un MSI donné.

    ERREUR:
    1. et, dans cette comparaison, pour une raison quelconque, ces inadéquations! (Trouvés ceux-ci dans les journaux verbeux MSI).

    2. Une fois que cela échoue, il cherche Valeur de la politique de la machine 'toujours incalculé' Valeur de la stratégie d'utilisateur "toujours à l'encombrement"

    3. Maintenant, si vous exécutez une installation silencieuse "qn", cette erreur est lancée: MSI_LUA: Invite d'altitude désactivée pour les installations silencieuses.

    4. Élimination de l'option CMDLine d'installation silencieuse pour MSIExec- ex., "QR" ou "QB", lancera une invite de l'UAC. (ce qui ne sera probablement pas le comportement attendu).

      Info supplémentaire:

      Mon MSI est ivkodé à travers un exe Bootstrapper. Mais cela n'a pas vraiment d'importance. Même un appel manuel à Msiexec via CMD Line se comporte de la même manière.

      Toute entrée / solutions, n'importe qui?


0 commentaires

1
votes

Ceci doit être à voir avec le SourceHash {Code de produit} Fichiers sous \ Windows \ installateur. Ce fichier peut être ouvert avec ORCA, vous pouvez lire le contenu. Il contient un nom de fichier, un spécificateur d'algorithme de hachage et un hachage. Sous Windows 2K3, ce hachage est un hachage SHA256 BASE64ED avec le dernier octet changé.

Si vous Renommez le fichier SourceHash pour votre produit hors de la manière , j'ai trouvé la mise à niveau travaillée et après avoir généré un nouveau fichier SourceHash. Vous pouvez ensuite diffuser les deux fichiers de hachage source. Dans le cas où je suis en train d'enquêter, lorsque vous diffusez les deux fichiers que seul le hash répertorié pour le MSI d'origine est différent. Après une mise à niveau réussie, le hachage de la nouvelle MSI répertorié dans le fichier de hachage source correspondra à celui de la source d'installation. Le fichier brisé SourceHash a évidemment été généré à partir d'une source modifiée / différente MSI, bien que je n'ai pas encore été incapable d'identifier lequel.


0 commentaires

3
votes

Ceci est le mot de la MS Enterprise Support Folks.

Apparemment, ils ne sont au courant d'aucune solution à cela. Au moins à ce jour maintenant. Tout ce qu'ils disent que cette KB est de corriger une échappatoire de sécurité. Je ne comprends pas quel type de sécurité corrigé cela est-un, qui permet une nouvelle installation sans une invite de l'UAC, mais jette une invite de l'UAC uniquement pour la mise à niveau.

Solution de contournement 1: distribution hachage.

Capturez le fichier de hachage * dans une machine et distribuez-les à d'autres machines. Les fichiers de hachage sont créés sous le répertoire "% Windir% \ installateur". La convention de dénomination est la suivante: "SourceHash * Ce fichier est créé uniquement lorsqu'un produit est installé avec KB2918614 installé sur la machine. Ce répertoire est caché. Ouvrez l'invite CMD à l'aide de 'Exécuter en tant qu'administrateur'. Traverser sur ce chemin et ouvrez le dossier en utilisant "Explorateur". commander. [Je n'ai pas pu résoudre le problème à l'aide de cette approche - peut être parce que l'accès à cet annuaire nécessite des privilèges d'administrateur que l'installateur Windows lui-même n'a peut-être pas]

Solution de contournement 2: whitelisting.

Seulement si vous faites confiance à l'application qu'il est toujours signé numériquement et ne contient rien de malveillant (même à l'avenir).

Étape 1: Activez la blanchissante

sous clé "HKLM \ Software \ Stratégies \ Microsoft \ Windows \ installateur", créez un DWORD: "SecurePairpolicy" et définissez sa valeur sur 2.

Étape 2: Ajoutez l'application à la liste blanche

Créer une nouvelle clé "SecureRePairwhitelist" sous "HKLM \ Software \ Stratégies \ Microsoft \ Windows \ installateur" et créez StringValues ​​avec les codes de produit (y compris les crochets de fleurs {}) du produit.

... Malheureusement, ces deux solutions de contournement ont besoin de privilèges d'administration!


3 commentaires

Merci M. DebugBreak! Cela me rendait vraiment un peu chauffé. Apparemment, le patch est de toute façon révisé afin que nous (espérons-le) ne pas avoir à vis à vis avec ce truc.


Bienvenue. Oui, c'est plutôt mauvais pour les développeurs. Les utilisateurs finaux peuvent en quelque sorte travailler leur chemin. Une suggestion: Si réalisable: lorsqu'un scénario de mise à niveau est rencontré, désinstallez le produit et faites une nouvelle installation.


J'ai essayé de distribuer le hachage, mais le MSI le supprimait et tente de la recréer que l'échec se produisait pendant la récréation. Je ne pouvais pas non plus avoir de whitelisting au travail. La clé d'installateur était manquante, puis j'ai essayé d'utiliser Psexec -S et cela a fonctionné. Le whitelisting est répertorié comme une solution de contournement sur MSDN: support.microsoft.com/en-us/ KB / 2918614



1
votes

J'ai le même problème. MSIS n'a pas pu être installé avec Invoke-Command posh. J'ai constaté que si j'installez des MSI sur le serveur sur le serveur localement sous le même compte utilisé pour invoke-commande, le problème est fixé et que l'invocation-commande commence à fonctionner comme d'habitude.


0 commentaires

3
votes

Voici ma façon automatique d'utiliser le travail Whitelist de registre mentionné mentionné sur le site de Microsoft.

Maintenant, avant d'exécuter ma commande d'installation sur une machine distante, je regarde le MSI et extrayez le code produit avec Get-ProductCodeFROMFROMSI , puis utilisez Add-Guidowowhitelist pour ajouter chaque GUID à la liste sur cet ordinateur. Voici un exemple: p>

Function Test-SecureRepairPolicy{
    param (
        [Parameter(mandatory=$true,ValueFromPipelineByPropertyName=$true)][string[]]
        # Specifies the computer name to connect to
        $ComputerName
    )

    Process {
        foreach ($Computer in $ComputerName)
        {
            #Open Remote Base
            $reg=[microsoft.win32.registrykey]::OpenRemoteBaseKey('LocalMachine',$Computer)
            #Get Windows key
            $subkey = $reg.OpenSubKey("SOFTWARE\Policies\Microsoft\Windows")
            $subkeynames = $subkey.GetSubKeyNames()
            if (($subkeynames | Measure-Object).Count -lt 1){
                return New-Object -type PSObject -Property @{
                    Success = $False
                    Note = "Can not open base key"
                    ComputerName = $Computer
                }
            }
            if ($subkeynames -notcontains "Installer"){
                return New-Object -type PSObject -Property @{
                    Success = $False
                    Note = "Can not locate installer subkey"
                }
            }
            $subkey.Close();$subkey = $null
            $subkey = $reg.OpenSubKey("SOFTWARE\Policies\Microsoft\Windows\Installer")
            $subkeynames = $subkey.GetSubKeyNames()
            if ($subkeynames -notcontains "SecureRepairWhitelist"){
                return New-Object -type PSObject -Property @{
                    Success = $False
                    Note = "Can not locate repairlist subkey"
                    ComputerName = $Computer
                }
            }
            $repairvalue = $subkey.GetValue("SecureRepairPolicy")
            if ($repairvalue -ne 2){
                return New-Object -type PSObject -Property @{
                    Success = $False
                    Note = "SecureRepairPolicy is incorrect"
                    ComputerName = $Computer
                }
            }
            $subkey.Close();$subkey = $null;$reg.Close();$reg = $null
            return New-Object -type PSObject -Property @{
                Success = $True
                Note = "SecureRepairPolicy structure is in place"
                ComputerName = $Computer
            } 
        }
    }
}

Function Repair-SecureRepairPolicy{
    param (
        [Parameter(mandatory=$true,ValueFromPipelineByPropertyName=$true)][string[]]
        # Specifies the computer name to connect to
        $ComputerName

    )
    Begin{
        Function Add-RemoteRegistryKey($Computer,$Parent,$Name){
            $reg=[microsoft.win32.registrykey]::OpenRemoteBaseKey('LocalMachine',$Computer)
            $subkey = $reg.OpenSubKey($Parent, $true)
            $subkey.CreateSubKey($Name)
            $subkey.Close();$subkey = $null;$reg.Close();$reg = $null
        }
        Function Add-InstallerKey($Computer){
           Add-RemoteRegistryKey $Computer "SOFTWARE\Policies\Microsoft\Windows" "Installer" 
        }
        Function Add-RepairPolicy($Computer){
            $reg=[microsoft.win32.registrykey]::OpenRemoteBaseKey('LocalMachine',$Computer)
            $subkey = $reg.OpenSubKey("SOFTWARE\Policies\Microsoft\Windows\Installer", $true)
            $subkey.SetValue("SecureRepairPolicy",2, "DWORD")
            $subkey.Close();$subkey = $null;$reg.Close();$reg = $null
        }
        Function Add-WhitelistKey($Computer){
            Add-RemoteRegistryKey $Computer "SOFTWARE\Policies\Microsoft\Windows\Installer" "SecureRepairWhitelist"
        }

    }
    Process {
        foreach ($Computer in $ComputerName)
        {
            $audit = Test-SecureRepairPolicy $computer
            if ($audit.Success){
                Write-Output "Repair whitelist keys setup.  No repair being performed."
            }
            else{
                Write-Output "Repair whitelist keys not setup.  Attempting to resolve"
                 if ($audit.Note -match "Can not open base key"){
                    Write-Error "Unable to open computer's registry key"
                    return
                 }
                 if ($audit.Note -match "Can not locate installer subkey"){
                    Add-Installerkey $Computer
                    Add-RepairPolicy $Computer
                    Add-WhitelistKey $Computer
                 }
                 if ($audit.Note -match "Can not locate repairlist subkey"){
                    Add-RepairPolicy $Computer
                    Add-WhitelistKey $Computer
                 }
                 if ($audit.Note -match "Can not locate repairlist subkey"){
                    Add-RepairPolicy $Computer
                 }
                 Write-Output "Showing new audit"
                 Test-SecureRepairPolicy $computer
            }
        }
    }
}

Function Add-GUIDtoWhiteList{
    param (
        [Parameter(mandatory=$true,ValueFromPipelineByPropertyName=$true)][string[]]
        # Specifies the computer name to connect to
        $ComputerName,
        [Parameter(mandatory=$true)][string[]]
        # Specifies the GUID(s) to add.
        $GUIDs
    )

    Process {
        foreach ($Computer in $ComputerName)
        {
            #Open Remote Base
            $reg=[microsoft.win32.registrykey]::OpenRemoteBaseKey('LocalMachine',$Computer)
            $subkey = $reg.OpenSubKey("SOFTWARE\Policies\Microsoft\Windows\Installer\SecureRepairWhitelist", $true)
            foreach($GUID in $GUIDs){
                $subkey.SetValue($GUID,"", "String")
            }
            $subkey.Close();$subkey = $null;$reg.Close();$reg = $null
        }
    }
}

Function Get-ProductCodefromMSI ($msi){
    [Reflection.Assembly]::LoadFrom("D:\scripts\lib\Microsoft.Deployment.WindowsInstaller.dll") | out-null
    (New-Object -TypeName Microsoft.Deployment.WindowsInstaller.Database -ArgumentList $msi).ExecuteQuery("SELECT Value FROM Property WHERE Property = 'ProductCode'")
}


0 commentaires

0
votes

J'avais aussi cela sur différents serveurs. Après quelques heures de creuser, j'ai découvert qu'ils ne pouvaient pas atteindre les contrôleurs de domaine. Vérifiez vos paramètres DNS et assurez-vous qu'elles peuvent atteindre l'annonce. Après avoir réparé cela, cette erreur a disparu.


0 commentaires

0
votes

Si vous exécutez via PSEXEC, il suffit d'ajouter que l'argument de l'est également résolue l'erreur. Ensuite, il est couru comme l'utilisateur du système distant et l'UAC n'est pas requis.


0 commentaires