You're welcome. Do you mean admin accesses via RADIUS or TACACS? if you are referring to RADIUS then please note that in my blog post I shared above it shows privilege 15 by default when you select "Web Authentication (Local Web Auth)" from the authorization profile common tasks. However, if you want to assign a different privilege level for a specific set of users, then you can create a new authorization profile with a custom RADIUS attribute "cisco-av-pair = priv-lvl=< the privilege level you want >", and then you create a new authorization rule point to the interested AD group and finally you associate the new authorization profile you created.
However, if you are referring to TACACS then TACACS policies won't interfere with RADIUS policies because TACACS aaa configs on the network devices will be different even if you use the same ISE PSNs as both RADIUS and TACACS servers.
RADIUS and TACACS accesses to the network devices themselves are terminated on the network devices VTY lines. So in both cases if you use a different aaa method list than the default you would need to define the new method list as shown in my post config snippet. However, these accesses are the accesses to the network devices themselves, not to the network (LAN).
Generally speaking RADIUS is used to allow the end users accesses to the network, not to the network devices themselves, and TACACS is used to allow accesses to the network devices themselves. Although technically speaking you could use TACACS to allow network accesses, RADIUS has been known as a standard protocol for the users network accesses because it is much more flexible in terms of defining vendor custom attributes.
The main differences between RADIUS and TACACS is that RADIUS encrypts only the password in a packet, TACACS on the other side encrypts the whole payload. Also, TACACS separate the authentication and authorization which means you can decide which single commands each user is allowed/denied to run on a network devices. RADIUS on the other hand consolidates authentication and authorization together.
Also, when you turn on dot1x in your environment and you are still not a 100% sure if all your endpoints are ready for this enforcement, then what you can do is starting with monitor mode which basically has no enforcement at all, but will allow you to have visibility of what's going on on your network and adjust the endpoints NIC settings, ISE policies etc. Once you are happy with everything you can swich to close mode where the enforcement will start.
Another common approach to deal with this would be to specific a set of test users and add them to a test AD group, and then you create the rules on ISE to only affect those users leaving the default actions on ISE to allow both authentication and authorization when they fail.
