Today I ran a DSPAUDJRNE ENTTYP(PW) USRPRF(*ALL) and while skimming over the results I noticed several entries similar to the following :
Violation Type : U
User Profile : ADMIN
Device Name : Communications Device
Remote Name :
Local Name :
Network ID :
Job Name : QZDASOINIT
Job User : QUSER
Job Number : 399141
Timestamp : 2006-09-19-03.39.04.647936
I know that QUSER/QZDASOINIT jobs are SQL connections, and there is no 'ADMIN' profile. But I am concerned by the frequency that this is occuring. Does anyone know if there is a way I can trace back the IP address the request originated from?
Unluckily, looking at the job won't work. this only happens once every few days, and at unpredictable times. and when I look back at the history log, it ends the job right after the failed login.
The up side, is I have noticed a trend where the same user has run a SQL connection right after the failed connects, so I'm going to research if something is odd with their DSN. But, I'd still like to be able to review, and be sure they have the same IP address as an origin.
we never get one of the normal CPIAD12 : "Servicing user profile USER from client IP." messages.
We're still running V4R4, and I don't think IBM even had the CPIAD12 messages until V4R3, so, it's entirely possible there simply isn't a log of what I need. I just find that odd since IBM is usually very good about security, and auditability.
Try looking at the history log.
DSPLOG JOB(686507/QUSER/QZDASOINIT)
User WBQUOTE from client 172.17.10.233 connected to job 686507/QUSER/QZDASOIN
User WBQUOTE from client 172.17.10.233 connected to job 686507/QUSER/QZDASOIN
unluckily, the history log doesn't do any good :/ since the login fails, a CPIAD12 (the user/client message) never generates. all that I get is :
Job 399134/QUSER/QZDASOINIT started on 09/19/06 at 02:49:49 in subsystem QSER
and
Job 399134/QUSER/QZDASOINIT ended on 09/19/06 at 03:38:53; 1 seconds used; en
bringing up the details on those messages doesn't contain an IP address, so, without a successful login to record the IP address, it doesn't do much good. (history log was one of the first things I tried)
If all else fails, you could try a comm trace and search for the attempted ADMIN login, especially if you have a suspected IP address you can filter on it and shorten your search.
The big problem is running V4R4 which is long obsolete. If you could run a current release, the IP address would be logged in the journal entry itself.
Your only reasonable choice is to attach an exit program to the various SQL exit points. Retrieve the remote IP address from the job attributes when the connection is initiated.
Tom
Discuss This Question: 5  Replies