cancel
Showing results for 
Search instead for 
Did you mean: 

NAC RADIUS attributes for C35 controller running 10.01.04.0011

NAC RADIUS attributes for C35 controller running 10.01.04.0011

Scott_Van_Arts1
New Contributor II
We are in the process of migrating from WC4110 controllers to C35 controllers. We use NAC to authenticate the users against AD. This works perfectly on the older controllers. However, not working so well on the new controllers. Apparently there is a minor change needed to get the authentication working correctly.

For the WC4110, we have them set up in a NAC appliance group:

Switch type: Layer 2 O-O-B
Primary gateway:
Secondary gateway: none
Auth Access Type: Network Access
Gateway RADIUS Attributes to Send: Extreme IndentiFi Wireless

f51efe35a52245a198c8711224d0cf77_RackMultipart20161028-102485-1ir54be-nac-radius_inline.png



The rule is set as follows:
Authentication method: 802.1x
User group: LDAP-USERS
End-system group: Any
Device Type Group: Any
Location group: ENTERPRISE (this is the name of the VNS on the controller)
Time group: Any
Profile: ENTERPRISE_BYOD
Portal: Default

f51efe35a52245a198c8711224d0cf77_RackMultipart20161028-51278-8fo41o-nac-rule_inline.png



This works perfectly with our old controller. The users authenticate via 802.1x, LDAP lookup works, they come back and hit the right rule on the NAC and the correct role is returned to the controller.

However, with this same setup in the NAC for the C35, it does not correctly identify the location group and the rule fails, thus returning the default profile rather than ENTERPRISE_BYOD which is what we want.

I believe this is related to how the C35 switch entry is defined on the NAC. I believe the C35 must need a different setup for the Auth Access Type and Gateway RADIUS Attributes to Send fields than how it is defined for the WC4110.

I realize that's somewhat confusing so if you need more info please ask.
14 REPLIES 14

So here a example if you run the evalution tool (description above) and the rule fails because of a missmatch in the location group = request from the wrong IP.

In the top section you'd see the source information of the request.
Could you check/post that so we'd make sure that the request is coming from .14/.15 with the correct parameters.

06fd0f7709b8470d870689db6552cff4_RackMultipart20161029-11105-1v2ygu2-NAC_evaluation_detail_inline.png


Just a wild guess.... could it be that you've the admin port of the controller connected to the network and the controller is sending the RADIUS requests via that port = isn't using the 10.140.20.x address and the rule doesn't match

Sure thing. There are 4 switch entries here. My two old controllers .10 and .11, and my new C35's .14 and .15. This rule works as intended with .10 and 11 but does not trigger with .14 and 15 and so the users are authenticated against our default-catchall rule rather than this one as they should be.

4604e4175efa41198cd17178be97d310_RackMultipart20161029-106401-1ois76e-location-group_inline.png


Ronald_Dvorak
Honored Contributor
Hi Scott,

you'd check why a rule doesn't hit.

Right click on the client and select "configuration evaluation tool" and then in the next window click on "run evalution" - click on the rule for details - could you please post the output so we'd take a look.

-Ron

aaee142360a5471abe515a530b8c29de_RackMultipart20161028-82889-ib6b8l-NAC_evaluation_inline.png



aaee142360a5471abe515a530b8c29de_RackMultipart20161028-116141-6w7vlu-NAC_evaluation_detail_inline.png



Sorry I've missed the info that the rule fails because of the location group so just ignore the above post.
GTM-P2G8KFN