[ 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
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+
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. ;) 
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
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
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. ;)
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.
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