aaa authentication login default group radius local
aaa authorization exec default group radius
My ACS user account is a member of an unmodified group on the ACS server. I have not set a privilege level in the Cisco-AV pair nor have I set the Service Type. The user is able to log in but does not go directly to privilege exec. The enable secret must still be supplied.
I successfully capture the RADIUS Access Request and Accept messages on the ACS server. If I configure the priv level and frame type on ACS, they are returned in the Accept message.
If I don't configure the priv level or the frames protocol shouldn't authorization fail? I don't see why the exec session is being granted if it is not specified in ACS.
If you're trying to set authorization for each type or level of command - that is called "remote command authorization" and is done through TACACS+. RADIUS command authorization is not supported; this is a limitation of the RADIUS protocol.
I appreciate the benefits of using TACACS+ for admin control and recognize that it is preferable. I am just trying to develop a better idea of what to expect when RADIUS is used (not that it should be).
ACS returns the priv-lvl value in the RADIUS accept message independant of the configuration of exec authorization on the router. It makes sense that the router ignorers it when authorization is not configured. A user authenticated by ACS without authorization is initially granted level 1 privelege. After enabling authorization on the router and configuring ACS to return level 7 for a specific group I see that the user, immediately upon authentication, is authorized and given level 7 privilege.
What bugs me is that RADIUS appears to allow ANY ACS authenticated user to have level 1 access to the router. The absence of a privilege level in ACS when authorization is enabled on the router is ignored. If that is the case how, when using radius for authentication AND authorization, do I prevent "sally" in accounting from getting into user exec on my router?
I understand I little better now what you're saying.
In RADIUS, the authentication and authorization are always "together" and occur at the same time. If the username is found and the password is correct, the RADIUS server returns an Access-Accept response, including a list of Attribute-Value pairs that describe the parameters to be used for this session. Typical parameters include service type, protocol type, ip address assignment, access lists, or static routes to name a few. Also, as you mentioned, it can assign a priv-lvl value for the user's session.
So you are right -- "ACS returns the priv-lvl value in the RADIUS accept message independant of the configuration of exec authorization on the router."
My guess is that if you don't have a specific value set for that attribute on the ACS server, it will return a default value - maybe 1 in this case. When that happens, the user should have that privelege level.
The typical solution is to create user groups in the ACS server. One group you configure with the priv-lvl=15 and the other group will have priv-lvl=1. Then put the users in the different groups based on what privelege levels you want them to have.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...