Who supports the library?  I understand that CA has released for GA a
"z/Linux" version of what I call "the pam_acf2 library".  So clearly, or
perhaps CA will support that version but what about those shops that run
Windows Active Directory, Solaris, HP/UX, AIX, Linux IA32 and IA64?  If I
build it I support it?  What security vulnerabilities exist or is it too
early to say?  Why would I want to authenticate z/Linux differently than I
authenticate Solaris users?  Seems that is two different user management
systems I have to support?   I understand that LDAP for user
authentication has its limitations, but most folks then look to Kerberos
to address these.  How does pam_acf2 stack up against a pam_ldap and
Kerberos implementation?  And then I understand that the user information
and passwords would be stored in ACF/2.  If this the case are the security
policies dictated at the client (linux, solaris, aix) layer or at the
ACF/2 layer.  For example if ACF/2 doesn't allow the use of ! in the
password but Linux does which way works?

Finally, it reads that your pam_acf2 library supports both acf2 and ldap
backends?  Is this the case or did I mis-read?  If I read it correctly are
saying that your one single library will allow a system to authenticate to
either backend?

These are all questions that I am trying to get our security folks to
answer?

Thanks!
Eric Sammons
(804)697-3925
FRIT - Unix Systems





"Re, Vincent" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
02/14/2004 08:03 AM
Please respond to Linux on 390 Port

        To:     [EMAIL PROTECTED]
        cc:
        Subject:        Re: Any looking at CA-ACF2?

Hi Eric,

I'm the original designer of the CA PAM client for ACF2 and Top Secret. To
answer your questions, the source code for the PAM client is indeed
available - if you call the support team, they will be more than happy to
help you get it. Although our emphasis is Linux on zSeries computers, we
have tested the code on Linux Intel, and if you wanted to port it, we
believe that the code would run fine on any PAM platform.

As to our own PAM client versus LDAP, realize that our mainframe security
products support both, so you certainly have the choice of using either
approach - or even both in parallel (say, for different platforms). In the
specific case of authenticating Linux users, we believe there are
important performance, security and feature differences between the
two...LDAP is a bit of an awkward protocol for performing user
authentication, and our product-specific PAM architecture enables us to
have better performance and to implement some important security features
that aren't possible over LDAP.

Hope that's some help...

Vince Re
Sr. VP and Chief Architect
Computer Associates

                 -----Original Message-----
                 From: Linux on 390 Port on behalf of Eric Sammons
                 Sent: Sat 2/14/2004 1:22 AM
                 To: [EMAIL PROTECTED]
                 Cc:
                 Subject: Any looking at CA-ACF2?



                 Our security group is looking at CA-ACF2 and the pam_acf2
library offering
                 from CA.  There claim is that CA has committed to
releasing this source to
                 the open source community.  Thus far I have only seen a
white paper that
                 states it supports only Linux installs on the Z platform.
 I am arguing
                 that with wide acceptance and support this solution is
the wrong solution.
                  I have instead suggested that we go with an LDAP
pam_ldap.so solution.
                 Given our environment includes Most Unix platforms
available to the masses
                 and that z/Linux is only just now breaking ground in our
environment the
                 CA-ACF2 pam library solution is not the best solution.
How our security
                 group opts to secure VM is really of no concern to me,
CA-ACF2 at this
                 layer is fine with me, it is the pam_acf2 library that
concerns me.

                 Has anyone else looked at this solution?  Any thoughts?
Any ideas how to
                 argue against and provide a stronger case?

                 Thanks!
                 Eric Sammons

Reply via email to