ACS 5.1 access rule selection sequence

[oldcreek12]

HI, I just installed a new ACS 5.1 to authenticate wireless PEAP users, so I created an Access policy "WirelessUsers" with identity store being Windows Active directory and all domain users are selected, and create a service rule that dictates that if the authentication protocol is radius, network device belongs to WLC device group, the result service will be "WirelessUsers", so this part worked perfectely, all domain users are able to gain wireless access via their DOMAIN/usernames and domain passwords. Now I want ACS local indentity store users (those local usernames can be the same or different from their AD usernames) to be able to manage those controllers, so I created another access policy "DeviceAdminUsers" with identity store being local users, another service rule which says that if the authentication protocol is radius, network device belongs to WLC device group, the result service will be "DeviceAdminUsers". The problem is that with the setup, whenenve when I try to SSH to WLC, ACS always put me in "WirelessUsers" access policy, even the login name does not have DOMAIN pre-pended or the login name simly does not exist in AD.  if I put the second rule in front of first rule, I am able to authenticate with ACS local username/password and gain access to WLC, but wireless users will fail to authenticate, because ACS is trying to put regular wiress users in "DeviceAdminUsers" access policy. I would expect if username does not exist in AD, ACS should proceed with next rule. Similar requirement was easily achieved in ACS 3.3. What did I do wrong? your input is greatly appreciated.

[Nicolas Darchis]

Your expectations are wrong :-)

-What you are looking to achieve requires to create an identity store sequence (in the identity store menu). Create a sequence that checks first AD and then the local identity store.

In your first access policy rule, instead of pointing identity to AD, point it to your sequence.

Voila !

-The rules for access services are meant to be different and in your case they are identical so the 2nd is never evaluated.

Something else you can do (but that is not related to what you want to achieve) is on the "identity" part of your service rule, you have "advanced options". There you can say "if user was not found : continue", or "if authentication failed : continue". But that continues towards the Autohrization service of your rule and not to the next service rule.

Hope it's clarified !

Nicolas

[oldcreek12]

Thanks, Nicolas, I tried the first option already, the problem was that ACS5.1 still tries to match the wireless service rule, not moving to the second rule for device authentication. I did more search on NetPro, one user stated that ACS5.1  can not used for "Network access" and "DeviceAdmin" at the same time, so switched to TACACS+ for device authentication, now ACS5.1 is able to match the correct rule and access service and authenticate network admins in local identity store, but somehow WLC does not like the response ACS sent, complaining "service type 0: unknow service type", althought I set "ruel1=ALL" in shell-profile and set priv level to 15.

[Nicolas Darchis]

Again, you are having a wrong expectation. ACS will not evaluate more than one rule when one matched !!!!!

My trick was that your first rule, instead of authenticating against AD, authenticates against an identity SEQUENCE, so it will try ad and then the internal store.

If you go the tacacs way for admin, it's role1=ALL and not "rule1=ALL".

Nicolas

[oldcreek12]

Sorry I may have missed your point, but ACS has no problem to find the user in local identity store with identity sequence, the problem I want to resolve is I don't want ACS to match the service of the first rule as that rule is for network access not for device administration. Thanks for pointing out my typo, I did have role1=ALL.

[Nicolas Darchis]

If you want to match different rules, they need to have different conditions.

I'm quite sure that the WLC sends a radius attribute different when it's a client authentication and when it's a admin authentication.

You should check out the "Service-type" in a debug aaa or in a sniffer trace. There's always one difference on which you can base your rule condition.