>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/OS version 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.
