Cisco ISE - Closed mode - PXE use case

[junk1]

Hi

In my ISE customer network, there is a scenario for PXE boot users who need access to the imaging servers much before their Dot1x supplicant kicks in. In their current dot1x infrastructure using NPS, they have "Pre-Auth ACL" with "authentication open" command configured to provide access to the PXE boot users to the required servers. In close mode with Cisco ISE, how do we address this?

If we retain the Pre-Auth ACL, in the situation of all PSNs go down, the Critical VLAN will not be effective because of the existing Pre-Auth ACL. Correct?

To move towards Critical ACL feature (IBNS 2.0), many of the customer network devices are not supported. It requires a massive upgrade.

Is it a good strategy to use EEM scripts in the switches to append the ACL with full access when all RADIUS servers go down, till the time they move to Critical ACL feature?

Please suggest a solution.

Thanks in advance, Regards

V Vinodh.

[Jason Kunst]

I would suggest to reach out to the IBNS team as this is a switching team question

[howon · Accepted solution]

If using closed mode, the EAP timeout and retries should be trimmed down to very low value to accommodate PXE boot. Currently we recommend 10 seconds for tx-period and leave everything to default for general operations, but you can start out by setting tx-period to 2 seconds, and max-reauth-req value to 1. As you test this I suggest gradually increasing the tx-period value while testing that the PXE booting still works. Sample config to start here:

interface GigabitEthernet0/1

description ACCESS (Multi-Domain w/ Closed Mode)

switchport access vlan 10

switchport mode access

switchport voice vlan 11

authentication control-direction in

authentication event fail action next-method

authentication event server dead action authorize

authentication event server dead action authorize voice

authentication event server alive action reinitialize

authentication host-mode multi-domain

authentication port-control auto

authentication periodic

authentication timer reauthenticate server

authentication timer inactivity server dynamic

authentication violation restrict

mab     

dot1x pae authenticator

dot1x timeout tx-period 2

dot1x max-reauth-req 1

[Mo Pourmirza]

What is the best practice for the authentication order and priority for PXE boot? Shall we configure mab for the first order and dot1x as the first priority.

authentication order mab dot1x

authentication priority dot1x mab

[Melghafri]

Hi Howon,

I have a question about your reply here.

How PXE will work while the interface is under closed mode? after dot1x failover and mab failover, the port will be unauthorized and will not allow any inbound traffic.

How the PXE request packets and the TFTP request packets will go through?

Waiting for your feedback.

Thanks

[howon]

With closed mode the default policy (When none of the specific policy matches) on the ISE should be configured to send down dACL/VLAN to support PXE. This may include access to DHCP, DNS, TFTP, and other ip/ports needed to accomplish the O/S image to be setup.

[Charlyn3266]

How do you accomplish this?

[howon]

With closed mode no traffic can pass through aside from 802.1x/CDP/STP. You will need to allow traffic via MAB when the port falls back from 802.1X. So on the ISE, create a policy that allows access to DHCP/DNS/TFTP for unknown MAB devices.

[Ralphy006]

So we tried this, but realized not only do we need DHCP, DNS, and PXE boot (TFTP and 4011), we also need to allow the windows device to have access to Active Directory to Enroll (I'm guessing this would be a ton of ports), as well as access to our PKI server.

Any thoughts on that level of access given to "unknown" devices?

[paul]

You can try to profile your way through the PXE boot/image process but that can be a challenge as there are multiple phases and each have their unique challenges.  Here is how I usually handle this with most of my customers:

1. Most of the reimaging should be happening in build rooms that have secure access controls and dedicated switches.  In this case we will only deploy ISE in monitor mode on those switches.
2. If the customer has a small amount of in place reimaging needs we have the desktop team use the ISE temp bypass portal we setup to put the MAC address of the device they are reimaging.  This allows the device onto the network for that day. 
3. If the customer has a large amount of in place reimaging needs they can use a program I wrote in their reimaging process that will automatically take the MAC address of the machine and put it into the temp bypass list via REST API calls.  You still need to profile your way through the first two phases of a PXE boot reimage process but that is pretty straight forward (DHCP client identifier contains PXEClient for phase 1 and DHCP hostname contains minint for phase 2)

[Mo Pourmirza]

Hi Paul,

My customer has over 10000 PCs across their network. So, my approach would be the option 3. However, my implementation is a bit different. I have created an Endpoint Identity group lets say PXE_Devices which is used in the authorization policy. So, if a PC's MAC address is in the group, a dACL allowing PXE access(SCCM,...) will be pushed to the switch port that the PC is connected to. Also, I have created an admin policy for the desktop team to be able to add the MAC addresses into the PXE_Devices. Before they re-image a PC, they need to login into ISE where they only see the PXE_Devices group. They can start imaging once the MAC address is added. I have also created a purge policy which deletes the PXE MAC address after  a day. Here is the main port configuration for PXE (IBNS 1.0):

authentication order mab dot1x
authentication priority dot1x mab

dot1x timeout tx-period 7

Can you please explain how you use the REST API call to put the MAC addresses in a temp list? Do you ask the desktop team to execute the API using Postman?

[paul]

I created a C++ executable program that customers have incorporated into their WinPE image. So everything is automated. One of my customers took my source code and coded it into Python and then made it into a executable.

[Mo Pourmirza]

Sounds Great! Do you have this code on GitHub by any chance?

[Ciscouserz]

Interesting topic.

Another way would be to add users already authed into a endpoint group, and if these clients tries to auth via mab they will have access to SCCM AD etc.