Auditing authentication issues in a distributed environment
As per the definition of your database link, it's a fixed user database link. 

If a link includes a fixed user, the fixed user's username and password are used to connect to the remote database.

For example, you have connected as kjohnston and created a fixed user private database link, If kjohnston uses the fixed user link in a query, then kjohnston is the user on the local database, but you connect to the remote database as testuser.

So you can't get the session information of testuser in the local database. DB one is just acting as client tool for the testuser. 

SQL&gt; SELECT users.username, users.lock_date, aud.os_username, aud.userhost, aud.sessionid, aud.os_process 
  FROM dba_users users 
  JOIN dba_audit_trail aud
    ON aud.username = users.username
   AND aud.timestamp = users.lock_date
 WHERE users.account_status in ('LOCKED', 'LOCKED(TIMED)')
   AND aud.action = 100 
   AND aud.returncode = 1017;  2    3    4    5    6    7    8  

USERNAME               LOCK_DATE
------------------------------ ---------
OS_USERNAME
--------------------------------------------------------------------------------
USERHOST
--------------------------------------------------------------------------------
 SESSIONID OS_PROCESS
---------- ----------------
TESTUSER               10-MAR-17
oracle
testserver1
   1590012 3348


You can get the locked username using the above query. 

On DB1, you can query the dba_db_links view to know who is the owner of that dblink.

SQL&gt; select * from dba_db_links where username='TESTUSER';


And you can get all the SQL fired by that user using either auditing or tracing. 


  I've tried querying v$session (on SID and AUDSID columns) and v$active_session_history (on SESSION_ID) on both DB1 and DB2 in an attempt to get more information. However, all attempts to query these tables on either database using either SESSIONID or OS_PROCESS values have failed (0 results returned).


You can't get information from these views on DB1 because that information is belongs to testuser which has created session on DB2.