Re: LDAP Errors
Mark, do you have a link to this redpaper? |-+ | | Post, Mark K | | | [EMAIL PROTECTED]| | | m | | | Sent by: Linux on| | | 390 Port | | | [EMAIL PROTECTED]| | | IST.EDU | | || | || | | 07/18/2002 09:02 | | | AM | | | Please respond to| | | Linux on 390 Port| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: LDAP Errors | --| Peter, I've just about finished working my way through the IBM Redpaper Securing Linux for zSeries with a Central z/OS (RACF) LDAP Server. They talk about most, if not all, of your issues. RACF also does a one-way encryption of passwords. The RACF/LDAP combination also does not allow an anonymous bind, requiring the use of a dummy userid. They were using PAM to do this, along with NSS (Name Service Switch), to do both password verification, and to store other attributes, such as UID, GID, home directory, default shell, etc. I highly recommend reading it. I'm just about to embark on a similar experiment with ACF2. What version of the LDAP server were you testing? Mark Post -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 9:03 AM To: [EMAIL PROTECTED] Subject: Re: LDAP Errors OK,,,here is my status concerning using CA-LDAP to authenticate Linux users to z/OS. It is not going to happen. The ldapseach and other ldap client commands work fine with simple authentication (-x). However, it is PAM that presents the problem with CA-LDAP. The claim from Computer Associates that CA-LDAP can seamlessly function as a full LDAP authentication server for the enterprise is somewhat misleading. I talked to CA in great lengths concerning this. Here is what I found out. CA-LDAP does not really support anonymous binds. Anonymous binds can appear to work but CA-LDAP will never return any information. Using an ID and password will get around the anonymous binds but then it came down to differences with the ACF2 LDAP format. Trying to use PAM for RLOGIN revealed that PAM was basically issuing an LDAPSEARCH in an attempt to extract the password, I assumed to be use for comparison. ACF2 passwords use one-way encryption that can never be decrypted to match the password that PAM knows about. There were other problems as well, such as the UFNs of the ACF2 attributes that did not lend themselves to OPENLDAP. Back to the claim that CA-LDAP can act as an authentication server. To authenticate a user, a bind must be issued to CA-LDAP containing the userid and password. This will work. However, I could not find any LDAP client commands to perform just a bind. I know the bind works because I must specify a userid and password with other LDAP client commands. CA recommends that I will have to developed code and/or modify PAM code to accommodate CA-LDAP. I am an ALC programmer and do not know much about C. I will take a peak and see what is involved. CA also told me that they are working on CA-LDAP PAM code for Linux but no particulars could be extracted. It appears it might be available with CA-ACF2 V6.5. This has been a major blow for our Linux evaluation. Our original intention was to demonstrate to management that there was not going to be any significant administration overhead with managing additional Linux security. There are already way too many ID and passwords in our shop. We have z/OS, email, LAN, servers, WEB? etc IDs and passwords to remember and administer. This will have to be another layer, at least for now. I know, we can still implement OPENLDAP, but this will be a major undertaking, especially with legacy systems. I pass this along to any other ACF2 customers who might be thinking of undertaking the same project. I also pass it along to solicit comments, suggestions, and alternative from the extreme knowledge base that makes up this forum. I do not know if this applies to RACF
Re: LDAP Errors
I was using the most recent version. The ACF2 version is officially called eTrust LDAP Server for OS/390 and z/OSversion 2.0 Where can I find the IBM Redpaper. Thanks. Peter Post, Mark K [EMAIL PROTECTED] Sent by: Linux on 390 Port [EMAIL PROTECTED] 07/18/2002 10:02 AM Please respond to Linux on 390 Port To: [EMAIL PROTECTED] cc: Subject:Re: LDAP Errors Peter, I've just about finished working my way through the IBM Redpaper Securing Linux for zSeries with a Central z/OS (RACF) LDAP Server. They talk about most, if not all, of your issues. RACF also does a one-way encryption of passwords. The RACF/LDAP combination also does not allow an anonymous bind, requiring the use of a dummy userid. They were using PAM to do this, along with NSS (Name Service Switch), to do both password verification, and to store other attributes, such as UID, GID, home directory, default shell, etc. I highly recommend reading it. I'm just about to embark on a similar experiment with ACF2. What version of the LDAP server were you testing? Mark Post -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 9:03 AM To: [EMAIL PROTECTED] Subject: Re: LDAP Errors OK,,,here is my status concerning using CA-LDAP to authenticate Linux users to z/OS. It is not going to happen. The ldapseach and other ldap client commands work fine with simple authentication (-x). However, it is PAM that presents the problem with CA-LDAP. The claim from Computer Associates that CA-LDAP can seamlessly function as a full LDAP authentication server for the enterprise is somewhat misleading. I talked to CA in great lengths concerning this. Here is what I found out. CA-LDAP does not really support anonymous binds. Anonymous binds can appear to work but CA-LDAP will never return any information. Using an ID and password will get around the anonymous binds but then it came down to differences with the ACF2 LDAP format. Trying to use PAM for RLOGIN revealed that PAM was basically issuing an LDAPSEARCH in an attempt to extract the password, I assumed to be use for comparison. ACF2 passwords use one-way encryption that can never be decrypted to match the password that PAM knows about. There were other problems as well, such as the UFNs of the ACF2 attributes that did not lend themselves to OPENLDAP. Back to the claim that CA-LDAP can act as an authentication server. To authenticate a user, a bind must be issued to CA-LDAP containing the userid and password. This will work. However, I could not find any LDAP client commands to perform just a bind. I know the bind works because I must specify a userid and password with other LDAP client commands. CA recommends that I will have to developed code and/or modify PAM code to accommodate CA-LDAP. I am an ALC programmer and do not know much about C. I will take a peak and see what is involved. CA also told me that they are working on CA-LDAP PAM code for Linux but no particulars could be extracted. It appears it might be available with CA-ACF2 V6.5. This has been a major blow for our Linux evaluation. Our original intention was to demonstrate to management that there was not going to be any significant administration overhead with managing additional Linux security. There are already way too many ID and passwords in our shop. We have z/OS, email, LAN, servers, WEB? etc IDs and passwords to remember and administer. This will have to be another layer, at least for now. I know, we can still implement OPENLDAP, but this will be a major undertaking, especially with legacy systems. I pass this along to any other ACF2 customers who might be thinking of undertaking the same project. I also pass it along to solicit comments, suggestions, and alternative from the extreme knowledge base that makes up this forum. I do not know if this applies to RACF. Thanks to all that provided input. Peter E. Abresch Jr.
Re: LDAP Errors
From http://linuxvm.org/ : 06/23/2002 - Jim Elliott published the URLs to three new IBM Redpapers. The titles are: Getting Started with zSeries Fibre Channel Protocol Linux on IBM zSeries and S/390: High Availability for z/VM and Linux Linux on IBM zSeries and S/390: Securing Linux for zSeries with a Central z/OS LDAP Server (RACF) http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpaperAbstracts/redp0205.html http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpaperAbstracts/redp0220.html http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpaperAbstracts/redp0221.html Mark Post -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 10:26 AM To: [EMAIL PROTECTED] Subject: Re: LDAP Errors I was using the most recent version. The ACF2 version is officially called eTrust LDAP Server for OS/390 and z/OSversion 2.0 Where can I find the IBM Redpaper. Thanks. Peter Post, Mark K [EMAIL PROTECTED] Sent by: Linux on 390 Port [EMAIL PROTECTED] 07/18/2002 10:02 AM Please respond to Linux on 390 Port To: [EMAIL PROTECTED] cc: Subject:Re: LDAP Errors Peter, I've just about finished working my way through the IBM Redpaper Securing Linux for zSeries with a Central z/OS (RACF) LDAP Server. They talk about most, if not all, of your issues. RACF also does a one-way encryption of passwords. The RACF/LDAP combination also does not allow an anonymous bind, requiring the use of a dummy userid. They were using PAM to do this, along with NSS (Name Service Switch), to do both password verification, and to store other attributes, such as UID, GID, home directory, default shell, etc. I highly recommend reading it. I'm just about to embark on a similar experiment with ACF2. What version of the LDAP server were you testing? Mark Post -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 9:03 AM To: [EMAIL PROTECTED] Subject: Re: LDAP Errors OK,,,here is my status concerning using CA-LDAP to authenticate Linux users to z/OS. It is not going to happen. The ldapseach and other ldap client commands work fine with simple authentication (-x). However, it is PAM that presents the problem with CA-LDAP. The claim from Computer Associates that CA-LDAP can seamlessly function as a full LDAP authentication server for the enterprise is somewhat misleading. I talked to CA in great lengths concerning this. Here is what I found out. CA-LDAP does not really support anonymous binds. Anonymous binds can appear to work but CA-LDAP will never return any information. Using an ID and password will get around the anonymous binds but then it came down to differences with the ACF2 LDAP format. Trying to use PAM for RLOGIN revealed that PAM was basically issuing an LDAPSEARCH in an attempt to extract the password, I assumed to be use for comparison. ACF2 passwords use one-way encryption that can never be decrypted to match the password that PAM knows about. There were other problems as well, such as the UFNs of the ACF2 attributes that did not lend themselves to OPENLDAP. Back to the claim that CA-LDAP can act as an authentication server. To authenticate a user, a bind must be issued to CA-LDAP containing the userid and password. This will work. However, I could not find any LDAP client commands to perform just a bind. I know the bind works because I must specify a userid and password with other LDAP client commands. CA recommends that I will have to developed code and/or modify PAM code to accommodate CA-LDAP. I am an ALC programmer and do not know much about C. I will take a peak and see what is involved. CA also told me that they are working on CA-LDAP PAM code for Linux but no particulars could be extracted. It appears it might be available with CA-ACF2 V6.5. This has been a major blow for our Linux evaluation. Our original intention was to demonstrate to management that there was not going to be any significant administration overhead with managing additional Linux security. There are already way too many ID and passwords in our shop. We have z/OS, email, LAN, servers, WEB? etc IDs and passwords to remember and administer. This will have to be another layer, at least for now. I know, we can still implement OPENLDAP, but this will be a major undertaking, especially with legacy systems. I pass this along to any other ACF2 customers who might be thinking of undertaking the same project. I also pass it along to solicit comments, suggestions, and alternative from the extreme knowledge base that makes up this forum. I do not know if this applies to RACF. Thanks to all that provided input. Peter E. Abresch Jr.
Re: LDAP Errors
OK,,,here is my status concerning using CA-LDAP to authenticate Linux users to z/OS. It is not going to happen. The ldapseach and other ldap client commands work fine with simple authentication (-x). However, it is PAM that presents the problem with CA-LDAP. The claim from Computer Associates that CA-LDAP can seamlessly function as a full LDAP authentication server for the enterprise is somewhat misleading. I talked to CA in great lengths concerning this. Here is what I found out. CA-LDAP does not really support anonymous binds. Anonymous binds can appear to work but CA-LDAP will never return any information. Using an ID and password will get around the anonymous binds but then it came down to differences with the ACF2 LDAP format. Trying to use PAM for RLOGIN revealed that PAM was basically issuing an LDAPSEARCH in an attempt to extract the password, I assumed to be use for comparison. ACF2 passwords use one-way encryption that can never be decrypted to match the password that PAM knows about. There were other problems as well, such as the UFNs of the ACF2 attributes that did not lend themselves to OPENLDAP. Back to the claim that CA-LDAP can act as an authentication server. To authenticate a user, a bind must be issued to CA-LDAP containing the userid and password. This will work. However, I could not find any LDAP client commands to perform just a bind. I know the bind works because I must specify a userid and password with other LDAP client commands. CA recommends that I will have to developed code and/or modify PAM code to accommodate CA-LDAP. I am an ALC programmer and do not know much about C. I will take a peak and see what is involved. CA also told me that they are working on CA-LDAP PAM code for Linux but no particulars could be extracted. It appears it might be available with CA-ACF2 V6.5. This has been a major blow for our Linux evaluation. Our original intention was to demonstrate to management that there was not going to be any significant administration overhead with managing additional Linux security. There are already way too many ID and passwords in our shop. We have z/OS, email, LAN, servers, WEB? etc IDs and passwords to remember and administer. This will have to be another layer, at least for now. I know, we can still implement OPENLDAP, but this will be a major undertaking, especially with legacy systems. I pass this along to any other ACF2 customers who might be thinking of undertaking the same project. I also pass it along to solicit comments, suggestions, and alternative from the extreme knowledge base that makes up this forum. I do not know if this applies to RACF. Thanks to all that provided input. Peter E. Abresch Jr.
Re: LDAP Errors
Peter, I would say that those errors are going to prevent you from working. What the messages mean is that rlogind is trying to use the shared library libdigestmd5.so to dynamically load a routine, and can't find it: des_key_sched. On top of that, it's trying to find an entire library, libgssapi.so.1, and cannot. Mark Post -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: LDAP Errors I am still trying to get PAM working with Computer Associates LDAP server. I want to authenticate Linux users against ACF2. Right now I am playing with just RLOGIN just to try to get something working. I am not having much luck. I am seeing the following in the Linux logs. Jun 6 10:31:47 ibm9672 in.rlogind[3902]: connect from 161.186.86.6 (161.186.86.6) Jun 6 10:32:10 ibm9672 rlogind[3902]: unable to dlopen /usr/lib/sasl/libdigestmd5.so: /usr/lib/sasl/libdigestmd5.so: undefined symbol: des_key_sched Jun 6 10:32:10 ibm9672 rlogind[3902]: unable to dlopen /usr/lib/sasl/libgssapiv2.so: libgssapi.so.1: cannot load shared object file: No such file or directory Jun 6 10:32:10 ibm9672 pam_rhosts_auth[3902]: denied to [EMAIL PROTECTED] as x062pea: access not allowed Jun 6 10:32:10 ibm9672 in.rlogind[3902]: PAM authentication failed for in.rlogind I do not know what the 2 unable to dlopen messages means nor how to correct it. I do not know if this is the cause of my problems or not. Also, if anyone can provide any pointers on using CA-ACF2 LDAP for password authentication, I will be much appreciative. Thanks to all. Peter E. Abresch Jr.
Re: LDAP Errors
Thanks, where do I go from here. I see those modules on the system? Peter Post, Mark K [EMAIL PROTECTED] Sent by: Linux on 390 Port [EMAIL PROTECTED] 06/06/2002 01:57 PM Please respond to Linux on 390 Port To: [EMAIL PROTECTED] cc: Subject:Re: LDAP Errors Peter, I would say that those errors are going to prevent you from working. What the messages mean is that rlogind is trying to use the shared library libdigestmd5.so to dynamically load a routine, and can't find it: des_key_sched. On top of that, it's trying to find an entire library, libgssapi.so.1, and cannot. Mark Post -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: LDAP Errors I am still trying to get PAM working with Computer Associates LDAP server. I want to authenticate Linux users against ACF2. Right now I am playing with just RLOGIN just to try to get something working. I am not having much luck. I am seeing the following in the Linux logs. Jun 6 10:31:47 ibm9672 in.rlogind[3902]: connect from 161.186.86.6 (161.186.86.6) Jun 6 10:32:10 ibm9672 rlogind[3902]: unable to dlopen /usr/lib/sasl/libdigestmd5.so: /usr/lib/sasl/libdigestmd5.so: undefined symbol: des_key_sched Jun 6 10:32:10 ibm9672 rlogind[3902]: unable to dlopen /usr/lib/sasl/libgssapiv2.so: libgssapi.so.1: cannot load shared object file: No such file or directory Jun 6 10:32:10 ibm9672 pam_rhosts_auth[3902]: denied to [EMAIL PROTECTED] as x062pea: access not allowed Jun 6 10:32:10 ibm9672 in.rlogind[3902]: PAM authentication failed for in.rlogind I do not know what the 2 unable to dlopen messages means nor how to correct it. I do not know if this is the cause of my problems or not. Also, if anyone can provide any pointers on using CA-ACF2 LDAP for password authentication, I will be much appreciative. Thanks to all. Peter E. Abresch Jr.
Re: LDAP Errors
On Thu, 2002-06-06 at 16:00, Peter E. Abresch Jr. - at Pepco wrote: I do not know what the 2 unable to dlopen messages means nor how to correct it. I do not know if this is the cause of my problems or not. Unix speak for Where has that .DLL file gone
Re: LDAP Errors
On Thu, 6 Jun 2002, Peter E. Abresch Jr. - at Pepco wrote: I am still trying to get PAM working with Computer Associates LDAP server. I want to authenticate Linux users against ACF2. Right now I am playing with just RLOGIN just to try to get something working. I am not having much luck. I am seeing the following in the Linux logs. Jun 6 10:31:47 ibm9672 in.rlogind[3902]: connect from 161.186.86.6 (161.186.86.6) Jun 6 10:32:10 ibm9672 rlogind[3902]: unable to dlopen /usr/lib/sasl/libdigestmd5.so: /usr/lib/sasl/libdigestmd5.so: undefined symbol: des_key_sched Jun 6 10:32:10 ibm9672 rlogind[3902]: unable to dlopen /usr/lib/sasl/libgssapiv2.so: libgssapi.so.1: cannot load shared object file: No such file or directory Jun 6 10:32:10 ibm9672 pam_rhosts_auth[3902]: denied to [EMAIL PROTECTED] as x062pea: access not allowed Jun 6 10:32:10 ibm9672 in.rlogind[3902]: PAM authentication failed for in.rlogind I do not know what the 2 unable to dlopen messages means nor how to correct it. I do not know if this is the cause of my problems or not. Also, if anyone can provide any pointers on using CA-ACF2 LDAP for password authentication, I will be much appreciative. Thanks to all. I don't know exactly what is going on here, but maybe some of my experiences might put you in the right direction. Most ldap tools in Linux are based on the OpenLDAP project. And the OpenLDAP project includes a couple of ways to authenticate yourself with the ldap server. I'm going to explain it using ldapsearch, which it a good tool to first test your connections and search filters. The first way to authenticate yourself to the ldap server is using sasl, and this is the default on openldap. You can see that the missing lib are from the sasl package. The problem is that, AFAIK, only OpenLDAP servers understand the sasl way of authenticating. Therefore for all other ldap server you need to use the simple authentication method. In ldapsearch you add the -x swith for this. Then using other swithes you can supply the necesary id's and passwords. So maybe you can first try with ldapsearch how exactly you have to connect to your ldap server. I also don't know the pam ldap modules so I can't tell you how to configure those. But still I hope that I was of help. Regards, Tim Verhoeven -- === Tim Verhoeven Linux Open Source Specialist GSM : 0496 / 693 453 + e-business solutions Email : [EMAIL PROTECTED] + consulting URL : www.sin.khk.be/~dj/ + Server consolidation ===
