Hi everyone, we are implementing trustsec in our network of mostly cisco gear. We do have a limited number of MX64, 67s, Z3s, and Z1s though for home users. The MXs and Z3s already perform dot1x authentication to our ISE servers and works well. But now that we are implementing trustsec we are looking for a way to incorporate the Meraki users. I know Merakis can't do full trustsec enforcement, so our plan is to use SXP between our ISE servers and 9500s that the Meraki concentrator is connected too. This doesn't give us enforcement between Merakis, but at least gives us some protection from the Meraki network talking to the rest of the greater network.
The question i'm posing however, is even though we are doing dot1x auth from the Merakis to ISE, the radius request from the Meraki's to ISE do not include the IP address of the client who's trying to connect. I've been told from Meraki support that is expected behavior. So, the problem is our ISE servers are able to authenticate Meraki users, but they can't be assigned an SGT value even locally within ISE because the IP address is unknown.
Has anyone out there come up with a solution to classify Meraki clients within ISE so they have an SGT value? I've thought about using the Meraki API to extract IP and username values and import them into ISE, but it doesn't seem very clean.
>So, the problem is our ISE servers are able to authenticate Meraki users, but they can't be assigned an SGT value even locally within ISE because the IP address is unknown.
802.1x is a layer 2 protocol. It happens before a client can get a layer 3 DHCP address.
The only way I can think of would be to instead use splash page authentication which can only happen after the client has a layer 3 IP address. You could even do this centrally.
Bit of a pain for users have to splash page authentication everytime though.
That's an interesting idea...I'm not sure I would be able to get away with that from a user experience perspective, but would like to know if that forces the IP data to be included in the original radius auth.
Its interesting though on traditional Cisco catalyst switches the radius reqeust does included the IP data, but not in the first packet. Looks like its transmitted later, wonder why they can't do that for Meraki too.
As for classifying all as "Meraki Clients" thats kind of our last resort solution. Reason being we want to classify more granular then that. There are printers, PCs (with different OUs) APs, etc all plugged into these Merakis and from an SGT perspective want to classify them differently so that if an accountant goes into the office one day, then works from home the next, they continue to have the same SGT tag which gives them the same network access.