Centralized AAA on RouterOS 7: RADIUS for Logins, VPN and User Manager

Local router accounts don’t scale past about three routers or two admins. Someone leaves the team and their account survives on the boxes nobody remembered; passwords drift between devices; and when the auditor asks “who logged into the edge router on March 3rd,” the answer is a shrug. Centralized AAA — authentication, authorization, accounting — fixes all three, and RouterOS speaks the lingua franca: RADIUS, as both client and (with the User Manager package) server.

The one rule that outranks everything else in this article: central auth must never be able to lock you out. Every RADIUS deployment keeps a local emergency account, tested, documented, in the password vault. The day the RADIUS server is down is the day you need to log into routers.

Router Login via RADIUS

Point the router at your RADIUS server and tell the login system to use it:

# The RADIUS client entry — service=login covers ssh/winbox/web/api auth
/radius add service=login address=10.99.0.10 secret=RADIUS_SHARED_SECRET \
  timeout=800ms comment="FreeRADIUS primary"
# Second server = redundancy; RouterOS tries them in order
/radius add service=login address=10.99.0.11 secret=RADIUS_SHARED_SECRET timeout=800ms

# Enable RADIUS for logins
/user aaa set use-radius=yes default-group=read

default-group=read is the authorization half: a RADIUS-authenticated user lands in the read group unless the RADIUS server says otherwise. The server can assign the group per-user with the vendor-specific attribute — MikroTik’s VSA Mikrotik-Group (vendor ID 14988) set to full, write, or read. That’s where the real win lives: admins get full, NOC gets read, and the mapping lives in one place (your RADIUS server backed by LDAP/AD) instead of on thirty routers.

On the FreeRADIUS side, the minimal user entry looks like:

# /etc/freeradius/3.0/users (concept — adjust to your setup)
alice  Cleartext-Password := "..."
       Mikrotik-Group = full

with the MikroTik dictionary (shipped with FreeRADIUS as dictionary.mikrotik) providing the VSA definitions.

The fallback account. use-radius=yes still checks local users when RADIUS doesn’t answer — but verify the semantics on your version rather than assume, and regardless: keep one local emergency user in group full with a vault-stored password, and test it by firewalling the RADIUS server for a minute and logging in. Also note /user aaa has exclude-groups and interim settings worth reading once — and that the RADIUS secret plus an on-path attacker equals authentication bypass, so RADIUS traffic belongs on the management VLAN/VRF (management-plane article, next in the series), never crossing untrusted segments unencrypted.

Accounting for logins comes with the same service=login entry — your RADIUS server’s accounting log becomes the answer to “who was on that router and when,” which is precisely what the logging article said the router alone can’t durably provide.

RADIUS for VPN and PPP

The second, bigger use case: user authentication for VPN services. Every PPP-family service (L2TP, SSTP, PPPoE, PPtP if you still haven’t killed it) can delegate auth:

/radius add service=ppp address=10.99.0.10 secret=RADIUS_SHARED_SECRET
/ppp aaa set use-radius=yes accounting=yes interim-update=5m

Now L2TP/IPsec road-warrior users (the IPsec article’s setup) authenticate against your central directory. RADIUS replies can push per-user attributes — Framed-IP-Address for fixed VPN IPs, rate limits via Mikrotik-Rate-Limit, address-list membership via Mikrotik-Address-List — which turns “VPN with per-user firewall policy” from a config sprawl into RADIUS attributes. interim-update gives you session-duration and traffic accounting good enough for usage reports.

The same /radius mechanism serves hotspot, wireless (802.1X/WPA-Enterprise on the WiFi article’s setups), dhcp, and more — one AAA backbone, many consumers. Add entries per service so secrets and servers can differ.

User Manager: RouterOS as the RADIUS Server

Sometimes there’s no FreeRADIUS and no appetite for one — a small ISP, a hotspot site, a lab. RouterOS 7’s User Manager package turns the router itself (or better, a dedicated CHR) into the RADIUS server. It’s a separate package: download the extra-packages bundle for your architecture from mikrotik.com, upload the user-manager package, reboot.

# On the User Manager box
/user-manager set enabled=yes
# Each router/NAS that will authenticate against it:
/user-manager router add name=gw-office address=10.10.0.1 shared-secret=RADIUS_SHARED_SECRET

# Profiles define what users get
/user-manager profile add name=vpn-standard name-for-users="Standard VPN"
# Attributes attach RADIUS reply values (name = dictionary attribute)
/user-manager attribute add name=Mikrotik-Rate-Limit packet-types=access-accept \
  value="10M/10M"

# Users
/user-manager user add name=alice password=STRONG_PASS group=default
/user-manager user-profile add user=alice profile=vpn-standard

Then the consuming routers point their /radius entries at the User Manager box exactly as they would at FreeRADIUS. User Manager v7 was rewritten from the v6 web-centric tool into a proper console-first subsystem — it supports users, profiles with validity/limits (useful for hotspot vouchers and time-limited access), attributes, accounting, and CRL-less EAP for wireless in recent versions.

An honest scoping: User Manager is excellent at “hundreds of VPN/hotspot users managed by one team.” It is not an identity platform — no LDAP/AD sync, limited policy logic, and its database lives on the router (back it up! /user-manager database save exists for that). When the user base or compliance needs outgrow it, FreeRADIUS in a container or VM with a real directory behind it is the graduation path — the consuming routers don’t change at all, only the /radius target does.

TOTP and Stronger Auth

Password-only admin access in 2026 needs a second factor somewhere in the chain. Practical options, in order of realism: enforce SSH keys for CLI (/user ssh-keys — the management-plane article’s approach) and keep passwords only for WinBox on the management VLAN; put RADIUS behind a server that does OTP (FreeRADIUS + TOTP module, or privacyIDEA) so interactive logins prompt for password+OTP concatenated; or front management access entirely with WireGuard (something you have: the key) and treat the password as the second factor. RouterOS itself doesn’t do native TOTP for logins — design the factor into the layer in front of it.

Verification

/radius print                       # servers, services, and 'pending' counters
/radius monitor 0                   # live request/timeout stats per server
/log print where topics~"radius"    # rejects and timeouts show here
/user active print                  # who is on the box right now, via what
# And the drill that matters:
# block RADIUS at the firewall for 60s -> confirm emergency local login works

On the User Manager side, /user-manager session print shows accounting sessions; a VPN login that authenticates but shows no session means accounting isn’t reaching the server — check accounting=yes and secrets.

Closing Thoughts

AAA is one of those investments that looks like bureaucracy until the first offboarding, the first audit, or the first shared-password leak — then it looks like the cheapest insurance you ever configured. The shape that works: RADIUS for everything (logins with group VSAs, VPN/PPP with per-user attributes, accounting on), served by User Manager while you’re small and FreeRADIUS-with-a-directory when you’re not, always on the management network, and always — always — with a tested local emergency account per box. Central control with a local escape hatch: the same principle as every HA design in this series, applied to trust itself.