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.
