LDAP/NIS user cannot activate dbaccess

Hi All, LDAP/NIS users which are not OS based are unable to use dbaccess command. The other OS users (informix) is able to connect to the database. I tried login with LDAP user and set all the environment variables and tried dbaccess, the command freezes and no output, no dbaccess screen no error, nothing was there. I setup same environment for OS user and it worked. Please help to sort this issue out. Your help is much appreciated. Thanks & Regards, Sameer Sharma

It's hard to say if the problem is only on the engine side (where there is a problem for sure) or also from dbaccess also. A truss to the process could help.... Let's have an overview so that you can better understand what's happening. At first glance I'd expect a -951 error or eventually that it worked. If you're testing locally, you should try remotely... As Informix works a bit differently when authenticating locally. In the past (up to version 11.70FC3 or FC2) informix required all the users to be recognized by the underlying OS. Note that I'm trying to choose my words carefully as the devil is in the details... When I say "recognized" I mean a low level call to the getpwnam() function would retrieve the user details (UID, GID, password, home, etc.). Basically what traditionally was stored in /etc/passwd and /etc/shadow. Now... I'ts possible to have the OS responding to getpwnam() even for LDAP/NIS users. In some cases it may require special configurations. But even here you may face an issue with password authentication... Informix usually (there may be a few exceptions depending on version and platform) that the getpwnam() call returns the encrypted password. It then calls crypt() to encrypt the user provided password and checks if they're the same. But some recent LDAP servers consider the sending of the password (even in encrypted form) as a security flaw and they don't send it. Without it, Informix usually complains with error -952. In your case the fact that it hangs is a bit strange and would require further investigation. What would be the solution? Since version 11.70.FC3 (or FC2) a few improvements were made: 1- We can create database users 2- We can define "surrogate users" (to which OS account your external or database internal user will be mapped Additionally because of the getpwnanm issue you could consider PAM (with surrogate user mapping) I imagine you're more confused now than before you read this. I could try to explain better, but the fact is that this is a complex issue. You could open a PMR, or you could start by trying to connect remotely and see what happens. running trus/strace on dbaccess could give some more clues, but again, interpreting it requires some skills.... Regards. On Fri, Sep 16, 2016 at 3:17 PM, SAMEER SHARMA <sameersharma34@gmail.com> wrote: > Hi All, > > LDAP/NIS users which are not OS based are unable to use dbaccess command. > The > other OS users (informix) is able to connect to the database. I tried login > with LDAP user and set all the environment variables and tried dbaccess, > the > command freezes and no output, no dbaccess screen no error, nothing was > there. > > I setup same environment for OS user and it worked. Please help to sort > this > issue out. Your help is much appreciated. > > Thanks & Regards, > Sameer Sharma > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a113f6d5e84eb38053ca16fdc

Sameer. Several months ago I did the same with NIS. The only trick was: restart Informix Engine. Regards. Luis Panozzo Saavedra Gerente Técnico luis_panozzo@sisa.com.bo Soluciones Integrales S.A. Calle Ignacio Cordero 8487 - Piso 2, San Miguel Teléfonos y Fax: +(591)(2) 2773378 / 2794538 La Paz - Bolivia From: "Fernando Nunes" <domusonline@gmail.com> To: ids@iiug.org Sent: Friday, September 16, 2016 11:15:45 AM Subject: Re: LDAP/NIS user cannot activate dbaccess [37836] It's hard to say if the problem is only on the engine side (where there is a problem for sure) or also from dbaccess also. A truss to the process could help.... Let's have an overview so that you can better understand what's happening. At first glance I'd expect a -951 error or eventually that it worked. If you're testing locally, you should try remotely... As Informix works a bit differently when authenticating locally. In the past (up to version 11.70FC3 or FC2) informix required all the users to be recognized by the underlying OS. Note that I'm trying to choose my words carefully as the devil is in the details... When I say "recognized" I mean a low level call to the getpwnam() function would retrieve the user details (UID, GID, password, home, etc.). Basically what traditionally was stored in /etc/passwd and /etc/shadow. Now... I'ts possible to have the OS responding to getpwnam() even for LDAP/NIS users. In some cases it may require special configurations. But even here you may face an issue with password authentication... Informix usually (there may be a few exceptions depending on version and platform) that the getpwnam() call returns the encrypted password. It then calls crypt() to encrypt the user provided password and checks if they're the same. But some recent LDAP servers consider the sending of the password (even in encrypted form) as a security flaw and they don't send it. Without it, Informix usually complains with error -952. In your case the fact that it hangs is a bit strange and would require further investigation. What would be the solution? Since version 11.70.FC3 (or FC2) a few improvements were made: 1- We can create database users 2- We can define "surrogate users" (to which OS account your external or database internal user will be mapped Additionally because of the getpwnanm issue you could consider PAM (with surrogate user mapping) I imagine you're more confused now than before you read this. I could try to explain better, but the fact is that this is a complex issue. You could open a PMR, or you could start by trying to connect remotely and see what happens. running trus/strace on dbaccess could give some more clues, but again, interpreting it requires some skills.... Regards. On Fri, Sep 16, 2016 at 3:17 PM, SAMEER SHARMA <sameersharma34@gmail.com> wrote: > Hi All, > > LDAP/NIS users which are not OS based are unable to use dbaccess command. > The > other OS users (informix) is able to connect to the database. I tried login > with LDAP user and set all the environment variables and tried dbaccess, > the > command freezes and no output, no dbaccess screen no error, nothing was > there. > > I setup same environment for OS user and it worked. Please help to sort > this > issue out. Your help is much appreciated. > > Thanks & Regards, > Sameer Sharma > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a113f6d5e84eb38053ca16fdc ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

User informix would connect via dbaccess but dbaccess database connection failed for any other users. PAM was the fix. Had a PMR with IBM on it....Also, what is the OS and version you are on. I started to see the issue after upgrading to AIX 6.1 AND there were some stringent security measures taken or added to the system by the UNIX group. Josue Pierrot Database Administrator, Information Technology 82 Hopmeadow St, Simsbury, US O 8604082129 M 8609214920 F 8604082139 E jpierrot@chubb.com ACE and Chubb are now one. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Fernando Nunes Sent: Friday, September 16, 2016 11:16 AM To: ids@iiug.org Subject: Re: LDAP/NIS user cannot activate dbaccess [37836] It's hard to say if the problem is only on the engine side (where there is a problem for sure) or also from dbaccess also. A truss to the process could help.... Let's have an overview so that you can better understand what's happening. At first glance I'd expect a -951 error or eventually that it worked. If you're testing locally, you should try remotely... As Informix works a bit differently when authenticating locally. In the past (up to version 11.70FC3 or FC2) informix required all the users to be recognized by the underlying OS. Note that I'm trying to choose my words carefully as the devil is in the details... When I say "recognized" I mean a low level call to the getpwnam() function would retrieve the user details (UID, GID, password, home, etc.). Basically what traditionally was stored in /etc/passwd and /etc/shadow. Now... I'ts possible to have the OS responding to getpwnam() even for LDAP/NIS users. In some cases it may require special configurations. But even here you may face an issue with password authentication... Informix usually (there may be a few exceptions depending on version and platform) that the getpwnam() call returns the encrypted password. It then calls crypt() to encrypt the user provided password and checks if they're the same. But some recent LDAP servers consider the sending of the password (even in encrypted form) as a security flaw and they don't send it. Without it, Informix usually complains with error -952. In your case the fact that it hangs is a bit strange and would require further investigation. What would be the solution? Since version 11.70.FC3 (or FC2) a few improvements were made: 1- We can create database users 2- We can define "surrogate users" (to which OS account your external or database internal user will be mapped Additionally because of the getpwnanm issue you could consider PAM (with surrogate user mapping) I imagine you're more confused now than before you read this. I could try to explain better, but the fact is that this is a complex issue. You could open a PMR, or you could start by trying to connect remotely and see what happens. running trus/strace on dbaccess could give some more clues, but again, interpreting it requires some skills.... Regards. On Fri, Sep 16, 2016 at 3:17 PM, SAMEER SHARMA <sameersharma34@gmail.com> wrote: > Hi All, > > LDAP/NIS users which are not OS based are unable to use dbaccess command. > The > other OS users (informix) is able to connect to the database. I tried > login with LDAP user and set all the environment variables and tried > dbaccess, the command freezes and no output, no dbaccess screen no > error, nothing was there. > > I setup same environment for OS user and it worked. Please help to > sort this issue out. Your help is much appreciated. > > Thanks & Regards, > Sameer Sharma > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a113f6d5e84eb38053ca16fdc ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ____________________________________________________________________ This email (including any attachments) is intended for the designated recipient(s) only, and may be confidential, non-public, proprietary, and/or protected by the attorney-client or other privilege. Unauthorized reading, distribution, copying or other use of this communication is prohibited and may be unlawful. Receipt by anyone other than the intended recipient(s) should not be deemed a waiver of any privilege or protection. If you are not the intended recipient or if you believe that you have received this email in error, please notify the sender immediately and delete all copies from your computer system without reading, saving, printing, forwarding or using it in any manner. Although it has been checked for viruses and other malicious software ("malware"), we do not warrant, represent or guarantee in any way that this communication is free of malware or potentially damaging defects. All liability for any actual or alleged loss, damage, or injury arising out of or resulting in any way from the receipt, opening or use of this email is expressly disclaimed. _____________________________________________________________________

I had something similar migrating from 11.5.xxx to 12.1.xxx....Using PAM authentication for remote access resolve the issue. jp Josue Pierrot Database Administrator, Information Technology 82 Hopmeadow St, Simsbury, US O 8604082129 M 8609214920 F 8604082139 E jpierrot@chubb.com ACE and Chubb are now one. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Fernando Nunes Sent: Friday, September 16, 2016 11:16 AM To: ids@iiug.org Subject: Re: LDAP/NIS user cannot activate dbaccess [37836] It's hard to say if the problem is only on the engine side (where there is a problem for sure) or also from dbaccess also. A truss to the process could help.... Let's have an overview so that you can better understand what's happening. At first glance I'd expect a -951 error or eventually that it worked. If you're testing locally, you should try remotely... As Informix works a bit differently when authenticating locally. In the past (up to version 11.70FC3 or FC2) informix required all the users to be recognized by the underlying OS. Note that I'm trying to choose my words carefully as the devil is in the details... When I say "recognized" I mean a low level call to the getpwnam() function would retrieve the user details (UID, GID, password, home, etc.). Basically what traditionally was stored in /etc/passwd and /etc/shadow. Now... I'ts possible to have the OS responding to getpwnam() even for LDAP/NIS users. In some cases it may require special configurations. But even here you may face an issue with password authentication... Informix usually (there may be a few exceptions depending on version and platform) that the getpwnam() call returns the encrypted password. It then calls crypt() to encrypt the user provided password and checks if they're the same. But some recent LDAP servers consider the sending of the password (even in encrypted form) as a security flaw and they don't send it. Without it, Informix usually complains with error -952. In your case the fact that it hangs is a bit strange and would require further investigation. What would be the solution? Since version 11.70.FC3 (or FC2) a few improvements were made: 1- We can create database users 2- We can define "surrogate users" (to which OS account your external or database internal user will be mapped Additionally because of the getpwnanm issue you could consider PAM (with surrogate user mapping) I imagine you're more confused now than before you read this. I could try to explain better, but the fact is that this is a complex issue. You could open a PMR, or you could start by trying to connect remotely and see what happens. running trus/strace on dbaccess could give some more clues, but again, interpreting it requires some skills.... Regards. On Fri, Sep 16, 2016 at 3:17 PM, SAMEER SHARMA <sameersharma34@gmail.com> wrote: > Hi All, > > LDAP/NIS users which are not OS based are unable to use dbaccess command. > The > other OS users (informix) is able to connect to the database. I tried > login with LDAP user and set all the environment variables and tried > dbaccess, the command freezes and no output, no dbaccess screen no > error, nothing was there. > > I setup same environment for OS user and it worked. Please help to > sort this issue out. Your help is much appreciated. > > Thanks & Regards, > Sameer Sharma > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a113f6d5e84eb38053ca16fdc ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ____________________________________________________________________ This email (including any attachments) is intended for the designated recipient(s) only, and may be confidential, non-public, proprietary, and/or protected by the attorney-client or other privilege. Unauthorized reading, distribution, copying or other use of this communication is prohibited and may be unlawful. Receipt by anyone other than the intended recipient(s) should not be deemed a waiver of any privilege or protection. If you are not the intended recipient or if you believe that you have received this email in error, please notify the sender immediately and delete all copies from your computer system without reading, saving, printing, forwarding or using it in any manner. Although it has been checked for viruses and other malicious software ("malware"), we do not warrant, represent or guarantee in any way that this communication is free of malware or potentially damaging defects. All liability for any actual or alleged loss, damage, or injury arising out of or resulting in any way from the receipt, opening or use of this email is expressly disclaimed. _____________________________________________________________________