The FDE pre-boot is network aware, but is not capable of 802.1x authentication, a popular method of protecting company infrastructure assets by securing network switch ports with logical machine or user identification and authorization.
You may implement 802.1x Network Access or Admission Control while still allowing the FDE pre-boot to communicate with the PolicyServer at pre-boot in order to authenticate users without cached credentials, retrieve policies, and remediate expired passwords.
Here are the things to consider before doing the procedure:
- A high familiarity with 802.1x network configuration, VLANs, IP routing and switching, ACLs, DHCP, DNS and firewall concepts
- Some familiarity with the Endpoint Encryption Security Suite, specifically configuration of FDE clients and connectivity to PolicyServer
- Target enterprise with a switched environment with multiple VLANs and 802.1x authentication, which is configured and working
- Target enterprise with complete initial testing and limited pilot deployment of PolicyServer and FDE
Below are the two types of configuration you may implement:
Most 802.1x capable switches are able to set a ‘guest’ or ‘dirty’ VLAN to which any given switch port will be set when a client device connected to it does not respond to a request/identity packet, indicating it is not capable of 802.1x authentication. Many organizations use this ability to provide a VLAN with only Internet connectivity to office guests. In this configuration the feature set is leveraged to provide a protected VLAN where connectivity to the PolicyServer is available to the FDE pre-boot while remaining segmented from the production network. Organizations already providing Internet access to guests via dirty VLAN may choose to add their PolicyServer to this network instead of creating an explicitly non-routed network.
Minimum requirements
- Server VLAN (production server systems) must contain:
- AAA server
- One (1) NIC of the dual homed PolicyServer
- IP Connectivity to the 802.1x Network Access Device (switch)
- Production VLAN (fully routable production clients) with DHCP server or IP helper (if static addressing is not being used for clients)
- Dirty VLAN (non-routable network target for FDE or unauthorized clients only) must contain:
- One (1) NIC of the dual homed PolicyServer
- DHCP server
- DNS server
Checklist
- The server hosting the PolicyServer front end should be provisioned with two network interface cards, each with static IP addresses; one available to the production VLAN and one on the guest VLAN.
- Ensure that the IIS site hosting the PolicyServer web application is set to listen on all IP addresses.
- FDE clients should be installed against the PolicyServer by FQDN.
- Follow your switch vendor’s configuration to create the guest VLAN and do not assign an IP address to the switch VLAN interface.
- Follow your switch vendor’s configuration to assign this VLAN as the default for machines that are not 802.1x capable.
- Create a DNS server on the guest VLAN and give it a scope for the the domain name which hosts your production PolicyServer IP. This is a copy of the production zone and needs only to contain a host entry for the PolicyServer. The service can be run on the PolicyServer, ensuring that only the IP attached to the guest network is listening for DNS requests.
- Create a DHCP server on the guest VLAN offering addresses on the same subnet as the PolicyServer guest VLAN IP and guest VLAN DNS server. Scope options should point DNS to the DNS server and need not contain a default gateway.
Due to lack of hardware resources, organizational barriers to deployment, or time required for change management procedures, some organizations may choose to use a routed dirty VLAN instead of the locked VLAN in the previous example. In this example, the same mechanism is used to switch FDE client to the dirty VLAN, however connectivity to the PolicyServer is driven through the production network, and other production systems are protected from unauthorized clients by an ACL placed on the switch VLAN interface. This has the advantage of not requiring two (2) NICs on the PolicyServer or the additional DNS and DHCP servers required for the locked VLAN. It does, however expose the production network to routing and ACL attacks, and carries increased support time, as changes to IP, routing, or DNS may require configuration changes to the switch ACL.
Below are the minimum requirements:
- Server VLAN (production server systems) must contain:
- AAA server
- PolicyServer
- IP Connectivity to the 802.1x Network Access Device (switch)
- Production VLAN (fully routable production clients) with DHCP server or IP helper (if static addressing is not being used for clients)
- Dirty VLAN (non-routable network target for DataArmor or unauthorized clients only) must contain:
- IP helper where necessary to the production DHCP
- Access Control List permitting IP connectivity to the DNS Server and PolicyServer
Here are the common issues you may encounter with 802.1x authentication:
- FDE does not acquire an IP address at pre-boot.
This happens because the DHCP is improperly configured or the switch takes longer than 30 seconds to activate guest VLAN.
To fix this, verify the DHCP configuration, possibly retest with a stock Windows PC, and retry. You may also lower the amount of time the switch waits for dot1x authentication from client; on Cisco IOS this command is Switch (config-if)# dot1x timeout tx-period <seconds>, or on some versions Switch (config-if)# dot1x timeout supp-timeout <seconds>.
- Windows does not have a network connection upon boot-up.
One of the following causes the issue:
- Windows timed out NAC/SOH/DHCP request because port is still in quiet period at Windows networking start.
- Windows fails NAC/SOH/DHCP because the port has expired the quiet period and timeout tx-period after restart.
To resolve the issue, decrease the time the switch remains quiet following a failed auth exchange; on Cisco IOS this command is Switch(config-if)# dot1x timeout quiet-period <seconds>. You may also increase the time the switch remains quiet following a failed auth exchange; on Cisco IOS this command is Switch(config-if)# dot1x timeout quiet-period <seconds>. You may also modify this via Windows Group Policy, configure "System/Logon>Always wait for the network at computer startup and logon" to "Enabled" and set the "Network Connections" service startup type to "Automatic".