-
Notifications
You must be signed in to change notification settings - Fork 34
tac_plus‐ng: RADIUS support
Marc Huber edited this page Oct 7, 2025
·
3 revisions
RADIUS PAP/CHAP/MSCHAPv1/MSCHAPv2 authentication support is implemented for various RADIUS transports (TCP, UDP, TLS, DTLS). This should be sufficient to grant administrative access to users on devices supporting RADIUS but not TACACS+.
See
for sample configurations.
Summary for legacy RADIUS:
- Add
listen { port = 1812 protocol = UDP }(and eventually a similar statement with1813, but sending accounting packets to 1812 works, too) to thespawndsection. Then, in thetac_plus-ngsection: - Import a RADIUS dictionary. This is custom-made, any existing ones won't match. Have a look at radius-dict.cfg for syntax, and extend it if needed.
- Change configuration scripts to handle RADIUS. E.g., you can check with
if (aaa.protocol == tacacs)for TACACS+, and, likewise,if (aaa.protocol == radius)is a suitable condition for RADIUS. RADIUS attributes can be queried viaradius[attribute]syntax, e.g.if (radius[Service-Type] == Administrative-User), and you can set response attributes usingset radius[attribute] = value, e.g.:set radius[cisco:Cisco-AVPair] = "shell:priv-lvl=15". - By default. the daemon accepts
tacacs,tacacss,radiusandradsecas supported protocols. You can limit this on a per-realm basis. Example:aaa.procotol.allowed = tacacss,radsec. Also, in script conditions comparingaaa.procotolto the pre-defined values works as expected, so you can clearly separate the protocol parts. Example:if (aaa.protocol == tacacs || aaa.protocol == tacacss) { ... }. -
tactrace.plnow supports RADIUS, too. Use the--radiusoption to trace RADIUS processing.
Please note that all of this is still work in progress.