For convenience, I am echoing an explanation of how to set granular group permissions where one can limit the commands allowed for a particular user group based on the NAS group they are trying to access. This explanation is from the author of the tacacs+ originally posted here.
Depending on what you are trying to accomplish, the engine was designed to be flexible. This is one thing that I regret doing. There were so many requests to features that I did them all just to make sure everyone was happy. The 2 ways of grouping devices - NAS group and subnetting. I prefer subnetting (since I am creator of the feature). I am being bias here but, subnetting is the better feature. NAS group allows you to group NAS or subnets but it does not allow you to do what is called a roll-up policy. Roll-up policy is where you can create supernets that has an overall policy for those devices, and you just apply the change in the policy for subnet that you want more limiting.
Here is how it works, and this is only applicable if you use loopback addresses. I have 2 sets of devices: Engineering and Research. I assigned Engineering devices to 172.16.0.0/24 and Research to 172.16.1.0/24. I have 4 sets of users: helpdesk, administrators, engineers and researchers. I need the everyone to have first level or read-only access to all devices. I would create 172.16.0.0/16 supernet allow everyone to have read-only. I need administrators to have read-write access to Engineering device but, no read-write to Research devices. I would create 172.16.0.0/24 and give administrators read-write access. I need the researchers to have read-write access to Research devices but, no read-write to Engineering devices. I would create 172.16.1.0/24 and give researchers read-write access. I need the engineers to have read-write access to all devices. I would add a policy to 172.16.0.0/16 supernet that states that all engineers have read-write. Make sure engineers' policy is the first one in the list.
You can using this same principle using priv-lvl, commands, etc. The engine will match highest bit mask then roll-up to the next bit mask then to the next. I have done up to 6 subnet levels. The engine don't care how many levels. It's up to you to keep track of what is allowed in each subnet and supernet.
The profile feature (another feature I create) was created to give more granularity if you have certain users or groups that require certain priv-lvl, command on some devices and not on others. If you put in the user profile or group profile, everything in the profile is applied to every device in the system that user have access to. I dreamed up this feature will working on maintenance where I could block users from access a device while I am doing maintenance or allow users since their roll was changing to another set of devices. Profile has the high precedence thus, if assigned to a device and user, the user configuration is ignored during the authorization process. Only the profile configuration is used.
I hope this helps. I will changing a lot of features to make them more intuitive; however, I will always keep them backwards compatible if you decided to use them.
Andrew