VMware Workstation et Device / Credential Guard ne sont pas compatibles

J'utilise VMware depuis un an sans problème, aujourd'hui je l'ai ouvert pour démarrer une de mes VM et obtenir un message d'erreur, voir capture d'écran.

J'ai suivi le lien et suis passé par les étapes, à l'étape 4, j'ai besoin de monter un volume en utilisant "mountvol". quand j'essaie de monter un volume en l'utilisant, mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\je répète que The directory is not empty.j'ai même créé une partition avec 2 Go et toujours le même message.

Mes questions:

Comment puis-je monter le volume qui n'est pas vide alors qu'il l'est?

Pourquoi ce périphérique / Credential Guard s'est-il activé automatiquement et comment puis-je m'en débarrasser ou le désactiver.

CMD:

Device / Credential Guard est une machine virtuelle / mode virtuel sécurisé basé sur Hyper-V qui héberge un noyau sécurisé pour rendre Windows 10 beaucoup plus sécurisé.

... l'instance VSM est séparée des fonctions normales du système d'exploitation et est protégée par les tentatives de lecture des informations dans ce mode. Les protections sont assistées par le matériel, car l'hyperviseur demande au matériel de traiter ces pages de mémoire différemment. C'est de la même manière que deux machines virtuelles sur le même hôte ne peuvent pas interagir l'une avec l'autre; leur mémoire est indépendante et le matériel réglementé pour garantir que chaque machine virtuelle ne peut accéder qu'à ses propres données.

De là, nous avons maintenant un mode protégé où nous pouvons exécuter des opérations sensibles à la sécurité. Au moment de la rédaction de cet article, nous prenons en charge trois fonctionnalités qui peuvent résider ici: l'autorité de sécurité locale (LSA) et les fonctions de contrôle d'intégrité du code sous la forme d'intégrité du code en mode noyau (KMCI) et le contrôle d'intégrité du code de l'hyperviseur lui-même, appelé Intégrité du code de l'hyperviseur (HVCI).

Lorsque ces capacités sont gérées par les Trustlets dans VSM, le système d'exploitation hôte communique simplement avec eux via des canaux et des capacités standard à l'intérieur du système d'exploitation. Bien que cette communication spécifique à Trustlet soit autorisée, le fait d'avoir du code malveillant ou des utilisateurs dans le système d'exploitation hôte qui tentent de lire ou de manipuler les données dans VSM sera beaucoup plus difficile que sur un système sans cette configuration, offrant l'avantage de sécurité.

L'exécution de LSA dans VSM entraîne le maintien du processus LSA lui-même (LSASS) dans le système d'exploitation hôte et une instance supplémentaire spéciale de LSA (appelée LSAIso - qui signifie LSA isolé) est créée. Cela permet à tous les appels standard à LSA de réussir, offrant une excellente compatibilité héritée et descendante, même pour les services ou les capacités qui nécessitent une communication directe avec LSA. À cet égard, vous pouvez considérer l'instance LSA restante dans le système d'exploitation hôte comme une instance «proxy» ou «stub» qui communique simplement avec la version isolée de manière prescrite.

Et Hyper-V et VMware n'ont pas fonctionné au même moment jusqu'en 2020 , lorsque VMware a utilisé la plateforme Hyper-V pour coexister avec Hyper-V à partir de la version 15.5.5 .

Comment VMware Workstation fonctionne-t-il avant la version 15.5.5?

VMware Workstation a traditionnellement utilisé un Virtual Machine Monitor (VMM) qui fonctionne en mode privilégié nécessitant un accès direct au processeur ainsi qu'un accès au support de virtualisation intégré du processeur (Intel VT-x et AMD-V d'AMD). Lorsqu'un hôte Windows active les fonctionnalités de Virtualization Based Security («VBS»), Windows ajoute une couche d'hyperviseur basée sur Hyper-V entre le matériel et Windows. Toute tentative d'exécution du VMM traditionnel de VMware échoue car, étant à l'intérieur d'Hyper-V, le VMM n'a plus accès à la prise en charge de la virtualisation du matériel.

Présentation du moniteur de niveau utilisateur

Pour résoudre ce problème de compatibilité Hyper-V / Host VBS, l'équipe de plate-forme de VMware a restructuré l'hyperviseur de VMware pour utiliser les API WHP de Microsoft. Cela signifie changer notre VMM pour qu'il s'exécute au niveau de l'utilisateur plutôt qu'en mode privilégié, ainsi que le modifier pour utiliser les API WHP pour gérer l'exécution d'un invité au lieu d'utiliser directement le matériel sous-jacent.

Qu'est-ce que cela signifie pour vous?

VMware Workstation / Player peut désormais s'exécuter lorsque Hyper-V est activé. Vous n'avez plus à choisir entre l' exécution de VMware Workstation et des fonctionnalités Windows telles que WSL, Device Guard et Credential Guard. Lorsque Hyper-V est activé, le mode ULM est automatiquement utilisé pour que vous puissiez exécuter VMware Workstation normalement. Si vous n'utilisez pas du tout Hyper-V, VMware Workstation est suffisamment intelligent pour le détecter et le VMM sera utilisé.

Configuration requise

Pour exécuter Workstation / Player à l'aide des API Windows Hypervisor, la version minimale requise de Windows 10 est Windows 10 20H1 build 19041.264. La version minimale de VMware Workstation / Player est 15.5.5.

Pour éviter l'erreur, mettez à jour votre Windows 10 vers la version 2004 / Build 19041 (mise à jour de mai 2020) et utilisez au moins VMware 15.5.5 .

Il existe une bien meilleure façon de gérer ce problème. Plutôt que de supprimer complètement Hyper-V, vous devez simplement effectuer un démarrage alternatif pour le désactiver temporairement lorsque vous devez utiliser VMWare. Comme montré ici ...

http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx

C:\>bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}. 

C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off 
The operation completed successfully.

Remarque: l'ID généré à partir de la première commande est celui que vous utilisez dans la seconde. Ne l'exécutez pas textuellement.

Lorsque vous redémarrez, vous ne verrez alors qu'un menu avec deux options ...

• Windows 10
• Pas d'Hyper-V

Donc, utiliser VMWare est juste une question de redémarrage et de choix de l'option No Hyper-V.

Si vous souhaitez supprimer à nouveau une entrée de démarrage. Vous pouvez utiliser l'option / delete pour bcdedit.

Tout d'abord, obtenez une liste des entrées de démarrage actuelles ...

C:\>bcdedit /v

Cela répertorie toutes les entrées avec leur ID. Copiez l'ID pertinent, puis supprimez-le comme ceci ...

C:\>bcdedit /delete {ff-23-113-824e-5c5144ea}

Comme mentionné dans les commentaires, vous devez le faire à partir d'une invite de commande élevée, et non de PowerShell. Dans PowerShell, la commande provoquera une erreur.

update: Il est possible d'exécuter ces commandes dans PowerShell, si les accolades sont échappées avec backtick (`). Ainsi...

C:\WINDOWS\system32> bcdedit /copy `{current`} /d "No Hyper-V"

Je ne suis toujours pas convaincu qu'Hyper-V est la chose pour moi, même avec les épreuves et les tribulations de Docker de l'année dernière et je suppose que vous ne voudrez pas changer très souvent, donc plutôt que de créer un nouveau démarrage et de confirmer le démarrage par défaut ou attendre l'expiration du délai à chaque démarrage que je passe à la demande dans la console en mode administrateur en

bcdedit /set hypervisorlaunchtype off

Une autre raison pour cet article - pour vous épargner des maux de tête: vous pensiez réactiver Hyper-V avec l'argument "on"? Nan. Trop simple pour MiRKoS..t. C'est automatique !

S'amuser!
G.

Pour le rendre super facile:

1. Téléchargez simplement ce script directement depuis Microsoft.

2. Exécutez votre Powershell en tant qu'administrateur, puis exécutez les commandes suivantes:

   • Pour vérifier si DG / CG est activé DG_Readiness.ps1 -Ready
   • Pour désactiver DG / CG. DG_Readiness.ps1 -Disable

Pour ceux qui pourraient rencontrer ce problème avec des modifications récentes de votre ordinateur impliquant Hyper-V, vous devrez le désactiver lors de l'utilisation de VMWare ou VirtualBox. Ils ne travaillent pas ensemble. Windows Sandbox et WSL 2 ont besoin de l'hyperviseur Hyper-V, qui rompt actuellement VMWare. Fondamentalement, vous devrez exécuter les commandes suivantes pour activer / désactiver les services Hyper-V au prochain redémarrage.

Pour désactiver Hyper-V et faire fonctionner VMWare, dans PowerShell en tant qu'administrateur:

bcdedit /set hypervisorlaunchtype off

Pour réactiver Hyper-V et interrompre VMWare pour le moment, dans PowerShell en tant qu'administrateur:

bcdedit /set hypervisorlaunchtype auto

Vous devrez redémarrer après cela. J'ai écrit un script PowerShell qui va basculer cela pour vous et le confirmer avec des boîtes de dialogue. Il s'auto-élève même au rang d'administrateur en utilisant cette technique afin que vous puissiez simplement cliquer avec le bouton droit et exécuter le script pour changer rapidement votre mode Hyper-V. Il pourrait facilement être modifié pour redémarrer pour vous également, mais personnellement, je ne voulais pas que cela se produise. Enregistrez-le sous le nom hypervisor.ps1 et assurez-vous que vous l'avez exécuté Set-ExecutionPolicy RemoteSignedafin de pouvoir exécuter des scripts PowerShell.

# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);

# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;

# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    # We are running as an administrator, so change the title and background colour to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
    $Host.UI.RawUI.BackgroundColor = "DarkBlue";
    Clear-Host;
}
else {
    # We are not running as an administrator, so relaunch as administrator

    # Create a new process object that starts PowerShell
    $newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";

    # Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
    $newProcess.Arguments = "-windowstyle hidden & '" + $script:MyInvocation.MyCommand.Path + "'"

    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";

    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);

    # Exit from the current, unelevated, process
    Exit;
}

Add-Type -AssemblyName System.Windows.Forms


$state = bcdedit /enum | Select-String -Pattern 'hypervisorlaunchtype\s*(\w+)\s*'


if ($state.matches.groups[1].ToString() -eq "Off"){

    $UserResponse= [System.Windows.Forms.MessageBox]::Show("Enable Hyper-V?" , "Hypervisor" , 4)

    if ($UserResponse -eq "YES" ) 
    {

        bcdedit /set hypervisorlaunchtype auto
        [System.Windows.Forms.MessageBox]::Show("Enabled Hyper-V. Reboot to apply." , "Hypervisor")

    } 

    else 

    { 

        [System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
        exit

    }

} else {

    $UserResponse= [System.Windows.Forms.MessageBox]::Show("Disable Hyper-V?" , "Hypervisor" , 4)

    if ($UserResponse -eq "YES" ) 
    {

        bcdedit /set hypervisorlaunchtype off
        [System.Windows.Forms.MessageBox]::Show("Disabled Hyper-V. Reboot to apply." , "Hypervisor")

    } 

    else 

    { 

        [System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
        exit

    }

}

la solution la plus simple à ce problème est de télécharger «l'outil de préparation matérielle Device Guard et Credential Guard» pour corriger l'incompatibilité:

• https://www.microsoft.com/en-us/download/details.aspx?id=53337
• Décompressez le zip
• tu trouveras :

• exécuter le "DG_Readiness_Tool_v3.6.ps1" avec PowerShell

• Vous devriez maintenant pouvoir allumer normalement votre machine virtuelle.

Je ne sais pas pourquoi mais la version 3.6 de DG_Readiness_Tool n'a pas fonctionné pour moi. Après avoir redémarré, mon problème d'ordinateur portable persistait. Je cherchais une solution et finalement je suis tombé sur la version 3.7 de l'outil et cette fois, le problème a disparu. Ici vous pouvez trouver le dernier script PowerShell:

DG_Readiness_Tool_v3.7

J'ai également beaucoup lutté avec ce problème. Les réponses dans ce fil ont été utiles mais n'ont pas suffi à résoudre mon erreur. Vous devrez désactiver Hyper-V et Device Guard comme les autres réponses l'ont suggéré. Plus d'informations à ce sujet ici .

J'inclus les changements nécessaires en plus des réponses fournies ci-dessus. Le lien qui m'a finalement aidé était ce .

Ma réponse va résumer uniquement la différence entre le reste des réponses (c'est-à-dire Désactiver Hyper-V et Device Guard) et les étapes suivantes:

1. Si vous avez utilisé la stratégie de groupe, désactivez le paramètre de stratégie de groupe que vous avez utilisé pour activer Windows Defender Credential Guard (Configuration ordinateur -> Modèles d'administration -> Système -> Device Guard -> Activer la sécurité basée sur la virtualisation).

2. Supprimez les paramètres de registre suivants:

   HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA \ LsaCfgFlags HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ DeviceGuard \ EnableVirtualizationBasedSecurity HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ DeviceGuard \ RequireFeatformures

   Important: si vous supprimez manuellement ces paramètres de registre, assurez-vous de tous les supprimer. Si vous ne les supprimez pas tous, l'appareil peut passer à la récupération BitLocker.

3. Supprimez les variables EFI Windows Defender Credential Guard à l'aide de bcdedit. À partir d'une invite de commandes avec élévation de privilèges (démarrer en mode administrateur), tapez les commandes suivantes:

    mountvol X: /s
   
    copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
   
    bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
   
    bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
   
    mountvol X: /d
   

4. Redémarrez le PC.

5. Acceptez l'invite pour désactiver Windows Defender Credential Guard.

6. Vous pouvez également désactiver les fonctionnalités de sécurité basées sur la virtualisation pour désactiver Windows Defender Credential Guard.

UNE SOLUTION RAPIDE À CHAQUE ÉTAPE:

Correction d'une erreur dans VMware Workstation sur l'erreur de transport hôte Windows 10 (VMDB) -14: la connexion du tuyau a été interrompue.

Aujourd'hui, nous corrigerons l'erreur VMWare sur un ordinateur Windows 10.

1. Dans la boîte RUN, tapez "gpedit" puis Goto [ERROR SEE POINT 3]

1- Configuration de l'ordinateur 2- Modèles d'administration 3- Système - Device Guard: SI AUCUN DEVICE GUARD: (TÉLÉCHARGER https://www.microsoft.com/en-us/download/100591 installer cette "c:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2019 Update (1909)\PolicyDefinitions" COPIE sur c:\windows\PolicyDefinitions) 4- Activer la virtualisation basée Sécurité. Maintenant, double-cliquez dessus et "Désactiver"

2. Ouvrez l’invite de commandes en tant qu’administrateur et saisissez la commande gpupdate / force suivante

3. Ouvrez l'éditeur de registre, allez maintenant à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard. Ajoutez une nouvelle valeur DWORD nommée EnableVirtualizationBasedSecurityet définissez-la sur 0 pour la désactiver. Passez ensuite à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. Ajoutez une nouvelle valeur DWORD nommée LsaCfgFlagset définissez-la sur 0 pour la désactiver.

4. Dans la zone RUN, tapez Activer ou désactiver les fonctionnalités Windows, décochez maintenant Hyper-V et redémarrez le système.

5. Ouvrez l'invite de commande en tant qu'administrateur et tapez les commandes suivantes

    bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader

    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"

    bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
    
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS

    bcdedit /set hypervisorlaunchtype off

Maintenant, redémarrez votre système

Si vous êtes quelqu'un qui maintient une invite de commande ouverte personnalisée «Exécuter en tant qu'administrateur» ou une fenêtre de ligne de commande PowerShell à tout moment, vous pouvez éventuellement configurer les alias / macros suivants pour simplifier l'exécution des commandes mentionnées par @ gue22 pour simplement désactiver l'hyperviseur hyper-v lorsque vous devez utiliser le lecteur vmware ou la station de travail, puis l'activer à nouveau une fois terminé.

doskey hpvEnb = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype auto ^& echo.^&echo now reboot to enable hyper-v hypervisor )
doskey hpvDis = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype off ^& echo.^&echo now reboot to disable hyper-v hypervisor )
doskey bcdL = bcdedit /enum ^& echo.^&echo now see boot configuration data store {current} boot loader settings

Avec ce qui précède en place, il vous suffit de taper les commandes "hpvenb" [hyperviseur activé au démarrage], "hpvdis" [hyperviseur désactivé au démarrage] et "bcdl" [liste des périphériques de configuration de démarrage] pour exécuter les commandes on, off, list.

Eh bien, les garçons et les filles après avoir lu les notes de publication de la build 17093 dans les petites heures de la nuit, j'ai trouvé le point de changement qui affecte mes VM VMware Workstation les empêchant de fonctionner, ce sont les paramètres Core Isolation sous Device Security sous sécurité windows (nouveau nom pour la page windows defender) dans les paramètres .

Par défaut, il est activé, mais lorsque je l'ai éteint et redémarré mon ordinateur, toutes mes VM VMware ont recommencé à fonctionner correctement. Peut-être qu'une option par appareil pourrait être incorporée dans la prochaine version pour nous permettre de tester les réponses des appareils / applications individuels pour permettre à l'isolation principale d'être activée ou désactivée par appareil ou application, selon les besoins.

Voici les instructions appropriées pour que tout le monde puisse les suivre.

• Commencez par télécharger l'outil de préparation matérielle Device Guard et Credential Guard à partir de ce lien: https://www.microsoft.com/en-us/download/details.aspx?id=53337
• extraire le contenu du dossier zip vers un emplacement comme: C: \ guard_tool
• vous aurez des fichiers comme ce nom de fichier de copie du fichier d'extension ps1 dans mon cas, sa v3.6 donc ce sera: DG_Readiness_Tool_v3.6.ps1

• Cliquez ensuite sur le menu Démarrer et recherchez PowerShell, puis faites un clic droit dessus et exécutez en tant qu'administrateur.

• Après cela, vous verrez le terminal de couleur bleue entrer la commande cd C: \ guard_tool , remplacez le chemin après cd par l'emplacement extrait de l'outil
• Entrez maintenant la commande :. \ DG_Readiness_Tool_v3.6.ps1 -Disable
• Après ce redémarrage du système
• Lorsque votre système redémarre, le système affiche une notification sur fond noir pour vérifier que vous souhaitez désactiver ces fonctionnalités, appuyez sur F3 pour confirmer.
• faites +1 si cela a aidé :)