Windows 10 Bitlocker Query



  • Server
    • FOG Version: 1.3.0-RC-26
    • OS: Ubuntu 14.04
    Client
    • Service Version:
    • OS: Windows 10 Pro
    Description

    Hi all,

    When imaging a system, I have to boot it into Legacy Mode in order to get the option to boot from the network. However, when I do this and image the system, I’ve now realised I can’t enable Bitlocker - the OS has to be installed when UEFI is enabled. Has anyone had this issue before? Is there a workaround or solution I’m unaware of?
    Would rebuilding the image with UEFI mode enabled help at all?



  • @george1421 Still no dice with getting this to run with the legacy boot option.
    I’ve cloned my FOG server for UEFI testing but the laptops don’t boot using IPV4 - they just hang. or say that the file is not found (going by the previous posts).

    EDIT:
    It seems to be working on a Dell E7270. I’ll test after the holidays with the other Dell laptop :)
    Thanks for the help, George and everyone else! Much appreciated as always!



  • @george1421 Thanks, George. I’ll give this a go with one of the other laptops to see if I can get it to work.


  • Moderator

    @RobTitian16 said in Windows 10 Bitlocker Query:

    @george1421

    Sorry about the delay - it’s been hectic this past week. Here’s the latest pcap:

    0_1481287363618_output.pcap

    … Once the motherboard was replaced, Bitlocker could then be enabled without any issue.

    If the tpm chip was initialized by another OS and then a new OS was overlaid onto the system with the activated tpm chip, I can understand why bitlocker would not init, because the system identity would have been changed. The information in the TPM chip would not match the current computing environment. From what I understand you must blank out and reset the TPM chip to enable it on the new OS.

    <edit>Ref: http://www.dell.com/support/article/us/en/4/SLN155219/en </edit>



  • I have a growing hatred for Dell systems. 8)



  • @george1421

    Sorry about the delay - it’s been hectic this past week. Here’s the latest pcap:

    0_1481287363618_output.pcap

    Interestingly, what @sudburr said earlier rings true as the very system I was trying to get Bitlocker to work on earlier died and had the motherboard replaced by Dell. Once the motherboard was replaced, Bitlocker could then be enabled without any issue.



  • @george1421 Yep, I removed those this morning.
    I had to revert back to a previous build of my FOG server as I needed to image a VM for our production environment. I’ll go through the dnsmasq set-up again and then provide a pcap when the issue occurs again (likely to be on Monday now).


  • Moderator

    @RobTitian16 Lets remove the dhcp options 66 and 67 from your primary dhcp server. Let dnsmasq supply these values. If that doesn’t work grab another pcap of the hyper-v pxe booting. Lets see what’s flying down the wire then.



  • @RobTitian16 I’ve also found this has stopped my ability to image VMs on Hyper-V:

    0_1480672488015_upload-f55fc67f-b107-457c-baa6-9dfba5bbe4e4



  • @george1421 We seem one step further :)
    It now boots from the network, but gets stuck on "iPXE initialising devices…"
    I’ve tried the suggestions here: (https://forums.fogproject.org/topic/6133/intel-nuc-dc53427hye-stuck-at-ipxe-initialising-devices/6) to no avail. It’s a Dell Latitude 6430 and I can see here (https://wiki.fogproject.org/wiki/index.php/WorkingDevices) that it looks like it may not work anyway.



  • @Wayne-Workman I’m not trying to capture an image from a system that’s using BitLocker - I’m trying to enable it after the system has been imaged. From the forum post linked in my other reply, it says it needs to be imaged in UEFI mode (effectively) to enable BitLocker to run correctly.



  • @sudburr I read online that UEFI has to be enabled to run BitLocker. (Source: http://www.dell-forum.com/windows/bitlocker-cannot-be-enabled-when-changing-the-boot-sequence-to-legacy-mode/).
    It does exactly what it says in that forum post - asks for a key every time the system is booted, which can be incredibly cumbersome when you have to dig out the key from a file share (using another system). I suppose we could supply everyone with USB keys, but that might not be a very good idea from a security standpoint if the USB keys are with the users all the time.

    When enabling BitLocker, I enable the check and it returns after restarting saying that it could not activate BitLocker because it could not connect to the TPM chip.


  • Moderator

    @Wayne-Workman Sorry we went to DM chat to work through the issues.

    The .0 thing was because his primary dhcp server was still handing out dhcp 66 and 67 and there was a dhcpProxy server (dnsmasq) sending out an Offer packet, so the target computer switched over to dhcpProxy mode and my configuration did not have that part configured (because its almost never used, except in conditions like this).

    We had to add this section.

    # PXEClient:Arch:00000
    pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
    
    # PXEClient:Arch:00007
    pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
    
    # PXEClient:Arch:00009
    pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi
    

    To create the complete config file here.

    port=0
    
    # Log lots of extra information about DHCP transactions.
    log-dhcp
    
    # Set the root directory for files available via FTP.
    tftp-root=/tftpboot
    
    # Disable re-use of the DHCP servername and filename fields as extra
    # option space. That's to avoid confusing some old or broken DHCP clients.
    dhcp-no-override
    
    # inspect the vendor class string and match the text to set the tag
    dhcp-vendorclass=BIOS,PXEClient:Arch:00000
    dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
    dhcp-vendorclass=UEFI,PXEClient:Arch:00007
    dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
    
    # Set the boot file name based on the matching tag from the vendor class (above)
    dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,10.1.0.102
    dhcp-boot=net:UEFI,ipxe.efi,,10.1.0.102
    dhcp-boot=net:UEFI64,ipxe.efi,,10.1.0.102
    
    # The boot filename, Server name, Server Ip Address
    dhcp-boot=undionly.kpxe,,10.1.0.102
    
    # PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
    pxe-prompt="Booting FOG Client", 1
    
    # PXEClient:Arch:00000
    pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
    
    # PXEClient:Arch:00007
    pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
    
    # PXEClient:Arch:00009
    pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi
    
    dhcp-range=10.1.0.102,proxy
    

  • Moderator

    As I understand it - you can’t capture an image from a system that is using bitlocker - unless you do it as a RAW type image - which is pretty much insane.

    @RobTitian16 said in Windows 10 Bitlocker Query:

    @george1421 Thanks, George.
    From what I can see, the system I’m trying to boot with is requesting the ipxe.0 from the FOG server, but that’s where the log ends.

    dnsmasq version 2.76 doesn’t do the .0 thing anymore. This would lead me to believe you’re not using 2.76, but an older version.



  • BitLocker requires either Trusted Platform Module (TPM) 1.2, TPM 2.0 or a USB flash drive (Windows 10 Pro and Windows 10 Enterprise only). There is even a way to disable the TPM requirement through Group Policy; though I haven’t tried it.

    The OS does not need to be installed as a UEFI system to be able to use BitLocker.

    The real question is, what do you mean that you can’t enable BitLocker? What are you trying to do with it and how precisely?


  • Moderator

    @RobTitian16 moving the discussion to DM.



  • @george1421 0_1480609373367_output.pcap

    It’s right at the end - 10.1.2.32 is the target host.
    10.1.0.102 is the FOG Server.


  • Moderator

    @RobTitian16 please post the pcap so I can take a look at it.



  • @george1421 Thanks, George.
    From what I can see, the system I’m trying to boot with is requesting the ipxe.0 from the FOG server, but that’s where the log ends.


  • Moderator

    @RobTitian16 Well then, now you get to play “Net Detective”.

    The only truth is what is flying down the wire.

    I need you to do the following:

    1. Install tcpdump on the FOG server.
    2. Setup tcpdump to capture this dhcp exchange between the target computer, dhcp server, dnsmasq, and the fog server. From the fog server linux console run the following command sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
    3. PXE boot the target computer to you reach the error
    4. Press Ctrl-C to exit out of the tcpdump program
    5. Review the output.pcap file with wireshark to see who is telling the client to request ipxe.0 -OR- post the pcap file here and we will take a look at it. My preference would be for YOU to look at the pcap file so YOU can see what is going on. But with that said we are here to help you learn too. Wireshark is an insanely complex program so using it for the first few times IS a bit daunting.

Log in to reply
 

420
Online

39.3k
Users

11.0k
Topics

104.6k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.