IF the connections are ODBC, is there even a process on the back-end? Unless there is a network broker task that is unique to Firebird's implementation, it is likely that at most, you would have a child process of Firebird itself (one per active client) for which a specific username would not be recognizable from the back-end. And the implementation doesn't have to even do that much if they use a pre-determined number of slots and just allocate a bunch of connection sockets internally. There is no guarantee that ODBC is not linearized internally on either a round-robin scheme or a first-come, first-served scheme.
You MIGHT get somewhere on the server using Windows Task Manager IF you could get there. Launch WTM. Select the "Performance" tab. At the bottom, click "Open Resource Monitor."
This next part isn't too hard, but requires you to maybe take notes. On Resource Monitor, select the Disk tab. Under the "Disk Activity" section (which you can expand by cursor-drag over the bottom edge), there is list of processes and files they have open. Find your database file. Clicking in the "File" column header changes the sort order to group the files together, which SHOULD make things easier to find. Each section scrolls independently so it won't be a terrible experience. Make a list of process IDs using your database.
Now switch to the Networks tab. Click in the "PID" column header to sort that list in PID order. You should be able to see the IP addresses of the sessions connected to your DB. You can ignore any that use the IPv4 loopback IP; those are internal connections that don't directly lead to anyone in particular and are usually part of the particular task's implementation. But you should be able to visit each PC to determine what IP address it is using, and that should match up with one of the connections from that list.