point Cisco ASA at ISE for RADIUS with CoA support

why bother pointing your asa at ise instead of local auth

local user accounts on an asa work until they don't. no centralized logging, no easy way to kill a session the second someone gets fired, no group policy magic based on ad attributes. ise fixes that, and radius with change of authorization (coa) means ise can reach back into an active vpn session and say "kill this" or "reassign this" without waiting for the tunnel to drop and reconnect. if you're running remote access vpn on an asa and still doing local auth, this is the upgrade that actually matters for defenders.

the aaa-server group, this is where ise gets defined

aaa-server ISE-GROUP protocol radius
aaa-server ISE-GROUP dynamic-authorization

the first line creates a named group and tells the asa "when i talk to this group, use radius." the second line is the one people skip and then wonder why coa doesn't work. dynamic-authorization opens a listener on the asa for coa packets coming from ise, usually udp 1700. without it, ise can authenticate the user fine but has zero ability to change anything mid-session. if you want ise to be able to disconnect a compromised session the moment your soc flags it, this line is non-negotiable.

adding the actual ise host with a shared secret

aaa-server ISE-GROUP (inside) host 10.10.10.50
 key YourSharedSecretHere
 authentication-port 1645
 accounting-port 1646

a few things to sanity check here as a defender, not just a config-paster:

the (inside) part matters. that's the interface the asa uses to reach ise. if your ise box lives on a different segment, this needs to match reality or auth will silently fail and you'll be staring at logs wondering why.

the key is a shared secret between the asa and ise, it has to match exactly on both sides. treat this like a password, not like a config comment. don't reuse it across every device in your network, and don't leave it sitting in a plaintext backup file on a shared drive.

ports 1645/1646 are the old-school radius auth/accounting ports. some environments use 1812/1813 instead. mismatch here is one of the most common "why isn't this working" moments, so check what ise is actually listening on before you assume the asa config is wrong.

binding the group to your tunnel-group

tunnel-group YourRemoteAccessTG general-attributes
 authentication-server-group ISE-GROUP

this is the step that actually puts ise in the authentication path for your vpn users. everything above was just building the tool, this line is what wires it into production. do this on a test tunnel-group first if you can, or at minimum during a maintenance window, because a typo here locks out every remote user at once.

testing before you touch a real user

test aaa-server authentication ISE-GROUP username testuser password testpass

this is the whole point of the post. the asa will send a real radius auth request to ise using a test credential and tell you pass or fail right in the cli, no vpn client needed, no real user affected. if it fails, you'll get enough detail to know whether it's a reachability issue, a bad shared key, or ise flat out rejecting the credential. run this before you ever bind the group to a live tunnel-group, and run it again after any change to the key, ports, or ise policy. a clean test here means when you do point real traffic at this config, you're not debugging blind during a user's actual outage.

the takeaway

if you're running an asa for remote access, this setup is worth doing even outside of any compliance checkbox. centralized auth through ise means one place to see who's connecting, one place to kill a session fast, and coa support means that "kill it now" isn't a wish, it's a real button someone in your soc can press. audit your own tunnel-groups this week, confirm dynamic-authorization is actually enabled and not just assumed, and run test aaa-server against your own config before trusting it. defending your vpn starts with knowing your own auth path cold.