Compromised user account

We occasionally get a request from ITSO to disable a user account and disconnect all associated network sessions. This is the procedure on how to do that for Wi-Fi sessions.

Find active sessions

Log into the mobility conductor (MC, previously called mobility master (MM)) via ssh, and use the show global-user-table command:

(isb-mm-1) [mynode] #show global-user-table list name PID

Global Users
------------
    IP                                  MAC            Name              Current switch  Role   Auth    AP name           Roaming   Essid    Bssid              Phy        Profile      Type  User Type
----------                         ------------       ------             --------------  ----   ----    -------           -------   -----    -----              ---        -------      ----  ---------
2607:b400:24:0:1234:5678:9abc:def  c6:ea:aa:11:22:33  PID@vt.edu         172.16.1.11     ur-vt  802.1x  SQUIR-238BA1077Q  Wireless  eduroam  48:2f:6b:a3:35:40  2.4GHz-HE  aaa-eduroam  N/A   WIRELESS
fe80::ab:cdef:123:4abc             c6:ea:aa:11:22:33  PID@vt.edu         172.16.1.11     ur-vt  802.1x  SQUIR-238BA1077Q  Wireless  eduroam  48:2f:6b:a3:35:40  2.4GHz-HE  aaa-eduroam  N/A   WIRELESS
2607:b400:24:0:123:4567:89ab:cdef  c6:ea:aa:11:22:33  PID@vt.edu         172.16.1.11     ur-vt  802.1x  SQUIR-238BA1077Q  Wireless  eduroam  48:2f:6b:a3:35:40  2.4GHz-HE  aaa-eduroam  N/A   WIRELESS
172.30.123.195                     c6:ea:aa:11:22:33  PID@vt.edu         172.16.1.11     ur-vt  802.1x  SQUIR-238BA1077Q  Wireless  eduroam  48:2f:6b:a3:35:40  2.4GHz-HE  aaa-eduroam  N/A   WIRELESS

Total entries = 4

Searching by the PID will return results for both PID (e.g., registered devices) and PID@vt.edu (e.g., eduroam).

Terminate the sessions

For each unique MAC address listed in the previous step, use the aaa user delate command to end the sessions. Note that deleting by the username from the MC is not currently supported.

(isb-mm-1) [mynode] #aaa user delete name PID
This command is not currently supported

(isb-mm-1) [mynode] #aaa user delete mac c6:ea:aa:11:22:33
Users will be deleted at MDs. Please check show CLI for the status
(isb-mm-1) [mynode] #show aaa user-delete-result

Summary of user delete CLI requests !
Current user delete request timeout value: 300 seconds

aaa user delete mac c6:ea:aa:11:22:33  , Overall Status- Response pending , Total users deleted- 0
MD IP : 172.16.1.11, Status- Complete , Count- 0
MD IP : 172.16.1.12, Status- Complete , Count- 0
MD IP : 172.16.1.13, Status- Complete , Count- 0
MD IP : 172.16.1.14, Status- Complete , Count- 0
MD IP : 172.16.1.141, Status- Complete , Count- 0
MD IP : 172.16.1.142, Status- Complete , Count- 0
MD IP : 172.16.1.143, Status- Complete , Count- 0
MD IP : 172.16.1.144, Status- Complete , Count- 0
MD IP : 172.17.1.11, Status- Complete , Count- 0
MD IP : 172.17.1.12, Status- Complete , Count- 0
MD IP : 172.17.1.13, Status- Complete , Count- 0
MD IP : 172.17.1.14, Status- Complete , Count- 0
MD IP : 0.0.0.0, Status- Response pending , Count- 0
MD IP : 0.0.0.0, Status- Response pending , Count- 0
MD IP : 172.16.236.151, Status- Complete , Count- 0
MD IP : 172.16.236.152, Status- Complete , Count- 0

You may notice in that example, the VTC controllers which are connecting over IPv6 (shown as MD IP : 0.0.0.0) still have the response pending. This seems to be a bug. To work around this bug, log into the appropriate MDs (reference "Current switch" column in the global users table) and run the same command.

(col-md-1) #aaa user delete mac c6:ea:aa:11:22:33