Felsöka BitLocker-principer från klientsidan

Den här artikeln innehåller vägledning om hur du felsöker BitLocker-kryptering på klientsidan. Även om Microsoft Intune krypteringsrapport kan hjälpa dig att identifiera och felsöka vanliga krypteringsproblem, kanske vissa statusdata från BitLocker-konfigurationstjänstleverantören (CSP) inte rapporteras. I dessa scenarier måste du komma åt enheten för att undersöka vidare.

BitLocker-krypteringsprocess

Följande steg beskriver flödet av händelser som ska resultera i en lyckad kryptering av en Windows 10 enhet som inte tidigare har krypterats med BitLocker.

1. En administratör konfigurerar en BitLocker-princip i Intune med önskade inställningar och riktar sig till en användargrupp eller enhetsgrupp.
2. Principen sparas i en klientorganisation i Intune-tjänsten.
3. En Windows 10 Mobile Enhetshantering-klient (MDM) synkroniseras med Intune-tjänsten och bearbetar BitLocker-principinställningarna.
4. BitLocker MDM-principen Uppdatera schemalagd aktivitet körs på enheten som replikerar BitLocker-principinställningarna till registernyckeln för fullständig volymkryptering (FVE).
5. BitLocker-kryptering initieras på enheterna.

Krypteringsrapporten visar information om krypteringsstatus för varje målenhet i Intune. Detaljerad information om hur du använder den här informationen för felsökning finns i Felsöka BitLocker med Intune krypteringsrapport.

Initiera en manuell synkronisering

Om du har fastställt att det inte finns någon användbar information i krypteringsrapporten måste du samla in data från den berörda enheten för att slutföra undersökningen.

När du har åtkomst till enheten är det första steget att initiera en synkronisering med Intune-tjänsten manuellt innan du samlar in data. På din Windows-enhet väljer du Inställningar Konton>>Åtkomst till arbete eller skola><Välj informationom ditt arbets- eller skolkonto>>. Under Status för enhetssynkronisering väljer du Sedan Synkronisera.

När synkroniseringen är klar fortsätter du till följande avsnitt.

Samla in händelseloggdata

I följande avsnitt beskrivs hur du samlar in data från olika loggar för att felsöka krypteringsstatus och principer. Se till att du slutför en manuell synkronisering innan du samlar in loggdata.

Händelselogg för hantering av mobila enheter (MDM)

MDM-händelseloggen är användbar för att avgöra om det uppstod ett problem med att bearbeta Intune-principen eller tillämpa CSP-inställningar. OMA DM-agenten ansluter till Intune-tjänsten och försöker bearbeta de principer som är riktade till användaren eller enheten. Den här loggen visar lyckad och misslyckad bearbetning Intune principer.

Samla in eller granska följande information:

LOGGA IN>DeviceManagement-Enterprise-Diagnostics-Provider admin

• Plats: Högerklicka på Start-menyn>Loggboken>Program och tjänstloggar>Microsoft>Windows>DeviceManagement-Enterprise-Diagnostics-Provider>Admin
• Plats för filsystem: C:\Windows\System32\winevt\Logs\Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider%4Admin.evtx

Om du vill filtrera den här loggen högerklickar du på händelseloggen och väljer Filtrera aktuell loggkritisk>/Fel/Varning. Sök sedan igenom de filtrerade loggarna efter BitLocker (tryck på F3 och ange texten).

Fel i BitLocker-inställningar kommer att följa formatet för BitLocker CSP, så du ser poster som denna:

./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption

eller

./Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation

Obs!

Du kan också aktivera felsökningsloggning för den här händelseloggen med hjälp av Loggboken för felsökning.

Händelselogg för BitLocker-API-hantering

Det här är huvudhändelseloggen för BitLocker. Om MDM-agenten har bearbetat principen och det inte finns några fel i händelseloggen DeviceManagement-Enterprise-Diagnostics-Provider är detta nästa logg att undersöka.

LOGGA IN>BitLocker-API-hantering

• Plats: Högerklicka på Start-menyn>Loggboken>Program och tjänstloggar>Microsoft>Windows>BitLocker-API
• Plats för filsystem: C:\Windows\System32\winevt\Logs\Microsoft-Windows-BitLocker%4BitLocker Management.evtx

Vanligtvis loggas fel här om det saknas maskinvaru- eller programvarukrav som principen kräver, till exempel TPM (Trusted Platform Module) eller Windows Recovery Environment (WinRE).

Fel: Det gick inte att aktivera tyst kryptering

Som du ser i följande exempel loggas även motstridiga principinställningar som inte kan implementeras under tyst kryptering och manifest som grupprincipkonflikter:

Det gick inte att aktivera tyst kryptering.

Fel: BitLocker-kryptering kan inte tillämpas på den här enheten på grund av motstridiga grupprincip inställningar. När skrivåtkomst till enheter som inte skyddas av BitLocker nekas kan det inte krävas att en USB-startnyckel används. Be systemadministratören lösa dessa principkonflikter innan du försöker aktivera BitLocker.

Lösning: Konfigurera den kompatibla PIN-koden för TPM-start till Blockerad. Detta löser motstridiga grupprincip inställningar när du använder tyst kryptering.

Du måste ange PIN-koden och TPM-startnyckeln till Blockerad om tyst kryptering krävs. Om du konfigurerar PIN-koden för TPM-start och startnyckeln till Tillåten och annan startnyckel och PIN-inställning till Blockerad för användarinteraktion och resulterar i ett motstridigt grupprincip fel i BitLocker-AP-händelseloggen. Om du konfigurerar PIN-kod för TPM-start eller startnyckel för att kräva användarinteraktion kommer den dessutom att leda till att tyst kryptering misslyckas.

Om du konfigurerar någon av de kompatibla TPM-inställningarna till Obligatorisk misslyckas tyst kryptering.

Fel: TPM är inte tillgängligt

Ett annat vanligt fel i BitLocker-API-loggen är att TPM inte är tillgängligt. I följande exempel visas att TPM är ett krav för tyst kryptering:

Det gick inte att aktivera tyst kryptering. TPM är inte tillgängligt.

Fel: Det går inte att hitta en kompatibel TPM-säkerhetsenhet (Trusted Platform Module) på den här datorn.

Lösning: Kontrollera att det finns en TPM tillgänglig på enheten och om den finns kontrollerar du statusen via TPM.msc eller PowerShell-cmdleten get-tpm.

Fel: Un-Allowed DMA-kompatibel buss

Om BitLocker-API-loggen visar följande status innebär det att Windows har identifierat en ansluten DMA-kompatibel enhet (Direct Memory Access) som kan exponera ett DMA-hot.

Un-Allowed DMA-kompatibel buss/enhet har identifierats

Lösning: Åtgärda problemet genom att först kontrollera att enheten inte har några externa DMA-portar hos oem-tillverkaren (Original Equipment Manufacturer). Följ sedan de här stegen för att lägga till enheten i listan över tillåtna enheter. Obs! Lägg bara till en DMA-enhet i listan över tillåtna om det är ett internt DMA-gränssnitt/buss.

Systemhändelselogg

Om du har maskinvarurelaterade problem, till exempel problem med TPM, visas fel i systemhändelseloggen för TPM från TPMProvisioningService- eller TPM-WMI-källan.

LOGGA IN>Systemhändelse

• Plats: Högerklicka på Start-menyn>Loggboken>Windows Logs>System
• Plats för filsystem: C:\Windows\System32\winevt\Logs\System.evtx

Filtrera på dessa händelsekällor för att identifiera eventuella maskinvarurelaterade problem som enheten kan ha med TPM och kontrollera med OEM-tillverkaren om det finns några tillgängliga uppdateringar av inbyggd programvara.

Aktivitetsschemaläggarens driftshändelselogg

Den operativa händelseloggen för schemaläggaren är användbar för felsökningsscenarier där principen har tagits emot från Intune (har bearbetats i DeviceManagement-Enterprise), men BitLocker-kryptering har inte initierats. BitLocker MDM-principuppdatering är en schemalagd aktivitet som ska köras när MDM-agenten synkroniseras med Intune-tjänsten.

Aktivera och kör driftloggen i följande scenarier:

• BitLocker-principen visas i händelseloggen DeviceManagement-Enterprise-Diagnostics-Provider, i MDM-diagnostik och registret.
• Det finns inga fel (principen har hämtats från Intune).
• Ingenting loggas i Händelseloggen för BitLocker-API för att visa att kryptering till och med har försökts.

LOGGA IN>Drifthändelse för schemaläggaren

• Plats: Loggboken>Program och tjänstloggar>Microsoft>Windows>TaskScheduler
• Plats för filsystem: C:\Windows\System32\winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational.evtx

Aktivera och köra händelseloggen för driften

Viktigt

Du måste aktivera den här händelseloggen manuellt innan du loggar data eftersom loggen identifierar eventuella problem med att köra den schemalagda aktiviteten Uppdatering av BitLocker MDM-princip.

1. Om du vill aktivera den här loggen högerklickar du på Start-menyn>Loggboken>Program och tjänster>Microsoft>Windows>TaskScheduler>Operational.

   

2. Ange sedan schemaläggaren i sökrutan i Windows och välj Schemaläggaren>Microsoft>Windows>BitLocker. Högerklicka på BitLocker MDM-principUppdatering och välj Kör.

3. När körningen är klar kontrollerar du kolumnen Resultat för senaste körning efter eventuella felkoder och undersöker händelseloggen för aktivitetsschemat efter fel.

   

   I exemplet ovan har 0x0 körts. Felet 0x41303 detta innebär att aktiviteten aldrig har körts tidigare.

Obs!

Mer information om felmeddelanden för Schemaläggaren finns i Fel och lyckade konstanter i Schemaläggaren.

Kontrollera BitLocker-inställningar

I följande avsnitt beskrivs de olika verktyg som du kan använda för att kontrollera krypteringsinställningar och -status.

MDM-diagnostikrapport

Du kan skapa en rapport över MDM-loggar för att diagnostisera problem med registrering eller enhetshantering i Windows 10 enheter som hanteras av Intune. MDM-diagnostikrapporten innehåller användbar information om en Intune registrerad enhet och de principer som distribueras till den.

En självstudiekurs om den här processen finns i YouTube-videon Så här skapar du en Intune MDM-diagnostikrapport på Windows-enheter

• Plats för filsystem: C:\Users\Public\Documents\MDMDiagnostics

Operativsystemets version och utgåva

Det första steget i att förstå varför krypteringsprincipen inte tillämpas korrekt är att kontrollera om Windows OS-versionen och -utgåvan stöder de inställningar som du har konfigurerat. Vissa CSP:er introducerades på specifika versioner av Windows och fungerar bara på en viss utgåva. Till exempel introducerades huvuddelen av CSP-inställningarna för BitLocker i Windows 10 version 1703, men de här inställningarna stöds inte på Windows 10 Pro förrän Windows 10 version 1809.

Dessutom finns det inställningar som AllowStandardUserEncryption (tillagd i version 1809), ConfigureRecoveryPasswordRotation (tillagd i version 1909), RotateRecoveryPasswords (tillagd i version 1909) och Status (tillagd i version 1903).

Undersöka med EntDMID

EntDMID är ett unikt enhets-ID för Intune registrering. I Microsoft Intune administrationscenter kan du använda EntDMID för att söka igenom vyn Alla enheter och identifiera en specifik enhet. Det är också en viktig information för Microsofts support för att möjliggöra ytterligare felsökning på tjänstsidan om ett supportärende krävs.

Du kan också använda MDM-diagnostikrapporten för att identifiera om en princip har skickats till enheten med de inställningar som administratören har konfigurerat. Genom att använda BitLocker CSP som referens kan du dechiffrera vilka inställningar som har hämtats vid synkronisering med Intune-tjänsten. Du kan använda rapporten för att avgöra om principen är riktad mot enheten och använda BitLocker CSP-dokumentationen för att identifiera vilka inställningar som har konfigurerats.

MSINFO32

MSINFO32 är ett informationsverktyg som innehåller enhetsdata som du kan använda för att avgöra om en enhet uppfyller BitLocker-kraven. De nödvändiga förutsättningarna beror på BitLocker-principinställningar och det nödvändiga resultatet. Tyst kryptering för TPM 2.0 kräver tpm och UEFI (Unified Extensible Firmware Interface).

• Plats: I sökrutan anger du msinfo32, högerklickar på Systeminformation i sökresultatet och väljer Kör som administratör.
• Filsystemplats: C:\Windows\System32\Msinfo32.exe.

Men om det här objektet inte uppfyller kraven betyder det inte nödvändigtvis att du inte kan kryptera enheten med hjälp av en Intune princip.

• Om du har konfigurerat BitLocker-principen för att kryptera tyst och enheten använder TPM 2.0 är det viktigt att kontrollera att BIOS-läget är UEFI. Om TPM är 1.2 är det inte ett krav att ha BIOS-läget i UEFI.
• Säker start, DMA-skydd och PCR7-konfiguration krävs inte för tyst kryptering, men kan vara markerat i stöd för enhetskryptering. Det här är för att säkerställa stöd för automatisk kryptering.
• BitLocker-principer som är konfigurerade för att inte kräva en TPM och som har användarinteraktion i stället för att kryptera tyst har inte heller några krav för att checka in MSINFO32.

TPM. MSC-fil

TPM.msc är en snapin-modul för Microsoft Management Console (MMC). Du kan använda TPM.msc för att avgöra om enheten har en TPM, för att identifiera versionen och om den är redo att användas.

• Plats: I sökrutan anger du tpm.msc och högerklickar och väljer Kör som administratör.
• Plats för filsystem: MMC Snapin-C:\Windows\System32\mmc.exe.

TPM är inte en förutsättning för BitLocker, men rekommenderas starkt på grund av den ökade säkerheten. TPM krävs dock för tyst och automatisk kryptering. Om du försöker kryptera tyst med Intune och det finns TPM-fel i BitLocker-API:et och systemhändelseloggarna hjälper TPM.msc dig att förstå problemet.

I följande exempel visas en felfri TPM 2.0-status. Observera specifikationen version 2.0 längst ned till höger och att statusen är klar att användas.

Det här exemplet visar en status som inte är felfri när TPM är inaktiverat i BIOS:

Att konfigurera en princip för att kräva en TPM och förvänta sig att BitLocker krypteras när TPM saknas eller inte är felfri är ett av de vanligaste problemen.

Get-Tpm cmdlet

En cmdlet är ett enkelt kommando i den Windows PowerShell miljön. Förutom att köra TPM.msc kan du verifiera TPM med hjälp av cmdleten Get-Tpm. Du måste köra den här cmdleten med administratörsbehörighet.

• Plats: I sökrutan anger du cmd och högerklickar och väljer Kör som administratör>PowerShell>get-tpm.

I exemplet ovan kan du se att TPM finns och är aktiv i PowerShell-fönstret. Värdena är lika med True. Om värdena har angetts till False skulle det tyda på ett problem med TPM. BitLocker kommer inte att kunna använda TPM förrän den finns, är redo, aktiverad, aktiverad och ägd.

Kommandoradsverktyget Manage-bde

Manage-bde är ett kommandoradsverktyg för BitLocker-kryptering som ingår i Windows. Den är utformad för att hjälpa till med administration när BitLocker har aktiverats.

• Plats: I sökrutan anger du cmd, högerklickar och väljer Kör som administratör och anger sedan manage-bde -status.
• Filsystemplats: C:\Windows\System32\manage-bde.exe.

Du kan använda manage-bde för att identifiera följande information om en enhet:

• Är den krypterad? Om rapporteringen i Microsoft Intune administrationscenter anger att en enhet inte är krypterad kan det här kommandoradsverktyget identifiera krypteringsstatusen.
• Vilken krypteringsmetod har använts? Du kan jämföra information från verktyget med krypteringsmetoden i principen för att se till att de matchar. Om Intune-principen till exempel är konfigurerad för XTS-AES 256-bitars och enheten krypteras med XTS-AES 128-bitars, resulterar detta i fel i Microsoft Intune principrapportering i administrationscentret.
• Vilka specifika skydd används? Det finns flera kombinationer av skydd. Att veta vilket skydd som används på en enhet hjälper dig att förstå om principen har tillämpats korrekt.

I följande exempel är enheten inte krypterad:

BitLocker-registerplatser

Det här är det första stället i registret som du vill se när du vill dechiffrera de principinställningar som hämtas av Intune:

• Plats: Högerklicka på Starta>körning och ange sedan regedit för att öppna Editor.
• Standardplats för filsystem: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker

MDM-agentens registernyckel hjälper dig att identifiera den globalt unika identifieraren (GUID) i PolicyManager som innehåller de faktiska BitLocker-principinställningarna.

GUID är markerat i exemplet ovan. Du kan inkludera GUID (det kommer att vara olika för varje klient) i följande registerundernyckel för att felsöka BitLocker-principinställningar:

<Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\ProvidersGUID>\default\Device\BitLocker

Den här rapporten visar BitLocker-principinställningarna som har hämtats av MDM-agenten (OMADM-klienten). Det här är samma inställningar som visas i MDM-diagnostikrapporten, så det här är ett alternativt sätt att identifiera inställningar som klienten har hämtat.

Exempel på registernyckeln EncryptionMethodByDriveType :

<enabled/><data id="EncryptionMethodWithXtsOsDropDown_Name" value="6"/><data id="EncryptionMethodWithXtsFdvDropDown_Name" value="6"/><data id="EncryptionMethodWithXtsRdvDropDown_Name" value="3"/>

Exempel på SystemDrivesRecoveryOptions:

<enabled/><data id="OSAllowDRA_Name" value="true"/><data id="OSRecoveryPasswordUsageDropDown_Name" value="2"/><data id="OSRecoveryKeyUsageDropDown_Name" value="2"/><data id="OSHideRecoveryPage_Name" value="false"/><data id="OSActiveDirectoryBackup_Name" value="true"/><data id="OSActiveDirectoryBackupDropDown_Name" value="1"/><data id="OSRequireActiveDirectoryBackup_Name" value="true"/> 

BitLocker-registernyckel

Inställningarna i principproviderns registernyckel dupliceras till den huvudsakliga BitLocker-registernyckeln. Du kan jämföra inställningarna så att de matchar det som visas i principinställningarna i användargränssnittet (UI), MDM-loggen, MDM-diagnostiken och principregisternyckeln.

• Plats för registernyckel: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE

Det här är ett exempel på FVE-registernyckeln:

• A: EncryptionMethodWithXtsOs, EncryptionMethodWithXtsFdv och EncryptionMethodWithXtsRdv har följande möjliga värden:
  • 3 = AES-CBC 128
  • 4 = AES-CBC 256
  • 6 = XTS-AES 128
  • 7 = XTS-AES 256
• B: UseTPM, UseTPMKey, UseTPMKeyPIN, USeTPMPIN är alla inställda på 2, vilket innebär att alla är inställda på att tillåta.
• C: Observera att de flesta nycklarna är indelade i grupper av inställningar för operativsystemenheten (OS), fast enhet (FDV) och flyttbar enhet (FDVR).
• D: OSActiveDirectoryBackup har värdet 1 och är aktiverat.
• E: OSHideRecoveryPage är lika med 0 och är inte aktiverat.

Använd CSP-dokumentationen för BitLocker för att avkoda alla inställningsnamn i registret.

REAgentC.exe kommandoradsverktyg

REAgentC.exe är ett körbart kommandoradsverktyg som du kan använda för att konfigurera Windows Recovery Environment (Windows RE). WinRE är en förutsättning för att aktivera BitLocker i vissa scenarier, till exempel tyst eller automatisk kryptering.

• Plats: Högerklicka på Starta>körning och ange cmd. Högerklicka sedan på cmd och välj Kör som administratör>reagentc /info.
• Filsystemplats: C:\Windows\System32\ReAgentC.exe.

Tips

Om du ser felmeddelanden i BitLocker-API:et om att WinRe inte är aktiverat kör du kommandot reagentc /info på enheten för att fastställa WinRE-statusen.

Om WinRE-statusen är inaktiverad kör du kommandot reagentc /enable som administratör för att aktivera den manuellt:

Sammanfattning

När BitLocker inte kan aktiveras på en Windows 10 enhet med hjälp av en Intune princip är maskinvaru- eller programvarukraven i de flesta fall inte uppfyllda. Genom att undersöka BitLocker-API-loggen kan du identifiera vilka krav som inte uppfylls. De vanligaste problemen är:

• TPM finns inte
• WinRE är inte aktiverat
• UEFI BIOS är inte aktiverat för TPM 2.0-enheter

Felaktig principkonfiguration kan också orsaka krypteringsfel. Alla Windows-enheter kan inte krypteras tyst, så tänk på de användare och enheter som du riktar in dig på.

Att konfigurera en startnyckel eller PIN-kod för en princip som är avsedd för tyst kryptering fungerar inte på grund av användarinteraktionen som krävs när BitLocker aktiveras. Tänk på detta när du konfigurerar BitLocker-principen i Intune.

Kontrollera om principinställningarna har hämtats av enheten för att avgöra om målet har lyckats.

Det går att identifiera principinställningarna med hjälp av MDM-diagnostik, registernycklar och företagshändelseloggen för enhetshantering för att kontrollera om inställningarna har tillämpats. BitLocker CSP-dokumentationen kan hjälpa dig att dechiffrera de här inställningarna för att förstå om de matchar det som har konfigurerats i principen.