I mostly use branding packages, so really never get into this state.Active users can be seen, it's up to the admin doing the user cleaning to kill the connections too, or script it.
/user/active/request-logout [find]
action failed (6)
::foreach item in=[/user/active find] do={:if ([/user find name=[/user/active get $item]->"name"]) do={} else={:put "Warning: found a removed user(s) being still be logged in: $[:tostr [/user/active get $item]]"}}
Warning: found a removed user that is still logged in: .id=*3;address=192.192.0.11;group=winbox;name=test;radius=false;via=winbox;when=2023-08-07 12:01:38
:foreach item in=[/user/active find] do={:if ([/user find group=[/user/active get $item]->"group"]) do={} else={:put "Warning: found a logged in user using a wrong group. Ask user to disconnect and reconnect to the services: $[:tostr [/user/active get $item]]"}}
...ah, actually that too, I hadn't considered it...Removing the connection in connection tracking does not work. The removed user can reconnect even while the connection is gone.
no, not at all!Reboot.
Problem solved.
/user/active {:local lsess [print as-value where name~".*"]; :foreach i in=$lsess do={:do {
request-logout ($i->".id")
} on-error={}}}
And, in ideal world, at least prompt if you attempt disable and/or delete a user that has active sessions...Why there isn't a "-" in winbox, IDK...
is this some kind of useless trolling?Play with the tools you have.
Reboot.
Done.
:foreach item in=[/user/active find] do={:if ([/user find name=[/user/active get $item]->"name"]) do={} else={:do {/user/active request-logout $item} on-error={:put "bugger"}}}
bugger
01:12:47 echo: system,error,critical login failure for user test from 192.168.0.11 via local
:foreach item in=[/user/active find] do={:if ([/user find name=[/user/active get $item]->"name" disabled] ) do={:do {/user/active request-logout $item} on-error={:put "bugger"}}}
In all seriousness:is this some kind of useless trolling?
a PROD router is not always elegible for "just a quick reboot"
imagine a BGP router has this issue and needs a reboot ...
# activate reading the .id from global
:global eventPathUser;
# remove previous running event scripts (:execute)
:do { /system script job remove $eventPathUser } on-error={:log error "Script .id not found"}
:global eventPathUser [:execute {
/user print follow-only [:foreach item in=[/user/active find] do={
#disabled user
:if ([/user find name=[/user/active get $item]->"name" disabled] ) do={
:do {/user/active request-logout $item} on-error={}}
# removed user
:if ([/user find name=[/user/active get $item]->"name"]) do={} else={
:do {/user/active request-logout $item} on-error={}}
}; # end foreach
]; # end print
}; # end execute
]; # end eventpath
/system script job remove $eventPathUser
Most of my devices use RADIUS to authenticate users, so they never exist in /users, so.....I wrote a small script that detect logged in users that do not exist in /users:
Not sure. BUT...I'd bet the RADIUS users still show up in /user/active & if you disable them in RADIUS while winbox is still open, they'd have access until winbox was closed.Most of my devices use RADIUS to authenticate users, so they never exist in /users, so.....I wrote a small script that detect logged in users that do not exist in /users:
I guess if your spouse had an account on the router, and you got a divorce. But you fire a network admin more often.Hi msatter would that be useful in a home network or is this strictly business stuff.
they certainly do show up in /users/active, and if you disabled them in RADIUS while logged in the router would never know since the credentials are cached for the duration of the session.Not sure. BUT...I'd bet the RADIUS users still show up in /user/active & if you disable them in RADIUS while winbox is still open, they'd have access until winbox was closed.
Most of my devices use RADIUS to authenticate users, so they never exist in /users, so.....
Well, now you mention it ......I eventually did just reboot the device, not that I consider that a good option).
don't know if upon deletion but you have the option to kill a session proactivelyI've seen this on MikroTik, but what about other vendors?
Plain Debian, or whatever or any big vendor. Do they proactively kill user session upon deletion immediately?