ExtremeControl Profiling

[Edsond]

Hi everyone,

In addition to dhcp pofiling, what are the other methods supported by ExtremeControl to identify the end-system Operating System?

When the switch port/or wifi is 802.1x enabled, only EAP traffic is allowed. So, no matter how much the end-system is sending DHCP Request, this traffic will not be allowed to pass through the port. Therefore, the DHPC Relay configuration pointing to ExtremeControl will have no effect. Am I right or wrong?

I created a rule in the NAC to authenticate via 8021.x only end-system running Windows 10 and 11 and when the end-system is first seen, the NAC didn't know who it was.

The switch is sending the DHCP request to the network, the NAC is receiving these DHCP Requests, however, this is only sent when the challenge imposed by the EAP is processed. Before this, only EAP traffic passes through the port or wireless network.

If the first packet that arrives at the NAC is from RADIUS, how will the NAC know which operating system is in use by the end-system?

I would appreciate it if we could talk more about this.

Thank you very much,

Edson Moura

[Edsond]

Hi Bartek,

This could work with a wired network. But, how does it work on a wireless network with WAP2/3 Enterprise?

Thanks,

Edson Moura

[Bartek]

Hi,

I've made a screenshot of working example in my lab so I ensure it works. In "accepted solution" you mentioned only about the wired network so I didn't try any wireless as irrelevant for you.
In wireless I would try to use PPSK with MAC-based authentication enabled to let NAC appliance do the magic. I can check this in my lab when I come back from my holiday. I believe it would be a KISS solution but I am interested of your solution using only 802.1x (I suppose that CoA would be required). What kind of wireless solution are you using now?

[Edsond]

Hi Bartek,

I'm using Extreme Cloud IQ with 802.1x.

Thanks,

Edson Moura

[Configterminal]

You are definitely not wrong with your points and I'd be curious how others have handled this with XMC-Control. 

My immediate thoughts are the following although I've never attempted this  on Control but you can do something like this in ClearPass - You can create a rule that sends back an ACL plus the proper VLAN for the device.  The ACL will limit what the device can talk to, e.g.: DHCP Server, XMC NAC Engines, etc.  This will allow the Client to perform the DHCP process and receive an IP but not much else - it will of also sent the DHCP Info to the NAC Engines so they can profile accordingly.    Once this process is done, ClearPass (or XMC-Control in this case I hope) can issue a CoA and the device should now hit the proper rule giving it the proper access as long as the fingerprinting was done correctly.

I am curious as to how others have handled this as I was thinking of implementing Device Types in my rule set as well but unsure as to how to perform a CoA after fingerprinting is successful

[Robert_Haynes]

You can see the various means of OS 'Device Type Detection' under Control -> Engines -> Engine Settings -> Device Type Detection. Agent-based assessment removed (defunct feature) Control will rely on DHCP Fingerprinting or Captive Portal interaction for this.

OS detection is performed after authentication of the device. If DHCP Fingerprinting is to be successful the DHCP flow should be relayed to Control (or mirrored) in addition to actual relay configuration to real DHCP servers. This way Control gets a glimpse of the DHCP exchange.

'You would never know the operating system of a device simply via EAP/RADIUS exchange. EAP/RADIUS is vendor/device agnostic.