Windows 10 Bitlocker Query

[RobTitian16]

@george1421 Is that an l (as in lower-case L) or a 1? I may have typed it incorrectly, which is why I got that error.

So far so good, although I’m running into an issue when starting PXE over IPv4 in UEFI:

Start PXE over IPv4
Station IP address is 10.1.x.x
Server IP address is 10.1.x.x
NBP filename is ipxe.0
NBP filesize is 0 Bytes
PXE-E23: Client received TFTP error from server. 

I’m guessing it’s because the ipxe.0 file doesn’t actually exist. Where would I get this from?

[george1421]

@RobTitian16 actually, lets do a sanity check first.

You were able to compile the dnsmasq correctly?

If so you still need to configure it. I think maybe I should update my documentation to say you must install your distribution dnsmasq package first then compile this new version.

But once dnsmasq is installed then you need to configure it using the second link. There should be no ipxe.0 file ever used.

If you did not install your distribution’s dnsmasq package first no worries. Install it now, then go back into the dnsmasq 2.76 source and just rerun the make command. Then confirm that 2.76 is installed correctly.

[RobTitian16]

@george1421 Yep, I had dnsmasq installed. Then, I installed the 2.76 version. Then I configured the config file as you did in your post:

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,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,192.168.112.24

# 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

dhcp-range=192.168.112.24,proxy

Am I missing a step somewhere?

[george1421]

@RobTitian16

Well the first thing that jumps out at me is that 192.168.112.X needs to be the IP address of your FOG server. Other than that, it should work out of the box as long as the target computer and dnsmasq server are in the same broadcast domain (subnet). If it doesn’t then we need to get a pcap to see what is going wrong on the wire.

[RobTitian16]

@george1421 Yep, they’re definitely on the same subnet.

This is my full config:

# Sample configuration for dnsmasq  to function as a proxyDHCP server,
# enabling LTSP clients to boot when an external, unmodifiable DHCPserver is present.
# The main dnsmasq configuration is in /etc/dnsmasq.conf;
# the contents of this script are added to the main configuration.
# You may modify the file to suit your needs.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Dnsmasq can also function as a TFTP server. You may uninstall tftpd-hpa if you like and uncomment the next line.
#enable-tftp

#Set the root directory for files available via FTP.
tftp-root=/tftpboot

#The boot filename.
dhcp-boot=undionly.kpxe,,10.1.0.102

# rootpath option, for NFS
dhcp-option=17,/images

# kill multicast

dhcp-option=vendor:PXEclient,6,2b

# 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



# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 3

# A boot service type of 0 is special, and will abort the net boot procedure and continue booting from the local media.
pxe-service=X86PC, "Boot from local hard disk", 0

# If an integer boot service type, rather than a basename is given, then the 
# PXE client will search for a suitable boot service for that type on the 
# network. This search may be done by multicast or broadcast, or direct to a server if its IP address is provided.
# pxe-service=x86PC, "boot from Windows RIS server", 1

#This range(s) is for the public interface, where dnsmasq functions as a proxy DHCP server providing boot information but no IP leases.
# Any IP in the subnet will do, so you may just put your server NIC IP here. Since dnsmasq is not providing true DHCP services, you do not
# want it handing out IP addresses. Just put your servers' IP address for the interface that is connected to the nwtwork on which the FOG 
# client exists. If this setting is incorrect, the dnsmasq may not start, rednering your proxyDHCP ineffective.
dhcp-range=10.1.0.102,proxy

# This range(s) is for the private network on 2-NIC servers, where dnsmasq functions as a normal DHCP server, providing IP leases.
#dhcp-range=192.168.0.20,192.168.0.250,8h

#For static client IPs, and only for the private subnets, you may put entries like this:
# dhcp-host=00:20:e0:3b:13:af,10.160.31.111,client111,infinite 

And I think I’ve just realised what could be wrong… the “#The boot filename” section probably needs to be taken out, right? That’s from the previous installation of dnsmasq.

[george1421]

@RobTitian16 Please move this file to a safe place and use my config file as it is complete and the order the dhcp-boot as they were. What you have should work, but you have the dhcp-boot for undionly first, which may skip the uefi tets since it would be the first match. also you don’t need the dhcp-options settings. What I posted is a complete config file.

[RobTitian16]

@george1421 Okay, I’m now using exactly the same file as your tutorial:

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

dhcp-range=10.1.0.102,proxy

However, when booting from a UEFI boot on a Dell Latitude E6430, the system is still saying the same thing.

Start PXE over IPv4
Station IP address is 10.1.x.x
Server IP address is 10.1.x.x
NBP filename is ipxe.0
NBP filesize is 0 Bytes
PXE-E23: Client received TFTP error from server. 

[george1421]

@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.

[RobTitian16]

@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.

[george1421]

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

[RobTitian16]

@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.

[george1421]

@RobTitian16 moving the discussion to DM.

[sudburr]

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?

[Wayne Workman]

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.

[george1421]

@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

[RobTitian16]

@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.

[RobTitian16]

@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.

[RobTitian16]

@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.

[RobTitian16]

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

[george1421]

@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.