Getting SQL30082N Security processing failed with reason "24" ("USERNAME AND/OR PASSWORD INVALID"). SQLSTATE=08001

Disclaimer: It's been quite a long time since I last used DB2 but I think I found someting for you: http://publib.boulder.ibm.com/infoce...c/c0005435.htm Table 1 on this page explains how authentication will happen if you set TRUST_ALLCLNTS to DRDAONLY and TRUST_CLNTAUTH to CLIENT (I believe this is what you need).

Please check it out and see if it helps.

I hope it does.

Unfortuantely, I'm not able to change the parameters at this time.

Hi data_bits,

The settings that you show are the default setting from a base installation.  No one has changed them, so they should "just work".

Unless Kerberos or similar tool is installed, authentication is deferred to the O/S.  You must have a user name on the server to connect to the database.

For most users, connection is simply:

  connect to {db}

To connect with a specific user:

  connect to {db} user {me} using {password}
  connect to {db} user {me} using '{password}'
  connect to {db} user {me} using "{password}"

The DB2 CLP is quite forgiving and allows the password to be open, enclosed in single quotes, or enclosed in double quotes.  If the password contains some of the "special characters" it must be enclosed in quotes.


Kent

I am checking whether they can login remotely using a client like TOAD or Data Studio. But it sounds like that doesn't work either.

I was able to login as the user to the OS, and then used
       db2 connect to mydb
and I was able to connect to the database.

It's still giving me the SQL30082N when I try from OS prompt using the full connect with user/using syntax.

I think everything is working for everyone else or we would have heard big time since its a production database. It's just 4 new users that are having this problem.

Since its set to server authentication, I suppose that's why the straight "connect to mydb" works.

But I don't know why the other syntax is not working. I have these same settings in other environments (Linux) and they work fine. We should be able to connect a server and then connect as a different user to a database if we provide the credentials.

Is there something in AIX that may be preventing this from working?

As far as I know, nothing has changed there on the server.

> 4 new users that are having this problem.


Can you read the system files on the AIX server?  If so, check the /etc/passwd file to see what users are defined on the server.  There's a good chance that everyone with an explicit login (CONNECT TO db USER xxx USING xxx) is listed there.


Kent

The user is in /etc/passwd.

I see these in the diag.log file:

2014-02-14-08.16.17.062822-360 I4214330A442       LEVEL: Warning
PID     : 13566122             TID  : 17514       PROC : db2sysc 0
INSTANCE: dbeme1p              NODE : 000         DB   : PEMEDB
APPHDL  : 0-14331
EDUID   : 17514                EDUNAME: db2agent (PEMEDB) 0
FUNCTION: DB2 UDB, bsu security, sqlexLogPluginMessage, probe:20
DATA #1 : String with size, 66 bytes
Password validation for user starkusr failed with rc = -2146500502

The password is pretty simple just numbers and alphabetics. It is 8 characters in length. Should we change it to something shorter?

8 characters shouldn't be a problem.

Oracle passwords are usually not case sensitive, but unix based passwords are.  Make sure that the password given to DB2 is in the correct case.

Kent

The password is entered correctly in the matching case.

Ask your DB2 and AIX admins if they've installed any 3rd party authentication packages.  Based on the settings that you show, your process should work.  To prove it, I tested this be creating the user 'db2user' on my DB2 server, password 'db2User' (note the capital 'U').  I then connected to the SAMPLE database.

db2 => list database directory

 System Database Directory

 Number of entries in the directory = 3

Database 1 entry:

 Database alias                       = xxxxx
 Database name                        = xxxxx
 Local database directory             = K:
 Database release level               = d.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

Database 2 entry:

 Database alias                       = TOOLSDB
 Database name                        = TOOLSDB
 Local database directory             = K:
 Database release level               = d.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

Database 3 entry:

 Database alias                       = SAMPLE
 Database name                        = SAMPLE
 Local database directory             = K:
 Database release level               = d.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

db2 => connect to sample user db2user using db2user
SQL30082N  Security processing failed with reason "24" ("USERNAME AND/OR
PASSWORD INVALID").  SQLSTATE=08001
db2 => connect to sample user db2user using db2User

   Database Connection Information

 Database server        = DB2/NT 9.7.4
 SQL authorization ID   = DB2USER
 Local database alias   = SAMPLE

db2 => connect to sample user db2user using 'db2User'

   Database Connection Information

 Database server        = DB2/NT 9.7.4
 SQL authorization ID   = DB2USER
 Local database alias   = SAMPLE

db2 => connect to sample user db2user using "db2User"

   Database Connection Information

 Database server        = DB2/NT 9.7.4
 SQL authorization ID   = DB2USER
 Local database alias   = SAMPLE

db2 =>

As long as the user/password is in the correct case, all is well.


Kent

I asked the AIX admins about 3rd party authentication tools and none are in place here.

I made sure the password was entered correctly.

Remote connections by clients do not work either from TOAD or Data Studio.

Is it possible the db2ckpw process needs to be recycled due to the security plug-in responsible for the authentication (IBMOSauthclient.so) maybe having reached a saturation point?

I haven't heard of this before but wonder if this is the case? Has anyone else ever had this problem?

If so, what was done to resolve it? Do I need to bounce the DB2 instance to get everything back to a level state?

It looks like its a problem with the DB2 server.

I'm at my wits end.

I stumbled on something that suggested shutting down the instance and doing a db2iupdt to get the security commands relinked. Does that sound like it would work?

I don't have root access.

If the problem is on the server, your DBA needs to fix it.  That's his job.  The system security prevents you from getting to the things that need analyzing and modifying.

Kdo-what do i need to tell the dba to do?

The DBA should know.  He's apparently made changes to the base install that are affecting this.  He should have some idea what he did and why.

Start by telling him just what you told me -- you cannot connect to DB2 from any of the remote clients.  It should take him just a few minutes to understand why.


Kent

He claims he has done not done anything to the environment. All old users are working ok. its just new users that can't connect using passwords.

It sounds like he's not being very cooperative.

For your new users, is the database cataloged correctly?

  db2 connect to mydb user app1 using my_password

That requires that mydb be cataloged to the client machine.  If that's not done, you won't be able to log onto DB2, though I would expect a connection error, not an authentication error.

It doesnt even work locally on the same server as where the database resides. And it only affects these new users.

That tells me a ton.

Can the old users create a telnet session to the AIX server?