Windows has a long-standing bug whereby sessions that were actually disconnected long ago sometimes remain active on the server end indefinitely as a sort of zombie session. This isn't usually a problem unless they are holding files or directories open, in which case they may need to be manually disconnected by the administrator. (They will also be cleaned up if the server is rebooted.)
It is therefore possible that someone opened a connection to the server in question by mistake, e.g., by double-clicking the wrong icon in the Network view, and that session might still be appearing in the sessions list on the server. If, on the other hand, the session reappears after being disconnected, it indicates that the client in question is genuinely connected to the server - that could still be by mistake, of course. You would need to look at the client, not the server, to figure out what is going on there. Note that a connected session isn't necessarily connected to anything in particular, even just running the
net view command against a remote server establishes a session in order to enumerate the available shares.
It is unlikely that the information reported by
net session is incorrect, but if in doubt, you can log into the server at the console or via Remote Desktop and use Computer Management to examine the connected sessions. You could also cross-reference with the output of the
netstat command which shows the underlying network connections, if the session is a zombie it would probably not appear in
I would have expected
net session to also show the connection being used to run the remote command, but this depends on how the remote access is implemented. Since
net session only shows SMB sessions, any mechanism that uses TCP/IP directly wouldn't show up. Neither would a system that establishes the SMB session in reverse, from the system where the command is being run to the system that requested it.