Bedrockno daylight

User & Identity Management

Nikita Tarikin runs the MikroTik RouterOS identity and access stack — the HotSpot captive portal, RADIUS authentication, authorization and accounting (AAA), and the User Manager RADIUS server — in production across every leaf of the official curriculum, with no gap between what is known and what is run: the subscriber-identity engine a virtual ISP runs on, verified by the MikroTik Certified User Management Engineer exam (MTCUME).

Every leaf studied and deployed to the same depth — none left on the study side of the line.

5.0
Knowledge K̄: 5.0
Deployment Ē: 18
leaves mapped: 0
know ≠ run splits

Verified by MTCUME 94%

The map

Every user-and-identity leaf in the official MikroTik curriculum, placed by what is known against what is run in production. The marks do not scatter: they gather into a single stack in the upper-right mastery corner, on the no-daylight diagonal, because every HotSpot and RADIUS leaf is studied and deployed to the same teaching depth. Nothing falls below the diagonal — every leaf here is carrying subscriber sessions in production.

Read left-to-right as knowledge, bottom-to-top as deployment. The one dense mark in the upper-right corner is the whole domain stacked at a single point — the captive portal and its login methods, the walled garden, the RADIUS client and the User Manager server — and the figure beside it counts them. No drop-lines is the signal itself: a stack with nothing studied-but-unbuilt has no daylight to draw.

The topography

The full leaf-level ledger, grouped by topic — the HotSpot captive portal and its login methods, the walled garden and rate-limiting, and the RADIUS layer beneath them: client-and-server setup, the User Manager server, router management over RADIUS, the user profiles, and live session control through Change of Authorization. Each row carries its two verdicts — what is known and what is deployed — and the field note that earned them, quoted verbatim from the assessment.

Leaf	Knowledge	Deployment	Field note
HotSpot		K̄ 5.0 · Ē 5.0 · 13 leaves
HotSpot Setup	5Teach	5Teach	Captive portal dst-nats unauth HTTP to the local login servlet.
HTTP CHAP / PAP	5Teach	5Teach	HTTP-CHAP client-side MD5 challenge-response protects the password over plain HTTP (vs HTTPS-needs-cert, PAP=cleartext-equiv); walled-garden (host pre-auth) vs IP-binding (client bypass)
MAC Login	5Teach	5Teach	Device w/o portal: IP-binding bypassed or mac-auth by MAC.
Cookie Login	5Teach	5Teach	Cookie = auto re-login on reconnect within lifetime.
HTTPS Login	5Teach	5Teach	Can't MITM TLS to redirect HTTPS; OS captive-portal probes trigger login.
Trial Login	5Teach	5Teach	Trial quota tracked by client MAC (uptime-limit/reset); MAC-spoof bypassable.
RADIUS Login	5Teach	5Teach	Per-user limit from RADIUS Mikrotik-Rate-Limit VSA in Access-Accept.
User Management	5Teach	5Teach	Profile = reusable policy; user = the credential bound to it.
Host & Active Tables	5Teach	5Teach	host = all detected devices; active = authenticated sessions.
SNMP	5Teach	5Teach	SNMP v3 auth+priv; avoid v1/v2c cleartext community.
HotSpot Rate-Limiting	5Teach	5Teach	RADIUS Mikrotik-Rate-Limit overrides local user-profile. v1 'never formalized precedence' now solid.
Walled Garden	5Teach	5Teach	Pre-auth allow of a host (payment gateway) via walled-garden.
HotSpot Customization	5Teach	5Teach	Login page = HTML files in the router's hotspot directory.
RADIUS		K̄ 5.0 · Ē 5.0 · 5 leaves
RADIUS Client/Server Setup	5Teach	5Teach	Access-reject-all = shared-secret mismatch / NAS not registered.
User Manager	5Teach	5Teach	limitation (rate/quota) <- profile (plan: price + validity) <- user-profile (assignment) <- user; rate delivered as the Mikrotik-Rate-Limit VSA; runs UM v7 in production
Router Management via RADIUS	5Teach	5Teach	/user aaa RADIUS login MUST keep a local-admin fallback vs lockout.
User Profiles	5Teach	5Teach	Interim-Update accounting reports Acct-Input/Output-Octets -> server tracks the running total vs the limitation transfer quota -> CoA (throttle) or Disconnect (cut) on exceed
RADIUS Incoming / CoA	5Teach	5Teach	live plan-upgrade via CoA carrying a new Mikrotik-Rate-Limit; needs /radius incoming accept=yes on the CoA port (3799); no reconnect

The edges

The edges of this domain are not internal — no leaf here is studied ahead of where it runs. They are the plane this stack reaches into: the tunnel and PPP layer whose subscriber sessions authenticate against this same RADIUS, where the virtual-ISP delivery actually rides.

Every leaf sits on the no-daylight diagonal — known and deployed to the same depth.

The warrant

Third-party confirmation of the identity-stack depth above — in support of the deployment record, never in place of it.

MTCUMEVerified — 94%, User Management Engineer

Identity is where the network learns who a session belongs to. Where this stack connects:

The questions

What user-management and identity work is genuinely production-proven?

All of it — the HotSpot captive portal, the RADIUS authentication-authorization-accounting (AAA) layer, and the User Manager server are deployed end to end as the delivery core of a virtual ISP, graded known and run at the same teaching depth, verified by MTCUME (MikroTik Certified User Management Engineer). The public mechanics: User Manager is RouterOS’s own RADIUS server — a centralized user database for authentication and authorization — shipped as a separate .npk package (present on every architecture except SMIPS) and built to the RADIUS standards in RFC 2865 and RFC 3579, with PAP, CHAP, MS-CHAPv2 and the EAP family for credentials. MikroTik’s own documentation names the features that lean on it most — DHCP, Dot1x, HotSpot, IPsec, PPP and Wireless — which is exactly the AAA spine a vISP delivers subscribers through. One version note worth naming: the RouterOS 7 User Manager (officially “version 5”) is a ground-up rewrite of the RouterOS 6 implementation, configured in WinBox and console rather than the old web admin, and an old database does not carry over automatically — it is migrated explicitly with /user-manager/database/migrate-legacy-db.

How does a MikroTik HotSpot captive portal actually authenticate a user?

This is daily, deployed ground — the public-access front door of the stack. The mechanism, publicly: the HotSpot transparently rewrites any client’s IP to a valid address and intercepts the first unauthenticated HTTP request, redirecting it to the local login servlet. It supports several login-by methods — http-chap, http-pap, https, mac, cookie, mac-cookie and trial — defaulting to http-chap plus cookie: http-chap protects the password over plain HTTP with a CHAP MD5 challenge-response rather than sending it in clear, mac authenticates a device silently by its MAC address, and the cookie auto-relogs a returning client until its lifetime expires. The walled garden pre-authorizes specific hosts — a payment gateway, say — so an unauthenticated client can still reach them. And per RFC 7710, when the router has a DNS name and a valid TLS certificate it advertises the captive-portal API to DHCP clients, so a modern phone or laptop pops the login page automatically instead of silently failing.

Can you build a RADIUS-driven subscriber plan — rate limits, quotas, and live changes?

Yes — this is the billing-adjacent core a vISP runs on, deployed and graded at teaching depth. The public mechanics: the RouterOS RADIUS client is configured under /radius with a shared secret (HMAC-MD5 message signing), authentication on UDP 1812 and accounting on 1813. A subscriber’s bandwidth is carried by the Mikrotik-Rate-Limit vendor attribute (format rx-rate/tx-rate — and from the router’s point of view rx is the client’s upload, tx the download), and the attributes the server returns override whatever a local profile would have set, falling back to the profile only for values it does not send. Quota and usage track through accounting interim-updates carrying the running byte counters. The part that makes it feel live: RouterOS implements RFC 5176 Change of Authorization — turn it on with /radius incoming set accept=yes port=3799 and the server can push a new Mikrotik-Rate-Limit to re-rate an active session with no reconnect, or send a Disconnect-Message to cut it. That is how a plan upgrade lands on a connected customer mid-session.

Does this same stack authenticate PPPoE and VPN subscribers, not just HotSpot users?

Yes — and that is the honest shape of this page. The leaves graded here are HotSpot and RADIUS, but the RADIUS layer is the identity backbone the rest of the access stack authenticates against. MikroTik’s own RADIUS client lists PPP, PPPoE, PPTP and L2TP among the services it serves: set /ppp aaa set use-radius=yes and a subscriber missing from the local secret database is authenticated against RADIUS instead, with the returned attributes — address, rate-limit, filter — overriding the default PPP profile. So a PPPoE customer logging into a virtual ISP and a HotSpot guest at a café authenticate through the same User Manager. The tunnel and PPP transport that carries those sessions is its own deployed domain — see the VPN and tunnelling page — while the identity behind them is the stack on this one.

Bring the access-and-identity problem.

If it is a HotSpot captive portal, a RADIUS-backed subscriber plan with rate limits and live changes, or a User Manager server on RouterOS, that is ground I run every day — the delivery core of a virtual ISP — and I will tell you where it connects to the tunnels that carry it.

Start the conversation