ACS 5.1: Service Selection Rules - Jump to next rule?

Unanswered Question


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?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jagdeep Gambhir Mon, 04/26/2010 - 07:07


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.



Do rate helpful posts

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?


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 -> -> Authorization -> Create -> Compound Condition -> System -> Attribute
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?


jrabinow Wed, 04/28/2010 - 03:38

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:

Monitoring & Reports > Reports > Catalog > AAA Protocol and select RADIUS Authentication
You should see summary of the requests and click on details icon to get more detailed information related to the processing for the request
2) As policy processing continues there are more attributes that become available. For example when service selection is performed this is performed prior to protocol negoication and so at this time the AuthenticationMethod is not yet available for use in conditions. Similarly identity attributes (AD, LDAP, internal etc) are similarly not yet available. They are are later available in authorization policies

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.

jrabinow Wed, 04/28/2010 - 08:13

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

I have done some sniffing to find out what info the switch ( 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)



This Discussion