OLEDB connection and AD Windows
Posted in 2008
Asker wanted IDS 10 on Linux to authenticate Windows/Active Directory users via PAM so local UNIX accounts wouldn't have to be duplicated, but IBM support said OLE DB (plus some other clients/tools) doesn't support PAM, so those connections fail. Fernando Nunes suggested skipping IDS-side PAM and instead configuring the OS (nsswitch.conf/LDAP) so getpwnam resolves AD users, letting IDS authenticate normally. Richard Spitz reported that this didn't work for him: once IDS is configured with PAM in sqlhosts it rejects clients not sending the CLNT_PAM_CAPABLE flag, and he reverted to NIS against the AD PDC while awaiting fixes for defects idsdb00094077/idsdb00152409. No confirmed resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Connectivity: ODBC / JDBC / .NET, Connectivity: ESQL/C, 4GL & Embedded SQL
Work Enviroment: Data Server: * IDS v10.00.FC1 * RedHat 4.??? 64 bits (?Itaniun) (Kernel 2.6.9-34EL) Clients: * Windows with different versions(CLI-SDK 2.90.FC1, CLI-SDK 3.0, .....) * We are working with 4GL (with 4J's),asp,aspx,.net,VB 6.0,... Our users logon in their PCs against an Active Directory Server with Windows 2003. To connect the database, we have created local users in the server with the same name that our users have in the domain. We would like to configure our dataserver so that our users authenticate in the server with their domain (AD) user, no needing the local user. We do this with PAM. We connect the O.S. but in some cases (for example OLEDB) the server is not able to connect with IDS. We opened a ticket in the IBM and the answer was: ************************************************************************ ******************** The following client APIs, tools and applications do not support PAM or LDAP Authentication Support modules: LibC++ Libdmi OLEDB VB Applications using ODBC Ilogin, dbping and ODBC Test connection ISA As sometimes we are using OLEDB, we would need to duplicate again the users, something that we don't like. I guess some informix users will have had this problem and that's why we are asking for some help. Any solution? Thank you in advanced
Fernandez Garcia, Domingo wrote: > Work Enviroment: > > > > Data Server: > > * IDS v10.00.FC1 > > * RedHat 4.??? 64 bits (?Itaniun) (Kernel 2.6.9-34EL) > > > > Clients: > > * Windows with different versions(CLI-SDK 2.90.FC1, CLI-SDK 3.0, '..) > > * We are working with 4GL (with 4J's),asp,aspx,.net,VB 6.0,... > > > > Our users logon in their PCs against an Active Directory Server with > Windows 2003. > > > > To connect the database, we have created local users in the server with > the same name that our users have in the domain. > > > > We would like to configure our dataserver so that our users authenticate > in the server with their domain (AD) user, no needing the local user. We > do this with PAM. We connect the O.S. but in some cases (for example > OLEDB) the server is not able to connect with IDS. > > > > We opened a ticket in the IBM and the answer was: > > > > ******************************************************************************************** > > The following client APIs, tools and applications do not support PAM or > LDAP Authentication Support modules: > > LibC++ > > Libdmi > > OLEDB > > VB Applications using ODBC > > Ilogin, dbping and ODBC Test connection ISA > > > > As sometimes we are using OLEDB, we would need to duplicate again the > users, something that we don't like. > > > > I guess some informix users will have had this problem and that's why we > are asking for some help. > > > > Any solution? > > Thank you in advanced > > > You have one simple solution... Configure RH to authenticate through PAM. This will make your users known to the OS. After that IDS should be able to authenticate (without using PAM). I'm not sure if this is the case, but there is a misconception that IDS checks /etc/passwd or /etc/shadow... This is not true... IDS uses OS functions. If your OS system can get the user data from AD, it's fine for IDS. Maybe one of the architects can correct me if I'm wrong...? But I recently did some tests that showed this... It can be a problem to configure your OS to do this... While doing it I was almost locked out of the system... But It's perfectly ok to do it in a VMware type of environment... I think some people may be trying to use IDS with PAM in situations where they could just set the OS (with PAM) and let IDS do the normal stuff... There are things to be gained from PAM, but it may not be necessary to go that way... Note: the info you got about IDS bugs may be relevant... I didn't check the problems mentioned and also 10.00.FC1 may be "old"... You may encounter issues solved in newer versions... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
Fernando Nunes <spam@onlinedomus.net> schrieb: >Fernandez Garcia, Domingo wrote: >> We would like to configure our dataserver so that our users authenticate >> in the server with their domain (AD) user, no needing the local user. We >> do this with PAM. We connect the O.S. but in some cases (for example >> OLEDB) the server is not able to connect with IDS. >You have one simple solution... Configure RH to authenticate through PAM. This >will make your users known to the OS. After that IDS should be able to >authenticate (without using PAM). > >I'm not sure if this is the case, but there is a misconception that IDS checks >/etc/passwd or /etc/shadow... This is not true... IDS uses OS functions. If >your OS system can get the user data from AD, it's fine for IDS. I had the same misconception and failed. IIRC, IDS uses the "classic" libc functions for user authentication (getpwnam() etc.) which do not support PAM. So even if the OS is configured for using PAM for user authentication, IDS cannot make use of this. And if IDS is configured for PAM, OLEDB fails. We are in the same situation as Domingo and, for the time being, had to live with the defects that Shesh posted. Since we cannot do without OLEDB, we had to switch back to using NIS, which we had been running for years. The NIS server is our AD PDC, so we do not have to redefine local unix users on our IDS database server running under Linux. I do know about the disadvantages of NIS, and as soon as the defects are fixed (due sometime around August 2008, as I was told by tech support) we will have another go at PAM. Regards, Richard
Richard Spitz wrote: > Fernando Nunes <spam@onlinedomus.net> schrieb: > >> Fernandez Garcia, Domingo wrote: >>> We would like to configure our dataserver so that our users authenticate >>> in the server with their domain (AD) user, no needing the local user. We >>> do this with PAM. We connect the O.S. but in some cases (for example >>> OLEDB) the server is not able to connect with IDS. > >> You have one simple solution... Configure RH to authenticate through PAM. This >> will make your users known to the OS. After that IDS should be able to >> authenticate (without using PAM). >> >> I'm not sure if this is the case, but there is a misconception that IDS checks >> /etc/passwd or /etc/shadow... This is not true... IDS uses OS functions. If >> your OS system can get the user data from AD, it's fine for IDS. > > I had the same misconception and failed. IIRC, IDS uses the "classic" libc > functions for user authentication (getpwnam() etc.) which do not support PAM. > So even if the OS is configured for using PAM for user authentication, IDS > cannot make use of this. And if IDS is configured for PAM, OLEDB fails. > > We are in the same situation as Domingo and, for the time being, had to live > with the defects that Shesh posted. Since we cannot do without OLEDB, we had > to switch back to using NIS, which we had been running for years. The NIS > server is our AD PDC, so we do not have to redefine local unix users on our > IDS database server running under Linux. > > I do know about the disadvantages of NIS, and as soon as the defects are fixed > (due sometime around August 2008, as I was told by tech support) we will have > another go at PAM. > > Regards, Richard As I wrote in another article, I could get Linux using PAM and getpwnam worked as well as IDS. I'd love to write more about this but in the next few weeks it will be completely impossible for me... My test setup included an Openldap server and Fedora (core 5?). IIRC I had to change /etc/nsswitch.conf... This can be used to specify that the users can be retrived from an LDAP server... If someone has the time, the will and the knowledge to do some research I can comment and possibly try to check my config files... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
On 7 Apr, 08:43, Richard Spitz <Richard.Sp...@med.uni-muenchen.de> wrote: > Fernando Nunes <s...@onlinedomus.net> schrieb: > > >Fernandez Garcia, Domingo wrote: > >> We would like to configure our dataserver so that our users authenticate > >> in the server with their domain (AD) user, no needing the local user. We > >> do this with PAM. We connect the O.S. but in some cases (for example > >> OLEDB) the server is not able to connect with IDS. > >You have one simple solution... Configure RH to authenticate through PAM. This > >will make your users known to the OS. After that IDS should be able to > >authenticate (without using PAM). > > >I'm not sure if this is the case, but there is a misconception that IDS checks > >/etc/passwd or /etc/shadow... This is not true... IDS uses OS functions. If > >your OS system can get the user data from AD, it's fine for IDS. > > I had the same misconception and failed. IIRC, IDS uses the "classic" libc > functions for user authentication (getpwnam() etc.) which do not support PAM. > So even if the OS is configured for using PAM for user authentication, IDS > cannot make use of this. And if IDS is configured for PAM, OLEDB fails. > > We are in the same situation as Domingo and, for the time being, had to live > with the defects that Shesh posted. Since we cannot do without OLEDB, we had > to switch back to using NIS, which we had been running for years. The NIS > server is our AD PDC, so we do not have to redefine local unix users on our > IDS database server running under Linux. > > I do know about the disadvantages of NIS, and as soon as the defects are fixed > (due sometime around August 2008, as I was told by tech support) we will have > another go at PAM. > > Regards, Richard What defects? Do you have APAR numbers?
"david@smooth1.co.uk" <david@smooth1.co.uk> schrieb: >What defects? Do you have APAR numbers? See the posting by Sheshnarayan Agrawal from IBM India in this thread. He mentioned defects idsdb00094077 and idsdb00152409. I don't know if there are corresponding APAR numbers. Regards, Richard
Fernando Nunes <spam@onlinedomus.net> schrieb: >As I wrote in another article, I could get Linux using PAM and getpwnam worked >as well as IDS. But did you get successful OLEDB connections in your setup? I'd be surprised if you did! Did you configure the PAM additions in the sqlhosts file (e.g. the pam_serv and pamauth parameters) or not? >My test setup included an Openldap server and Fedora (core 5?). >IIRC I had to change /etc/nsswitch.conf... This can be used to specify that the >users can be retrived from an LDAP server... This is a prerequisite anyway to get the OS itself to authenticate against an LDAP server using PAM, and has nothing to do with IDS. When IDS is configured for using PAM, client connections that are not explicitly PAM enabled fail. The docs are very clear about this: The Informix OLEDB driver does not support PAM. The problem seems to be that there is really nothing special about PAM authentication as long as the simple "password" method is used and not the "challenge" method which requires the client to implement a callback function. However, IDS refuses to authenticate a client that does not send the "CLNT_PAM_CAPABLE" flag, even when no special PAM functions are necessary. Regards, Richard