Wired 802.1x, Pre-auth ACL, PXE Booting

[Ralphy006]

Hi guys,

I've reviewed the "Low Impact Mode" 802.1x guides as well as other posts that allow PXE booting with a Pre-Auth ACL.

Scenario 1: Low Impact mode with Pre-Auth ACL

• Pre-Auth ACL allowing dhcp, dns, tftp and internet access
• Authentication OPEN
• If dot1x and MAB fails, we keep the pre-auth ACL
• This handles allowing PXE booting, and allows guest devices to have internet access only
• If ISE ever becomes unresponsive, anything that joins post failure, will have the pre-auth ACL

Scenario 2: Closed mode

• Authentication closed
• if dot1x and MAB fails, we throw on a DACL that allows DNS, TFTP for PXE, and Internet access

With Scenario 2, has anyone had good experiences with PXE booting?

Thanks!

[craig.beck]

Configured correctly, it'll work. Generally though, if authentication fails, in closed mode the port won't pass any traffic.

However, you can use MAB to allow unknown MAC addresses to pass authentication. This will give you what you want but to be honest I'd say it's just an unnecessary overhead for ISE to deal with in your scenario, given that you're allowing internet access too. Low-impact mode does it without having to process the request via authorization rules (as authentication fails so authorization rules will never be queried) so unless you need to apply something via RADIUS there's little-to-no point in doing it in Closed mode.

[Ralphy006]

Thanks for the response. I'll give it a shot with PXE booting. I'm a little skeptical that it will work but I'll let you know.

The reason we still send MAB to ISE is for the following scenarios:

1. Some MAB'ed devices will get MORE access than just internet (ie printers, security cameras, etc). So depending on the ISE identity Group, we have different MAB AuthZ results
2. Low impact mode seems to ask for a pre-auth ACL. The pre-auth ACL is a bit problematic for us, because if the switch ever deems ISE as unresponsive, any new connection would fail open (assuming we have a our dead server criteria done correctly), but the pre-auth ACL would remain intact. The company is a bit risk adverse in the sense of potential downtime if ISE ever choked.

[craig.beck · Accepted solution]

I think I may have worded my last response poorly... apologies.

There's two ways to look at it...

1] Use low-impact mode and apply the preauth ACL as a default. This will apply to anything that fails (normal for low-impact mode). Successful authentications can and will still be authorized by ISE though and a specific dACL can be pushed for desired devices, groups, etc.

2] Use closed mode and allow MAB failures to be authorized by ISE to apply a dACL to those devices, as well as successfully-authenticated devices.

The difference between the two is that in closed mode only EAPoL traffic will pass through the port until the device is authenticated and authorised - a preauth ACL won't work in closed mode. In allowing unauthenticated devices to be authorised in closed mode you're effectively just emulating low-impact mode though, hence mentioning that it's probably pointless.

If you're worried about ISE becoming inaccessible that would also push me towards low-impact mode. However, you could look at using Inaccessible Authentication Bypass instead. When ISE is unavailable the switch will drop everything into a specific VLAN. That may or may not be suitable in your scenario though, but it's an option for some.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-0_1_se/configuration/guide/3750xcg/sw8021x.html#49907

[Ralphy006]

Thanks. I still need to figure out how to handle the PXE booting.

It's very much a chicken or the egg.

Basically, when a laptop does an upgrade via PXE booting, the machine loses it's supplicant configuration.

The machine would need access to PXE (SCCM), our windows PKI and windows AD to enroll in order to become fully authenticated again.

Options I am considering:

1. Create an AuthZ rule where if something was previously profiled and authenticated, and ends up trying MAB, put it in an interim vlan that has access to PXE booting, PKI and AD. These DACL's would get a little messy unless we allow all IP. Another problem with this, is that MAC address spoofing would fall into this category as well
2. Profile PXE booting somehow via the DHCP request. Not 100% sure how to profile this properly
3. Force PXE booting to be done in a physically secure area

[craig.beck]

You're absolutely right.

Using MAB with an endpoint group (for devices needing to PXE) in an authz rule is generally how I've seen and done if PXE booting is required at any switchport in any location. This at least enables you to identify what's using PXE and what isn't (guests or other devices, for example), so the right attributes get pushed to the switch. Unfortunately there's not much more that you can do that's simple to implement if you want to apply a specific dACL/VLAN to devices needing to be rebuilt via WDS/SCCM. DHCP profiling can be used in conjunction with an authz rule but you obviously have to a) be using profiling and b) be sending DHCP info to ISE. Remember, profiling can be hard on ISE if it isn't configured correctly.

WinPE can use user-based 802.1x so you could create a policy in ISE that allows devices to authenticate using a specific user account (backed-off to AD if you want) when they boot into WinPE, but you'd need to allow some access beforehand using MAB (or a default preauth ACL in low-impact mode). Microsoft has some good resources which show how to configure the XML file required to configure the supplicant in WinPE.

Most places I've seen that use a secure switch/area to do imaging will just have a pretty-flat switch with nothing on it apart from maybe a bit of multicast config. Obviously that's highly restrictive in terms of where you can rebuild machines though.