Hi all,
The certificate we currently use for RADIUS/EAP on one of our SSIDs is expiring. We already have the new one and ideally want to do an overlapping service using the new one in parallel to give devices chance to migrate, and so we can see what is still to migrate.
With PEAP this has been fairly simple, we've specified an outer identity on reconfigured clients, and then created a new service definition in Clearpass that looks for a Radius:IETF Username of this specified identity and offered the new certificate if it's found. Sadly we've not previously used outer identities for identification, so it's a case of "look for this attribute, if found use new service, if not found use old".
The issue we've now hit is with EAP-TLS clients. The supplicants don't seem to pass the outer identity (even though some research has confirmed it's in the spec) and as such we're a bit stuck how to stop these from dropping through to the old service. Looking at the Radius attributes of the requsts I was hoping to see something I could differentiate on but sadly there's nothing. No EAP-TLS clients should be using the old service anyway (as they're the easy ones to switch over) so if I could somehow have three services, one that only listens to EAP-TLS, one that listens to PEAP with the outer identity and then the fallback that just listens to PEAP with no outer identity requirement that would be ideal. However, setting up a service with the constraint of "Radius:Aruba > Aruba-Essid-Name > OurSSID" that only listens to EAP-TLS would immediately catch and fail all the PEAP ones to. Is anyone aware of a way to do a fall through on this, so that if a PEAP request comes in it bypasses the first service and moves onwards?
Cheers,
Luke