Tracking The Source of a Bad Password
We had a customer recently who had someone locking out a service account on IBM i. This service account ran their BI dashboard. The question was asked: “how can we find out who did this?”
Using the audit journal, we have the ability to find out where the bad password requests came from. When you narrow down the where, the who becomes much easier to figure out.
If you are auditing your security events (which you should be) then you can do the following steps. You’ll need your QAUDLVL system value to include *AUTFAIL and *SECURITY. If you don’t audit security events, check this IBM technote to start doing so: http://www-01.ibm.com/support/docview.wss?uid=nas8N1014712.
First, you need to copy the audit journal entries into something much more readable: a table. The following will export all bad password entries to an outfile called QAUDITPW in QGPL from the current chain of journal receivers.
CPYAUDJRNE ENTTYP(PW) OUTFILE(QGPL/QAUDIT) JRNRCV(*CURCHAIN) FROMTIME(*FIRST) TOTIME(*LAST)
Once you have that available we can then run the following SQL statement to get all instances of a bad password request for an account called ‘LCKDACCT’ and some additional valuable information. STRSQL
SELECT PWJOB, PWUSER, PWNBR, PWPGM, PWUSPF, PWRPORT, PWRADR, PWESDL,
PWTYPE, PWUSRN,PWTSTP FROM QGPL/QAUDITPW
WHERE PWUSRN = ‘LCKDACCT’
The 7th field PWRADR is the remote IP address of the connection request with the bad password. If you have an IP address then you can narrow down your search, especially if it’s a recent event and the offending user is still using the same IP address. If it’s a server, which in this event it was, we can at least determine a subset of users who have access to the server and then walk back the cat from there, so to speak.