Felsöka BitLocker-principer från klientsidan

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

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. Den schemalagda bitLocker MDM-principen Uppdatera schemalagd aktivitet körs på den enhet 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 vägledning om hur du använder den här informationen för felsökning finns i Felsöka BitLocker med Intune-krypteringsrapporten.

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 ditt arbets- eller skolkontoInformation.>> Under Status för enhetssynkronisering väljer du 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. Kontrollera 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 användaren eller enheten riktar sig till. Den här loggen visar lyckade och misslyckade bearbetningar av Intune-principer.

Samla in eller granska följande information:

LOG>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 följer formatet för BitLocker CSP, så du ser poster som denna:

./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption

eller

./Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation

Kommentar

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.

LOG>BitLocker-API-hantering

• Plats: Högerklicka på Start-menyn> Loggboken> Program och tjänstloggar>Microsoft>Windows>BitLocker-API
• Filsystemplats: 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 användning av en USB-startnyckel. Låt 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 leder det också till att tyst kryptering misslyckas.

Om du konfigurerar någon av de kompatibla TPM-inställningarna till Obligatoriskt misslyckas den tysta krypteringen.

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: DMA-kompatibel buss som inte tillåts

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.

Ej tillåten 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 med den ursprungliga tillverkaren av utrustningen (OEM). 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.

LOG>System-händelse

• Plats: Högerklicka på Start-menyn> Loggboken> Windows Logs System>
• Filsystemplats: 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 hä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-krypteringen 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 bitLocker-API för att visa att krypteringen ens har försökts.

Logguppgiftsschemaläggarens>driftshändelse

• 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 drift

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 bitLocker MDM-principuppdateringen.

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 Windows-sökrutan 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 Senaste körningsresultat för eventuella felkoder och undersöker händelseloggen för aktivitetsschemat efter fel.

   

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

Kommentar

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ällningarna och -statusen.

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 för 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 i specifika versioner av Windows och fungerar bara på en viss utgåva. Till exempel introducerades huvuddelen av BitLocker CSP-inställningarna 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 administrationscentret för Microsoft Intune 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. Till exempel kräver tyst kryptering för TPM 2.0 ett TPM- och Unified Extensible Firmware Interface (UEFI).

• 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. Detta ä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-fil (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.
• Filsystemplats: MMC Snapin-modul C:\Windows\System32\mmc.exe.

TPM är inte en förutsättning för BitLocker, men rekommenderas starkt på grund av den ökade säkerhet som den ger. 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 och systemhändelseloggarna hjälper TPM.msc dig att förstå problemet.

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

Det här exemplet visar en status som inte är felfri när TPM är inaktiverad 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 Windows PowerShell-miljön. Förutom att köra TPM.msc kan du verifiera TPM med 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 är närvarande och 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, 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 rapportering i administrationscentret för Microsoft Intune 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 principrapportering för Microsoft Intune Administrationscenter.
• 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 att titta 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 Registereditorn.
• Standardfilsystemplats: Dator\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 klientorganisation) i följande registerundernyckel för att felsöka Principinställningar för BitLocker:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers<GUID>\default\Device\BitLocker

Den här rapporten visar de BitLocker-principinställningar som har hämtats av MDM-agenten (OMADM-klienten). Det här är samma inställningar som du ser 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 huvudregisternyckeln för BitLocker. Du kan jämföra inställningarna för att se till att de matchar vad som visas i principinställningarna i användargränssnittet (UI), MDM-loggen, MDM-diagnostiken och principregisternyckeln.

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

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

• S: 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, ange cmd. Högerklicka sedan på cmd och välj Kör som administratör>reagentc /info.
• Filsystemplats: C:\Windows\System32\ReAgentC.exe.

Dricks

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

Felkonfiguration av principer 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 den användarinteraktion 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 händelseloggen för enhetshantering för företag 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.