cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

519
Views
0
Helpful
2
Replies
Highlighted

ACS 5.8 - Machine Auth. prior User Auth.

Hi All,
i'm studying Cisco ACS 5.8 documentation.
The concept of "ACCESS SERVICES" is quite new for me (ACS 5.x it is very different from ACS 4.x), and there is a thing that i would like to ask you:
is there a way to manage in differents ways, with differents policies, users that are authenticate from a Domain Machine and users that are authenticate from a "Personal" Machine?
What I mean is that in this scenario a user can manually configure his Wireless Card to send domain credentials: i don't want to block it, but i want to apply for example a specific ACL on the WLC..
Can ACS "Read" both Machine and User or have I to use a combination of Certificate and PEAP?

Thanks in advance,
N

2 REPLIES 2
Highlighted

Hi Nicola,

As you found ACS5 is very different as compared to ACS4. ACS5 is purely based on rules that means for any specific authentication or authorization it needs to have a rule.

Rules- Set of one or more conditions, example

= User should be member of admin group,

= Request should be from device group Routers,

Result = If conditions in the Rules are satisfied it will permit access.

Check out this video to know about acs5 working

https://supportforums.cisco.com/video/12576221/understanding-acs-5x-functions-and-rule-flow

Regards,

~JG

Do rate helpful posts

Highlighted
Rising star

Hi Nicola,

ACS 5.x works in a waterfall fashion. First the shell profiles and command sets, then you should the authentication protocols, then the user database, then how you map the users to their authorization rules. Let's say you want users to authenticate in two ways: Auth A and Auth B.

1) If you plan on using user groups, make sure to create identity user groups which will be mapped to your external databases. For example group Local_Admins will be matched to Domain_Admins by LDAP.

2) Create the shell profiles and command sets. Shell profiles is for mapping attributes to Radius and Tacacs replies, command sets are for TACACS+ and allow you to configure exactly which commands that user can perform. If you don't need TACACS+ you can skip the command set. An example of a shell profile is to allow change idle-time and set privilege level to 15.

3) Make access profiles, for example one which allows Auth A and one which allows Auth B. You'd match these by tacacs or radius. You can decide here if you want to authenticate by Identity (user database), Group mapping and apply authorization rules. You can select any of these three. If you use local users then you won't need to use group mapping. Each of these can consist of complex rules or a single rule.

4) Under Identity you will match the source of your user database to the access profile. For example, for access profile A users from database A will be authenticated by Auth A. Databases can include internal databases, LDAP, AD etc.

5) We now know where to find the users who will be authenticated by Auth A for radius/tacacs. Now we need to use group mapping so that we can connect the external database to our identity groups from an earlier step. This can be one-to-one mapping, or many-to-one mapping. This means I can map multiple external groups to a single Identity group.

6) Authorization. For the mapped identity group which will be authenticated by Auth A from user database A we will apply a shell profile and command set according to certain criteria. For example let's say that our NAS is a router at home, then we can customize the authorization so that if the network device group is that of Home_Routers then apply a certain shell profile, you can skip command set if you don't need it in any of your authorization rules for a specific access profile (for example RADIUS).

All in all I don't feel this was more complicated than ACS 4.x since ACS 4.x sometimes caused a mess of configurations when users in the same group needed to authenticate via different methods and with different attributes. ACS 5.x makes things more clear cut and readable.

Hope this helped.

Content for Community-Ad