In order to dump a user into a specific privilege level, you need to authorize the EXEC session. The command would be aaa authorization exec default group radius local. However, I don't think that what you are trying to do specifically is possible with a simple straightforward AAA setup. The way the AAA method list works is that the device will try the first method such as radius and if there is no response from radius, then it falls back to the next method of local. Local only comes into play if the radius server does not respond at all. Chances are it will respond with a reject for the local account since the radius server doesn't know the local account. Even if you could switch the order to local first, local will always be available so the device would never use radius. And since the radius user does not exist in the local database, you get % Authorization failed %.
You could get fancy and use the "rotary" command and Telnet on a specific VTY line such as vty 15. "rotary 5" would allow you to Telnet to the device on port "3005". And then you assign a specific AAA method list to this VTY line only that only checks the local database. Rotary only works with Telnet. Which leads me to overall security and your approach.
Telnet is obviously not a good idea. The benefit of using AAA with an external server is that you increase security and ease of management by centralizing your policy on an authentication server. And if a bad person keeps attempting to access your device, all of those attempts are logged on the server, away from the device. If the bad person were successful after hundreds of attempts, they could just erase that information on the device and do whatever bad stuff they want such as locking you out of the device. And if it were local authentication, it would be hard to know what really happened and why you can't get into your device anymore. Assuming that the device is not sending syslog messages to an external server.
The solution that most organizations use is to configure an account on the Radius server that is local to the Radius server and not in AD or some other external identity source. That allows you to connect if the Radius server is unable to reach AD. If the Radius server goes down, then you have a local account on the device that you can use. Since Radius is down, the local device account works. Then you can obviously configure your console port to only use local or no authentication at all as a last resort. But you would want to ensure that the device is physically secure where only certain people have physical access to the device.
HTH,
Colby
