Results 1 to 7 of 7
  1. #1
    Join Date
    Oct 2004
    Posts
    268

    Unanswered: Password validation for user

    DB2 V9.5 FP8 64 bit - RHEL 6.2

    I am getting below warning in db2diag.log file and there is no such user as "xwsbuser". The user "xwbuserp" we have works fine. I get this message only once in a while and not continuously.

    2012-07-20-14.24.32.363314-240 I3862697E435 LEVEL: Warning
    PID : 22399 TID : 140064025732864PROC : db2sysc
    INSTANCE: db2inst1 NODE : 000 DB : XWPROD1
    APPHDL : 0-26393
    EDUID : 23103 EDUNAME: db2agent (XWPROD1)
    FUNCTION: DB2 UDB, bsu security, sqlexSlsSystemAuthenticate, probe:150
    MESSAGE : application id:
    DATA #1 : String with size, 26 bytes
    AC142C16.04DA.120720182432


    2012-07-20-14.24.32.548824-240 I3863133E442 LEVEL: Warning
    PID : 22399 TID : 140064025732864PROC : db2sysc
    INSTANCE: db2inst1 NODE : 000 DB : XWPROD1
    APPHDL : 0-26394
    EDUID : 23103 EDUNAME: db2agent (XWPROD1)
    FUNCTION: DB2 UDB, bsu security, sqlexLogPluginMessage, probe:20
    DATA #1 : String with size, 67 bytes
    Password validation for user xwsbuser failed with rc = -2146500502

    Is this mean some one trying to connect to database with userid "xwsbuser" ?. How can I find out which server/source the request is made from ?

    Thanks for any help.

  2. #2
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Yes, someone tried to use that id.

    You can check APPHDL : 26394 to see if it still connected, and then look at the ip address (db2 list applications).
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  3. #3
    Join Date
    Oct 2004
    Posts
    268
    Quote Originally Posted by Marcus_A View Post
    Yes, someone tried to use that id.

    You can check APPHDL : 26394 to see if it still connected, and then look at the ip address (db2 list applications).

    I don't think it was ever connected since the userid/password never existed on the server. Any other way to find out ?

  4. #4
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by mdx34 View Post
    I don't think it was ever connected since the userid/password never existed on the server. Any other way to find out ?
    Not that I know of (going backwards), but you can set up DB2 auditing to trap that in the future. Not sure why you care if it only happened once? Is it a crime to make a typo?
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  5. #5
    Join Date
    Oct 2004
    Posts
    268
    Quote Originally Posted by Marcus_A View Post
    Not that I know of (going backwards), but you can set up DB2 auditing to trap that in the future. Not sure why you care if it only happened once? Is it a crime to make a typo?
    Not only once. Several times on different days. I don't think it is a person trying to type the userid/password. I am thinking may be some one entered wrong userid/password on an application connection string that connects to the database. The other ID I mentioned is the userid for WebSphere application that connects to the database (Which works).

    I am trying to find out what process trying to connect to database with wrong userid/password so that we can correct it.

  6. #6
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Code:
    MESSAGE : application id:
    DATA #1 : String with size, 26 bytes
    AC142C16.04DA.120720182432
    The IP address of the client attempting to connect is AC.14.2C.16, that is, 172.20.44.22
    ---
    "It does not work" is not a valid problem statement.

  7. #7
    Join Date
    Oct 2004
    Posts
    268
    Quote Originally Posted by n_i View Post
    Code:
    MESSAGE : application id:
    DATA #1 : String with size, 26 bytes
    AC142C16.04DA.120720182432
    The IP address of the client attempting to connect is AC.14.2C.16, that is, 172.20.44.22

    Thank you. We found out that a WebSphere Application server was pointing to client production server rather that client test server and corrected it...........Thanks again.
    Last edited by mdx34; 07-23-12 at 10:32.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •