Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I am using db2inst1 to connect to a database in DB2 which I have installed on my machine. Therefore, db2inst1 user does not require username/password authentication (borrows them from the OS). I would like to change that, and force every time a connection is initiated a username/password to be requested.

More specifically, this is how the authentication configuration looks like:

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) = CLIENT
 Alternate authentication           (ALTERNATE_AUTH_ENC) = NOT_SPECIFIED
 Cataloging allowed without authority   (CATALOG_NOAUTH) = NO
 Trusted client authentication          (TRUST_CLNTAUTH) = SERVER
 Bypass federated authentication            (FED_NOAUTH) = NO

db2 connect to dbName

   Database Connection Information

   Database server        = DB2/LINUXX8664 10.1.0
   SQL authorization ID   = DB2INST1
   Local database alias   = DBNAME

db2 connect to dbName user db2inst1 using password

   SQL1639N  The database server was unable to perform authentication because 
   security-related database manager files on the server do not have the required 
   operating system permissions.  SQLSTATE=08001

I have played with some authentication combinations for "AUTHENTICATION" and "TRUST_CLNTAUTH" without much luck.

share|improve this question

2 Answers 2

I believe you want the following

  • AUTHENTICATION = CLIENT
  • TRUST_ALLCLNTS = NO
  • TRUST_CLNTAUTH = SERVER

As you have changed above, the AUTHENTICATION=CLIENT, will force the client to authenticate. (Which can still use the OS as noted above.)

TRUST_CLNTAUTH = SERVER will cause the client to send the user id and password to the server for authentication when they are provided in the connect statement. This still does not force the client to require the user name and password as it can get them from the OS.

This is because DB2 will assume TRUST_ALLCLNTS as YES by default. This causes the server to assume all clients can be trusted and allow them to check against their respective OS's. So from what I know, to force the client to require a user name and password with the connect statement requires TRUST_ALLCLNTS to be set to NO. This will cause the server to not trust them and force them to send the user id and password to the server to authenticate against it.

share|improve this answer
    
I changed the TRUST_ALLCLNTS = NO |||| db2 get dbm cfg|grep -i trust Trust all clients (TRUST_ALLCLNTS) = NO Trusted client authentication (TRUST_CLNTAUTH) = SERVER ||| db2 connect to dbName user db2inst1 using password still returns SQL1639N –  John Pappas Jan 15 '13 at 23:36
    
I also dropped the database, db2stop and db2start... but the same issue persists. Am I missing something? –  John Pappas Jan 15 '13 at 23:38
    
After reading the documentation it looks like: If TRUST_ALLCLNTS is set to "NO", the untrusted clients must provide a userid and password combination when they connect to the server. Untrusted clients are operating system platforms that do not have a security subsystem for authenticating users. publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/… –  John Pappas Jan 16 '13 at 20:02
    
but I am still wondering, what is going wrong here? Dos this mean that the user "trusted"? Not to mention the fact that same holds for any user in my Linux system. –  John Pappas Jan 16 '13 at 20:17
    
I'm thinking part of the challenge is that the client and the server reside on the same system. –  Chris Aldrich Jan 16 '13 at 22:06

You issue db2 connect from the same operating system where the server (database) is installed. In this case there is no difference between AUTHENTICATION=CLIENT and AUTHENTICATION=SERVER or SERVER_ENCRYPT (by the way, I believe the manuals strongly recommend against CLIENT setting).

If you are logged in as an OS user db2inst1, the DB2 will not doubt that OS authenticated you as such. I am not aware of any trick that would cause DB2 to re-authenticate OS user just to "double check". But a very easy way to accomplish what you require is to be a different OS user while issuing db2 connect. If you are logged in as john and try to db2 connect to mydb user db2inst1, you will be asked for a password, because DB2 can see that OS have not authenticated you as db2inst1. Hence DB2 asks for a password and performs OS authentication on your behalf.

In a default database setup, all users (including john) would be able to connect as themselves, so, as you apparently have security in mind, you'd probably want to revoke connect on database from public first.

share|improve this answer
1  
If you catalog the database using a loopback TCP/IP connection and change the authentication method to SERVER (fixing the permissions problem causing SQL1639N) it will be requiring you to enter user credential each time you connect, as it won't use local user authentication for a seemingly remote connection. –  mustaccio May 22 '13 at 16:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.