Results 1 to 6 of 6
  1. #1
    Join Date
    Sep 2014

    Unanswered: DB2 9.7 Linux, LDAP auth, windows client not working


    I am trying to setup transparent LDAP auth for DB2 9.7. I have successfully configured an LDAP server (389-ds), the db2 server (9.7 ln RHEL 6.5 64-bit). I can login to the server command line using the ldap account, and connect to a database from the linux shell and select data from a table that the LDAP group my user is in has been granted read to.

    However..... After setting DB2AUTH to OSAUTHDB

    this only works if I use:

    connect to SAMPLE

    if I use

    connect to SAMPLE user USERNAME using PASSWORD

    It registers as SQL30082N Security processing failed with reason "24" ("USERNAME AND/OR

    also, the same is true if I use a local user in a local group. And, the windows db2 client can't connect either. It gets an auth failure as well.

    If I don't use the DB2AUTH variable setting, only local users and groups can access the database, LDAP users can't.

    So, I am guessing that the DB2 Client installed on the Windows workstation is providing the user attribute ( which it should because the windows username is not the same as the Linux username).

    My question: once the DB2AUTH=OSAUTHDB has been set, is there a different syntax that needs to be used for the CONNECT TO DATABSE USER USERNAME statement? Or is there a different setting or configuration on the client to make it work?

    To summarize-
    Before setting DB2AUTH=OSAUTHDB, local users and groups can access db2 from the command line using connect to ... user .... using.... , and from the db2 client on a windows machine with the ODBC and CLI settings, but LDAP users cannot.

    After DB2AUTH=OSAUTHDB, local users and groups AND ldap users and groups can access db2 from the command line using connect to database..., but cannot use connect to ... user ... or use the db2 client.

    I can't find any other recommended configuration in the db2 ldap transparent setup docs or various online resources. Thoughts?

  2. #2
    Join Date
    Apr 2006
    Provided Answers: 11
    according the doc
    To enable transparent LDAP authentication, set the DB2AUTH miscellaneous registry variable to OSAUTHDB. Supported operating systems are:

    Best Regards, Guy Przytula
    Database Software Consultant
    Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
    Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
    DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
    Information Server Datastage Certified

  3. #3
    Join Date
    Sep 2014
    Yes, I did those things. But, as I said ONCE I DO THAT, the behavior changes.

    I can no longer connect with the Windows DB2 Client, and if I log in to linux directly, the db2 connect to <database> statement works, but db2 connect to <database> user <username> statement does not.

    Does anyone else have a suggestion?

  4. #4
    Join Date
    Jun 2003
    Toronto, Canada
    Provided Answers: 1
    Local connections without specifying the authorization ID ("CONNECT TO MYDB") do not perform authentication, but those with the authorization ID ("CONNECT TO MYDB USER blah") will attempt to authenticate, hence the difference in behaviour. You should check what shows in db2diag.log during the failed authentication attempts, as well as look at the LDAP server logs to see what gets sent during the OS authentication attempts vs. DB2 authentication.
    "It does not work" is not a valid problem statement.

  5. #5
    Join Date
    Sep 2014
    Thank you for your response.

    Before even using a LDAP user, I am trying to use a linux local user, robins, on the db2 server. this is the result:

    ---->user shell

    login as: robins
    robins@db2server's password:
    Last login: Tue Sep 30 13:06:42 2014 from
    [robins@db2server ~]$ db2
    (c) Copyright IBM Corporation 1993,2007
    Command Line Processor for DB2 Client 9.7.7
    To list the current command option settings, type LIST COMMAND OPTIONS.

    For more detailed help, refer to the Online Reference Manual.

    db2 => connect to sample user robins
    Enter current password for robins:
    SQL30082N Security processing failed with reason "24" ("USERNAME AND/OR
    db2 =>

    ---->tail -f /var/log/secure - The ssh login to the server is shown, but no further attempts at auth. Does this mean the db2 server didn't even try to pass the credentials to pam_unix?
    Oct 1 11:09:45 db2server sshd[28553]: Accepted password for robins from w.x.y.x port 2117 ssh2
    Oct 1 11:09:45 dwdatadevm1 sshd[28553]: pam_unix(sshd:session): session opened for user robins by (uid=0)

    --->tail -f DIAGPATH/db2diag.log
    2014-10-01- I25351275E447 LEVEL: Warning
    PID : 26803 TID : 140737035364096PROC : db2sysc 0
    INSTANCE: db2instance NODE : 000 DB : SAMPLE
    APPHDL : 0-1501
    EDUID : 41 EDUNAME: db2agent (SAMPLE) 0
    FUNCTION: DB2 UDB, bsu security, sqlexLogPluginMessage, probe:20
    DATA #1 : String with size, 65 bytes
    Password validation for user robins failed with rc = -2146500507

    Remember, at this point, all I have done is set the DB2AUTH setting. By the way, the result is exactly the same if I use an LDAP user. I don't see any evendence that the DB2 server is actually trying to authenticate the user credentials suppled in the connect statement. There has the be a disconnected or misconfigured setting somewhere.

  6. #6
    Join Date
    Sep 2014

    SOLVED - DB2 Ldap SSSD

    Thanks. I now have a solution - for posterity:

    When setting up transparent LDAP authentication for DB2 on RHEL 6.x using sssd instead of pam_ldap, create the file /etc/pam.d/db2 according to the IBM directions, but change the pam_ldap lines to pam_sss:

    auth    required 
    auth    sufficient likeauth nullok 
    # auth    sufficient use_first_pass 
    auth    sufficient use_first_pass
    auth    required 
    account  required 
    account  sufficient uid < 100 quiet 
    #account  sufficient  
    account  sufficient  
    account  required 
    password requisite retry=3 dcredit=-1 ucredit=-1 
    password sufficient nullok use_authtok md5 shadowremember=3 
    #password sufficient  use_first_pass 
    password sufficient  use_first_pass 
    password required 
    session  required 
    session  required
    This fixes the problem.

Posting Permissions

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