[ Purposely changing this response to 303 ] On Wed, Sep 21, 2016 at 7:09 AM, Mark Clarke <m...@jumpingbean.co.za> wrote: > I wouldn't say NSS/389/Dogtag has been widely adopted outside RedHat yet > - it very well might be an emerging technology but its not something > every sys admin needs to know. If its included at an "awareness level" > then ok - but until it gets wide spread adoption, and mind share, I > can't agree that it should be covered in any more details.
Putting even "mixed environments" aside, and all that SSSD enables (for any LDAP, although most only use it with IPA), given the key Samba people involved with SSSD/IPA developments ... This final comment I cannot believe ... > To be frank I think there the coverage in 303 is overboard. The 303 Exam expends quite a lot of time on OpenLDAP replication, and other things. You say 389/IPA coverage in 303 is overboard. If I wanted to actually introduce "my opinion" (instead of just experience), I'd say OpenLDAP replication coverage is overboard. Anyone needing multi-master replication is using the iPlanet lineage ... and has been for 15+ years. ;) I.e., I cannot help "Linux enthusiasts" if they've never touched the iPlanet stack, and aren't familiar with its inherent multi-master replication. It's always been 2-way from day 1, then 4-way in version 6, and now 20-way in version 9 (aka 389 1.3). To be frank ... I honestly just wish "Linux enthusiasts" were aware that Netscape hired Howe, Good and Smith themselves from Michigan in 1996, and why. This also explains why there's been no release since 1996. ;) [1] For those of us who have managed not just the Certificate System, but even Gecko browser (Navigator, Mozilla, Firefox, et al.) attributes, even some GNOME, in iPlanet and other LDAP servers, it's obvious. Netscape wanted to manage both security, especially key, distribution as well as client attributes, in LDAP. Mind you this not only _pre-dates_ AD by 3 years (and OpenLDAP 2 years), but it is part of the reason _why_ Microsoft _also_ took the Michigan LDAP code too. It wasn't all just about Novell Directory Server / eDirectory, although that was a major reason. Microsoft was pushing MS IE hard, and even made it part of the core Windows library set in 1997. The reason? Microsoft too wanted to manage the clients in their future directory server too. Red Hat acquired all iPlanet assets in 2004. Red Hat releases as much source code as they could from iPlanet version 7.1 at the time, for anyone to use. Other distros didn't show any interest, despite multi-master replication and other things that OpenLDAP didn't have at the time. Red Hat also rewrote what they could not, and the resulting codebase became the "clean" and "100% open source" 389 codebase by 2005. Again, anyone could have adopted it, including Network Security Services (NSS), but no one did. I hinted why prior, a couple of other distros were pushing proprietary solutions at the time. One of the first things Red Hat first focused on was unifying Netscape libraries with OpenLDAP libraries, as the iPlanet lineage had a lot of Netscape libraries that had been developed _before_ OpenLDAP. The NSS (libnss) portion stayed separate from OpenSSL (libssl), especially since -- at the time -- the former had all sorts of US Government (e.g., FIPS) and Common Criteria certification, while the latter did not (Red Hat assisted with the latter). Next, would be a "canned" solution, which I've already talked about endlessly. It involves several key and core Samba maintainers to this day, who constantly contribute a lot of the SSSD code into Samba, such as for multi-domains, as SSSD has blown past the capabilities of Winbindd, let alone provides so much more. SSSD is really the "key component" to everything. As I often tell Windows AD architects, the SSSD is Linux's counterpart to the LSA in NT/Windows. It enables all sorts of capabilities, and is modular. This is where we are at in the 2010s. I haven't seen a corporate installation of _any_ distro without SSSD since 2013. I teach a lot of Debian and Ubuntu guys how to configure it, day-in, day-out. And when the comment comes up about how it should be "just a single command to configure" ... IPA naturally follows. IPA is nothing special. It's just a "canned" client-server solution of SSSD on the client side, and 389 et al. on the server. It's "canned," meaning inflexible, not a generic setup, but very, very 'tight,' just like AD. After all, Microsoft _too_ offers a _full_ LDAP server. It's called AD Lightweight Directory Services (LDS). But it's not 'canned.' And just like AD, you do _not_ have to know the first thing about LDAP or Kerberos to manage IPA. ;) -- bjs P.S. With Oracle's acquisition of Sun, Oracle finally deprecated the Sun One / iPlanet offerings. So the defacto standard of iPlanet is now 389, sold commercially as Red Hat Directory Server. It's 'sold separately' because managing a full LDAP server is costly, support-wise. Meanwhile, IPA (IdM) is "Free," even though it's the same 389 at the heart of IPA. It's not about the software. It's about the support costs. Debian has the full IPA Server now, has for nearly 2 years. The problem is the lack of people actually knowing it exists, just like 389, Dogtag and even SSSD too. [1] http://directory.fedoraproject.org/docs/389ds/FAQ/history.html -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me _______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
