We want to look at the ACF2 - Linux PAM Support but are told this is in BETA. Is this the same as pam-acf2? Al Schilla State of Minnesota
-----Original Message----- From: David Boyes [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 9:34 AM To: [EMAIL PROTECTED] Subject: Re: Any looking at CA-ACF2? We've looked at it on a couple of occasions, and have opted against the ACF2 solution in favor of native Kerberos or Kerberos plus LDAP as a locator. At the time we looked at it, the VM version of ACF2 didn't support the LDAP interface very well (or at least the documentation was somewhat sparse), and most of our customers main authentication databases for distributed systems are not in ACF2 (exactly the scenario you posit in your note). Kerberos proved to be more scalable, and, once the learning curve was overcome, a lot more stable than the LDAP based solution (don't discount this for Kerberos -- it's non-trivial if you're used to simple userid/password schemes). I understand that the VM ACF2 has gotten a lot of work recently, and it's probably about time to look at it again, but now that we have the Kerberos stuff worked out, it's hard to see where going backward to LDAP would be a useful thing to do. LDAP isn't really intended for authentication, and it's painfully slow compared to Kerberos. The combination of the two (LDAP to find the right credential server, and Kerberos for the heavy lifting of the authentication) is a lot more scalable and functional. The pam_kerb4 and pam_kerb5 modules are already widely supported, and most Unixen grok Kerberos fairly well these days. I'd certainly argue that it's a major step up in security over LDAP, at the price of a fair amount of additional complexity (even the Windows guys bought a clue on this one...). Last comment: the Kerb/LDAP solution can be easily replicated on and off the box by multiple vendors, or by completely open-source alternatives. I really find the lock-in to a single-vendor solution to be a drawback. Do you *really* want to have no other options in case your ISV decides to jack up the support pricing? One thing that really needs to be done at some point is for some enterprising soul to write a VM DVM that plugs into the ESM interface and acts as a PAM client to a real external source. If this were done, then we'd have a lot more flexibility both for CMS and for Linux. Dunno how hard this would be, but it'd be really handy to be able to do things like totally Kerberize the CMS environment w/o major mods. -- db David Boyes Sine Nomine Associates > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Eric Sammons > Sent: Saturday, February 14, 2004 1:22 AM > To: [EMAIL PROTECTED] > 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 >
