Cisco ISE and IGEL thin clients

[rojersmirth]

Hi gang. We're using IGEL thin clients and the latest version of ISE for profiling. I"ll preface with the fact that i don't speak Cisco and we're having big issues with IGEL 'authenticating' with the network. We have an IGEL scep profile that handles a scep cert. a ton of our devices will never auth with 802.1x. when our ise engineer looks at the port, the device is passing the mac address for the mac and for the device name (hostname). has anyone seen this issue or have an advice? thanks!

[balaji.bandi]

we hear that what is the Logs show in ISE, what is causing the failure ?

if the device able to use certs to join ?

[Greg Gibbs]

There is not enough information to provide any meaningful assistance here. See How to Ask the Community for Help.

If you are not able to provide the necessary details, your best bet would be to open a TAC case to work with someone directly to replicate the issue and gather the necessary troubleshooting information.

[hatfir]

To expound on the issue, when an iGel device run through an ISEd port, it is blocked, as expected. However, there is nothing identifiable in the information assed to ISE for the device. The hostname is the MAC, which is obviously unique to the single device, and there is nothing in any field that would identify the device as an iGel device.

Because of this, there doesn't seem to be a way to create a profile for it. We could simply allow all "Dell" devices, but that leaves us far more open than we would like and greatly defeats the purpose of ISE.

We need to know what we can use to create a profile for iGel devices on the network that would both allow the devices and keep the security that ISE affords.

[Greg Gibbs]

If the thin client is not capable of using 802.1x to authenticate to the network, then you're limited to using MAB. ISE Profiling is mainly based on what we can learn about the device from the network, which is highly dependent on the endpoint itself. If the device supports SNMP, you could use the NMAP probe to query the device itself for information. Something like this typically involves testing what info you can get about the device when connected to the network (ideally in a test environment first) and creating a custom profiling policy to suit. Profiling is always considered a 'best guess' so it will never be as secure as an active authentication method like 802.1x.
Another alternative (if there is not a reasonable amount of profiling available) would be to create an Endpoint Identity Group, create an authorization policy that uses that EIG, and add all of the IGEL MAC addresses to that group.

See the Profiling Design Guide for the various options.

[hatfir]

Thank you for the prompt reply!

Our issue is more of a chicken and egg problem. The thin client is capable of 802.1x configuration, but we have no mechanism to get the 802.1x profile onto the box without it checking into a server to get the config. However, it cannot get the config/connect to the server without having the 802.1x profile.

What we need is a way to identify these boxes as being ones we want to be able to connect to the server to get the profile without allowing all devices to do this. We also have a SCEP server, but we have the same issue. A new box on the network doesn't know where the SCEP server is, so it doesn't knwo to go there to get a cert to allow it to 802.1x authenticate.

Alternatively, we could allow all unauthenticated machines to see that one server and the two ports required for a profile to be delivered to it. If the requesting machine is not an iGel, it won't know what to do with the config nor will it be in the iGel console to profile. Obviously, not allowing all noncompliant machines access to a server even in a limited fashion is a security risk, so if we could determine whether a machine has a given name/OS/whatever on it and only allowing those access to the server would be the better answer.