Bit Locker Network Unlock Without Low Impact on L2 Before Radius Auth

[jbulloch]

Good afternoon cisco community,

Recently our desktop support team approached in regards to getting bit locker networker unlock running to do WOL pushes to asleep machines.

In our environment, we are currently in a full 'closed' deployment of  ISE with dot1x. There a few legacy devices doing MAB. As part of this setup, we use a L2 (No SVI) vlan across our standard template on user facing interface. When the supplicant does it's EAP talk to the authenticating network device, the bundled radius traffic then pulls down the DACL with the assigned VLAN access from the identity store. This works as intended.

The problem becomes that most implementations for this will suggest you use a pre-auth ACL and low impact mode. In order to get the eap traffic through in that setup you would need to use auth open. It does not appear that direction in would allow the eap traffic to flow pre-boot to windows in the UEFI steps. Corporate folks have blacklisted the use of auth open. In addition, it would be difficult to do WOL steps without a SVI to do the broadcast for the DHCP requirement.

As anyone been in a similar situation and how did you adjust your environment to allow for the unlock?

Would it be possible to use a guest vlan with routing information and enforce it against a MAB database before applying pre-auth DACL? I am looking into this possibility with ISE. Can the guest vlan be L3?

Thank you for any possible assistance. 

[Arne Bier]

Is this an issue you have actually run into, or is it just a theoretical consideration/question?  I don't know if the UEFI Secure Boot needs network access at the point where the boot loader prompts the user for the Bitlocker password. It's my educated guess that once the key is entered, the rest of the OS boots, and then the supplicant gets initialized etc.

If the situation is more complicated than that (because you mention WOL), then I guess the question is whether a remote party can access the bitlockered machine, after it's awoken with WOL process.  The command

access-session control-direction in

is indeed used for that, and as far as I know, has no bearing on the closed mode EAP setup. The pre-auth ACL doesn't control the ability of L2 traffic to pass (e.g. EAPOL)

[Arne Bier]

A similar Community question was posted recently - have a look to see if that helps.

[jbulloch]

Hi arne,

Thanks for the reply. I've been in that other thread too yesterday hoping the inital poster might provide feedback on their setup.

This is indeed a situation i am currently facing. We coporate wise work with several government agenices here in our neck of the woods, so we must have this paticular network set to thier standards. One of those standards is to have all ports facing the users - aka those ports which leave the IDF to a wall plate - be set to a unused vlan. So we have a vlan tag we all agreeded on to use for this, which does not get a SVI. This is as you would expect not a big deal for ISE and it functions fine in applying the DACL and tag.

The problem is then both for the access control and the bit locker unlock and then the WOL componet of waking the machine. I know WOL can work, as i have built it on a static (switchport mode access to an actual svi) and tested it. But it would be difficult to:

A. ) Do the helpers and directed broadcast on the unused vlan as it does not have a svi.

B.) Allow the machine to be PXE booted with WOL to do the bit locker unlocker when its powered off/asleep 

My understanding has also been that both 'auth control' and 'access control' direction can be used in conjuction - auth control for controling auth traffic during auth, and 'access control' for controling access based on the auth status. 

My understanding of this is once the WOL packet is received by the machine for PXE, machine would then contact DHCP and do go through ISE and get a DHCP address. Then the DHCP server settings forward the DHCP unlock request to WDS server through a broadcast, similar to an option for a TFTP boot on a thin client but not quite. Once the key is received, machine can boot to windows and go through dot1x with ISE just fine.

For this reason a lot of people will suggest pre-auth ACL and auth open, including thread we noted above. However various higher engineering folks are requesting not to use auth open.   

I have used 'auth control direction in' on my functioning WOL setup, so i suppose they can both be used if you don't want to use both either.

However i don't think the machines will forward any radius traffic during the PXE boot until it hits windows, so i'am also now not sure why auth open would be neededed. Since the pxe boot wouldn't be sending any eap traffic to the switch to send radius traffic to ISE.  Am i correct in this thinking?

[jbulloch]

I've come to the conclusion that auth open might not be needed here, but i will need to get coporate on board with the need for the network to be broadcast able (aka l3) - this is on going.