db2 can't connect from clients after restart

Question

I stopped my db using db2stop force. The started did a backup restarted and after that i cannot connect to db from the a client anymore i get: using the command

db2 connect to "dbname" using "user"

SQL30082N Security processing failed with reason "42" ("ROOT CAPABILITY REQUIRED"). SQLSTATE=08001

password and username are correct. When im on the server connecting using command

db2 connect to "dbname"

or

db2 connect to "dbnmae" user "user"

or

db2 connect to "dbname" user db2inst1

works just fine. I m really confused. Any help is much appreciated Thanks.

What i tried so far :

db2 get dbm cfg | grep -i auth GSS Plugin for Local Authorization
(LOCAL_GSSPLUGIN) = Server Connection Authentication
(SRVCON_AUTH) = NOT_SPECIFIED Database manager authentication
(AUTHENTICATION) = SERVER Cataloging allowed without authority
(CATALOG_NOAUTH) = NO Trusted client authentication
(TRUST_CLNTAUTH) = CLIENT Bypass federated authentication
(FED_NOAUTH) = NO

switched to client but did not using

db2 update dbm cfg using authentication client

Update:

Despite the age of this question, it would be wonderful to have a solid answer to this question. Hi locojay, how did you manage? :-)

I'm having the SQL30082N reason code 24 issue in my Windows PC, and today we experienced the same issue in an AIX server.

I googled for a couple hours and didn't find but one happy answer, related to having users with the same name both in the server and the client. IMO it does not apply to me, as I'm running into a VBox that´s isolated from the domain (no network).

My case: I installed DB2 as user db2admin, no security. Then I granted DBADM to VIRTUALUSR01 and gave this user a password.

  db2 connect to TheBase

works fine. But

  db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword 

returns SQL30082N with reason code 24.

Answer 1

Using client authentication is generally a Bad Idea(TM). That's because you now rely on machines that you may not control for authentication. If I wanted to subvert your system, I could create a new user locally, say, db2inst1 or VIRTUALUSR01 or Administrator, with a password I know, and then, use that to wreak havoc on the database. If, however, no one in your organisation has root/administrator authority over their own machines, client authentication can be made to work. But all it takes is someone plugging in their own personal laptop, and your database could be at risk.

Instead, check the permissions of the files. If you've installed as root, ~db2inst1/sqllib/security/db2c[hk]pw (assuming instance ID of db2inst1) should be setuid root. If not, run db2iupdt against your instance (./db2iupdt db2inst1) which should fix the permissions.

If you've installed without root authority ("non-root install"), which I doubt, since you seem to have had this working, you would need to read the DB2 documentation on non-root installations and their limitations - I don't use non-root installs myself, so I'm not so familiar with them. However, there should be a set-root script that you can use to enable setuid root which, of course, you have to run as root.