Hi – Just want to say these are a great series of videos.
When I try to authenticate a client using the default Wireless MAB condition using the Cisco device profile everything works as expected however when I try to authenticate a client using the default Wireless 802.1x condition I am unsuccessful.
The Cisco device profile has a default Wireless 802.1x condition that matches the following in the RADIUS request:
– Radius:NAS-Port-Type = Wireless – IEEE 802.11
– Radius:Service-Type = Framed
According to Meraki support WPA2-Enterprise with 802.1x only supports the following attributes:
– UserName
– NAS-IP-Address
– NAS-Port
– Called-Station-ID
– Calling-Station-ID
– Framed-MTU
– NAS-Port-Type
– Connect-Info
Obviously only NAS-Port-Type is matched.I can create a custom condition for Wireless 802.1x containing the following which works:
Radius:NAS-Port-Type = Wireless – IEEE 802.11
However I cannot use the default Wireless 802.1x condition for some reason – any ideas? Wireless MAB works fine which uses NAS-Port-Type and Service-Type but I do not understand why it works (service type isn’t in Meraki’s supported list)…
It may be due to “Radius:Service-Type = Framed”. This was for some reason not included in some past code revisions. What I would do for the time being is duplicate the wireless 802.1x policy and remove the “Radius:Service-Type = Framed” line. This has been resolved however in the current GA and Beta.
Where you say “This was for some reason not included in some past code revisions” are you referring to Meraki or ISE? Also, where you say it has been resolved in the current GA – What is GA? and again is this referring to Meraki or ISE?
I have made the custom policy as you suggest and that works.
Thanks
Loading...
I am referring to this info was not included in the radius access request in some of the past Meraki code releases. When I say GA I am referring to General Availability – current stable release code that is considered up to date in dashboard
Loading...
I am having the exact same problem that Ben Cook and the firmware of the APs in the Meraki Dashboard claims to be “Up to date”.
I’m using ISE to authenticate Wireless 802.1x corporate users against the AD using PEAP-MSCHAPv2. Using the default Wireless 802.1x compund condition (which uses Radius:Service-Type = Framed) simply does not work. The rule is skipped and the request ends up being catched by the default authentication rule. I created a new condition with only Radius:NAS-Port-Type – Wireless – IEEE 802.11 and now that rule catches the request.
However, the same thing happens with the Authorization rule. Meraki seems to not understand Radius:Service-Type and the rule that uses it gets skipped. If I get rid of that attribute and try to match on an AD group, it also won’t match. Is there a way to create different authroization rules on ISE based on different AD groups if my APs are Meraki?
Thanks!
Alfonso
Loading...
Alfonso, this issue should be resolved in R24.8 and newer. If you are still experiencing the issue, please try upgrading to R24.11 or R25.7. That being said, the service-type=framed is an attribute that should be sent from the Meraki AP. So the issue is not with the APs not understanding the attribute, it’s that the APs were just not sending it in the first place. This was a bug in code.
You can absolutely have different rules based on AD groups. Whether it is Meraki or not, the information needed to gather what AD groups a user is part of is provided by the Active Directory query for the user account from ISE to the AD server. The Access points (and really any radius endpoint) act as a conduit between the client and the radius server to simply assist in converting the authentication traffic from EAPoL to Radius, and once that is complete, taking the radius access_accept + attributes and converting that to an access state within the infrastructure.
Hi – Just want to say these are a great series of videos.
When I try to authenticate a client using the default Wireless MAB condition using the Cisco device profile everything works as expected however when I try to authenticate a client using the default Wireless 802.1x condition I am unsuccessful.
The Cisco device profile has a default Wireless 802.1x condition that matches the following in the RADIUS request:
– Radius:NAS-Port-Type = Wireless – IEEE 802.11
– Radius:Service-Type = Framed
According to Meraki support WPA2-Enterprise with 802.1x only supports the following attributes:
– UserName
– NAS-IP-Address
– NAS-Port
– Called-Station-ID
– Calling-Station-ID
– Framed-MTU
– NAS-Port-Type
– Connect-Info
Obviously only NAS-Port-Type is matched.I can create a custom condition for Wireless 802.1x containing the following which works:
Radius:NAS-Port-Type = Wireless – IEEE 802.11
However I cannot use the default Wireless 802.1x condition for some reason – any ideas? Wireless MAB works fine which uses NAS-Port-Type and Service-Type but I do not understand why it works (service type isn’t in Meraki’s supported list)…
It may be due to “Radius:Service-Type = Framed”. This was for some reason not included in some past code revisions. What I would do for the time being is duplicate the wireless 802.1x policy and remove the “Radius:Service-Type = Framed” line. This has been resolved however in the current GA and Beta.
Where you say “This was for some reason not included in some past code revisions” are you referring to Meraki or ISE? Also, where you say it has been resolved in the current GA – What is GA? and again is this referring to Meraki or ISE?
I have made the custom policy as you suggest and that works.
Thanks
I am referring to this info was not included in the radius access request in some of the past Meraki code releases. When I say GA I am referring to General Availability – current stable release code that is considered up to date in dashboard
I am having the exact same problem that Ben Cook and the firmware of the APs in the Meraki Dashboard claims to be “Up to date”.
I’m using ISE to authenticate Wireless 802.1x corporate users against the AD using PEAP-MSCHAPv2. Using the default Wireless 802.1x compund condition (which uses Radius:Service-Type = Framed) simply does not work. The rule is skipped and the request ends up being catched by the default authentication rule. I created a new condition with only Radius:NAS-Port-Type – Wireless – IEEE 802.11 and now that rule catches the request.
However, the same thing happens with the Authorization rule. Meraki seems to not understand Radius:Service-Type and the rule that uses it gets skipped. If I get rid of that attribute and try to match on an AD group, it also won’t match. Is there a way to create different authroization rules on ISE based on different AD groups if my APs are Meraki?
Thanks!
Alfonso
Alfonso, this issue should be resolved in R24.8 and newer. If you are still experiencing the issue, please try upgrading to R24.11 or R25.7. That being said, the service-type=framed is an attribute that should be sent from the Meraki AP. So the issue is not with the APs not understanding the attribute, it’s that the APs were just not sending it in the first place. This was a bug in code.
You can absolutely have different rules based on AD groups. Whether it is Meraki or not, the information needed to gather what AD groups a user is part of is provided by the Active Directory query for the user account from ISE to the AD server. The Access points (and really any radius endpoint) act as a conduit between the client and the radius server to simply assist in converting the authentication traffic from EAPoL to Radius, and once that is complete, taking the radius access_accept + attributes and converting that to an access state within the infrastructure.