はじめに
Autonomous DatabaseのDBユーザーのパスワードを変更後、クライアント（アプリケーション）側のパスワード変更漏れでDBユーザーがロックされてしまう場合に、原因となっているクライアントを特定する方法です。
確認方法
Autonomous Databaseでは、デフォルトでユーザーのログイン失敗が監査情報として取得されているため、UNIFIED_AUDIT_TRAILビューを使用して、ログインに失敗しているユーザーのクライアント情報を確認することができます。
こちらのSQLの「DBユーザー名」の部分をロックされてしまったDBユーザー名に変更して実行することで、ログインに失敗しているユーザーのクライアント情報を確認できます。
set linesize 100
col userhost for a15
col os_username for a15
col client_program_name a30
SELECT
userhost, -- クライアントアプリケーションのホスト名
os_username, -- クライアントアプリケーションを実行しているOSユーザー名
client_program_name, -- クライアントプログラム名
authentication_type -- クライアントの認証情報
FROM unified_audit_trail
WHERE dbusername = 'DBユーザー名'
AND unified_audit_policies = 'ORA_LOGON_FAILURES';
DBユーザー名にADMINを指定して実行してみます。
SQL> set linesize 100
SQL> col userhost for a15
SQL> col os_username for a15
SQL> col client_program_name a30
SQL> SELECT
2 userhost,
3 os_username,
4 client_program_name,
5 authentication_type
6 FROM unified_audit_trail
7 WHERE dbusername = 'ADMIN'
8 AND unified_audit_policies = 'ORA_LOGON_FAILURES';
USERHOST OS_USERNAME CLIENT_PROGRAM_NAME
--------------- --------------- ------------------------------------------------
AUTHENTICATION_TYPE
----------------------------------------------------------------------------------------------------
apserver1 opc sqlplus@apserver1 (TNS V1-V3)
(TYPE=(DATABASE));(CLIENT ADDRESS=((PROTOCOL=tcps)(HOST=xxx.xxx.xxx.xxx)(PORT=34350)));
SQL>
こちらの例では、
IPアドレスxxx.xxx.xxx.xxxを持つapserver1という名前のホスト上のOSユーザーopcが実行しているSQL*Plusからの接続
でログインが失敗していることがわかりました。
まとめ
UNIFIED_AUDIT_TRAILビューを使用して、Autonomous Databaseへのログインに失敗しているDBユーザーのクライアント情報を確認することができました。めでたし、めでたし。