ISE as a radius proxy

[rcullum]

Are there any advantages/disadvantages to using the ISE as a radius proxy? Customer already has ACS and that is staying in place. Will this have any impact on ISE ability to profile using radius? I'm thinking of the statement in the ISE profiling Design Guide for ISE which states:

Note: The RADIUS probe does not listen directly to RADIUS traffic, but rather listens and parses RADIUS

attributes sent in syslog to the Monitoring node on default UDP port 20514. Captured RADIUS profile attributes are

then forwarded to an internal logger on default UDP port 30514.

So if my ISE is just proxying radius packets, does ISE still log  these radius attributes? Would it still be of benefit of joining the ISE to an AD domain for profiling even though ISE would not be authenticating directly to AD if it was radius proxying?

[Jason Kunst]

You should only use ISE a radius proxy if needed for a specific use case

Accounts in old systems not migrated (example guest accounts)

I don’t see benefits of adding AD to ISE if you’re not directly integrating

The design you’re talking about seems backward, you should be getting rid of acs because it’s going away

[Craig Hyps · Accepted solution]

As Jason noted, I would plan on migrating ACS to ISE to consolidate and simplify services and for ongoing support reasons.

That said, there are different ways to implement proxy and ISE has advanced capabilities to process the packets instead of simple relay.  When processing the packets as a proxy (when allowing RADIUS to responses to be processed by local Authorization policy), it should allow profiling to work including CoA functions.

Craig