04-26-2010 05:16 AM - edited 03-10-2019 05:05 PM
Hi!
I have set up 2 rules in Access Policies -> Access Services -> Service Selection Rules.
The first rule (Rule-SwitchAdministrasjon) is to give users in a certain AD group access to administer switches.
This rule points to a policy called Policy-SwitchAdministrasjon where it says that the only allowed protocol is PAP/ASCII.
The next rule (Rule-SwitchAccess) points to a policy called Policy-SwitchAccess, and the purpose of this rule is to give users 802.1x access on switch ports.
But when I use a computer and connect it to a switchport, ACS gives me the following error:
"EAP-negotiation failed because the Allowed Protocols section of the Access Service has no EAP-based protocols enabled."
And the Access Service it hits/stops at is Policy-SwitchAdministrasjon.
It does not seem to jump to the next rule (Rule-SwitchAccess) at all.
(Please) correct me if I'm wrong, but isn't the whole point that it should jump to the next rule if the first one fails?
The rules themselves work; if I put the Rule-SwitchAccess on top, I'm able to get switchport access, but then I cannot log in to (administer) my switches any more.
Any pointers?
Thanks.
04-26-2010 07:07 AM
Dal,
The reason it is not checking the second rule is because the first rules matches the incoming request. It will only check rule 2 if incoming request attributes does not match with rule 1.
Best way here is to segregate incoming traffic on the basis of Protocol.
Rule 1---> Match protocol-->Radius
Rule 2--->Match protocol -->Tacacs+
That should take care of this issue.
Regards,
~JG
Do rate helpful posts
04-26-2010 07:46 AM
Hi, thanks for answering.
But I don't see how this can solve the problem.
I don't use TACACS, and besides, what if I had more than 2 rules?
Is protocol the only way to segregate traffic?
Isn't it possible to move to the next rule based on what the outcome in the Policy is?
For example if the user is not in the desired AD group, it moves on to the next Rule/Policy?
Thanks.
04-27-2010 12:27 PM
I found out there was other ways to segregate traffic, by selecting the Customize button.
But I still can't make it work, I cannot get the traffic to match my rule.
I am using a Compound Condition, and it looks like this:
RADIUS-IETF:Service-Type match Login Or RADIUS-IETF:Service-Type match Administrative (taken directly from a slide presented in Barcelona in january.
But it's not kicking in.
Is there a way to segregate on what traffic hits the switch? Like telnet, ssh, http? Than we could use that to make switch administration rules.
One other thing:
I have noticed a difference in the amount of Compound conditions based on where I use it:
Under Service Selection Rules -> Create -> Compund Condition -> System -> Attribute, there are very few attributes.
But under Access Policies ->
the list is much longer.
Why? Bug? I really hope so.
For example the condition System -> AuthenticationMethod could have fixed my problem if it was available directly under Service Selection Rules.
Where do I report bugs / suggestions, btw?
Thanks.
04-28-2010 03:38 AM
Two comments / suggestions:
1) If can't see why rule is not matched it is good to look at the details for the request. Go to:
04-28-2010 06:04 AM
Hi, thanks for answering.
Not easy to see WHY it fails, or why that rule is never hit.
It should be listed somehow why a rule is not hit.
But what I can see from login attempts that has succeded, it says under Authentication Result: Service-Type=Login
So why the rule does not hit when I enter the exact same thing as a condition (Compound Condition: RADIUS-IETF:Service-Type match Login), is beyond me.
I know one thing, it creates a lot of frustration.
About the policy processing, is there a place I can see what a switch requests (what info it sends to the ACS), and in what order?
Is there a document describing this?
Thank you.
04-28-2010 08:13 AM
To see the RADIUS attributes sent go to the authentication details as I mentioned in last post and select the Authentication Details section. Under "Other Attributes:" section can see the list of RADIUS attributes that were received
04-29-2010 12:46 AM
I'm not sure I understand, the info listed under Other Attributes seems to be info sent FROM the ACS, not recieved.
About the problem I've encountered; could it be a bug?
If so, how do I report it and get i verified?
Thanks.
04-29-2010 05:33 AM
I have done some sniffing to find out what info the switch (10.50.55.40) really sends to the ACS.
I cannot see a attribute called Service-Type at all, only the ones seen in the picture below:
What can cause this? Is it something that needs to be turned on in the switch?
I have done the audit thing under Advanced troubleshooting, and all options regarding Radius seems to be turned on.
The switch runs this software: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(52)SE, RELEASE SOFTWARE (fc3)
Thanks.
04-29-2010 05:44 AM
Just found the answer:
It was something that had to be enabled in the switch!
I added this line: radius-server attribute 6 on-for-login-auth
and now it works!
And a new sniffer session also confirms that this info is being sent out from the switch now.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: