topic Re: Cisco ISE - Closed mode - PXE use case in Network Access Control

Cisco ISE - Closed mode - PXE use case

junk1 — Mon, 29 Feb 2016 16:13:24 GMT

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.

Re: Cisco ISE - Closed mode - PXE use case

Jason Kunst — Mon, 29 Feb 2016 20:24:22 GMT

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

Re: Cisco ISE - Closed mode - PXE use case

howon — Wed, 02 Mar 2016 17:18:07 GMT

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

Re: Cisco ISE - Closed mode - PXE use case

Melghafri — Sun, 13 Nov 2016 10:03:51 GMT

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

Re: Cisco ISE - Closed mode - PXE use case

howon — Mon, 14 Nov 2016 14:31:46 GMT

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.

Re: Cisco ISE - Closed mode - PXE use case

Charlyn3266 — Sat, 28 Jan 2017 14:15:19 GMT

How do you accomplish this?

Re: Cisco ISE - Closed mode - PXE use case

howon — Mon, 30 Jan 2017 14:49:32 GMT

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.

Re: Cisco ISE - Closed mode - PXE use case

Ralphy006 — Wed, 19 Jun 2019 17:04:43 GMT

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?

Re: Cisco ISE - Closed mode - PXE use case

Mo Pourmirza — Fri, 02 Aug 2019 14:40:57 GMT

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

Re: Cisco ISE - Closed mode - PXE use case

paul — Fri, 02 Aug 2019 14:59:00 GMT

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:

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

Re: Cisco ISE - Closed mode - PXE use case

Mo Pourmirza — Mon, 05 Aug 2019 21:23:43 GMT

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?

Re: Cisco ISE - Closed mode - PXE use case

paul — Mon, 05 Aug 2019 00:51:24 GMT

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.

Re: Cisco ISE - Closed mode - PXE use case

Mo Pourmirza — Mon, 05 Aug 2019 21:22:21 GMT

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

Re: Cisco ISE - Closed mode - PXE use case

Ciscouserz — Fri, 30 Aug 2019 18:46:12 GMT

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.