origin of connection

pts.
Tags:
AS/400
DataCenter
Security
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?
Asked: Last updated:
Related Questions
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

My first thought would be to check the joblog of the QZDASOINIT job in question to see if it provides any additional information; a specific user ID and IP address is sometimes listed there. Other than that, I’m not really sure.

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • MODMOD
    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.
    0 pointsBadges:
    report
  • KevinBattreall
    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
    0 pointsBadges:
    report
  • MODMOD
    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)
    0 pointsBadges:
    report
  • ParityError
    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.
    0 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: