On Sun, Mar 13, 2022 at 4:33 PM Markus Schade via lpi-examdev < [email protected]> wrote:
> Am 07.03.2022 um 17:39 schrieb Justin Keller via lpi-examdev: > >> Both SUSE and Red Had have replaced OpenLDAP with 389 DS. Shall we do > the same in 210.4 ? > Just to clarify on Red Hat, and I know this gets confusing, hence this e-mail. HINT: Compliance is Red Hat's primary focus, after 100% GPL (and MPL as required) code first'n foremost. [A] RE: 389 DS - Netscape libs gone - 389 DS [A] uses virtually no legacy Netscape libraries, sans Security Services (NSS, libnss), in addition to OpenSSL (libssl) - OpenLDAP libs - 389 DS uses only OpenLDAP libraries as much as possible (nearly all) - OpenLDAP clients - 389 DS uses OpenLDAP clients by default (even if it's backwards compatible with some Netscape tooling) - OpenLDAP server - Red Hat ships, but does *not* support, openssl-server package ... with exceptions [B] - Has Own License - Red Hat does *not* support 'raw' 389 DS without an added, costly subscription [C] RE: SSSD (v. Legacy) - SSSD has become the defacto NSS/PAM replacement for legacy NSS/PAM solutions that used OpenLDAP libraries prior, and is built with OpenLDAP, but with 389 DS code and capabilities (e.g., pam_ldap and pam_krb5 are really legacy with known issues), which is why other distros 'took awhile' to get 'on-board' with SSSD, especially since it's like an 'NT Local Security Authority (LSA) equivalent module/security service provider' approach that does IPA by default (like LSA does ActiveDirectory), but is modular and can support all sorts of solutions. [D] RE: IPA (Enterprise IdM) - 389 DS is for IPA - 389 DS included with Fedora (RHEL) is largely for IPA (Enterprise IdM) support, which is *free*, and uses 389, Dogtag [A], MIT Kerberos, BIND, et al. as an 'ActiveDirectory equivalent 'domain' approach for IETF RFC2307bis POSIX attributes' [C] Understand Red Hat really wants people to use IPA (Enterprise IdM), *not* 'raw' 389 DS. [C] Red Hat also expects everyone to be on SSSD for compliance reasons. [D] Debian/Ubuntu packages exist, but OpenLDAP still seems to be the primary > choice. I wouldn't drop it just yet. > OpenLDAP knowledge is still required for 389 DS and, to a lesser extent, IPA. OpenLDAP clients and libraries are used, and its base schema is still largely usable. But if we're going to get into the deeper end of 'service' configuration, then that's where I start 'putting my foot down.' I.e., for Enterprise usage, there's a reason why 389 DS (and IPA) is popular, just like iPlanet before it, was extremely popular. E.g., Mutli-master replication is built-in. [A] That said ... OpenLDAP Server does still have its uses for non-system objects, like application LDAP trees ... although so does 389 DS (non-IPA). [B] - bjs NOTES: *[A] 389 DS = Open Source LDAP with inherent, Multi-Master Support* After starting a project to modify OpenLDAP to add multi-master replication in the early '00s, Red Hat had the opportunity to acquire all remnants of Netscape/iPlanet Directory Server from AOL-Netscape for low 8 figures USD, and subsequently did so in 2004. They spent almost a year open sourcing it as 389 DS 1.0 in 2005, and is considered iPlanet v8 from the 'commercial' standpoint (as the Red Hat Directory Server v8 product), and included the (up to) 4 Multi-master support. This is why iPlanet was considered the 'Gold Standard' for Enterprises, especially since it was the first, commercial LDAP solution. I.e., just like Netscape hired many Mosaic developers from Chicago, they also hired many LDAPv3 developers from Michigan, as they tied Navigator/Communicator policies/profiles to an Enterprise LDAP store they first released in 1996. SIDE NOTE: This is also where Microsoft also got the idea for centralized policy storage in ActiveDirectory's LDAP too. Red Hat purposely removed as much reliance on Netscape libraries, and used OpenLDAP libraries instead ... with some exceptions, like Netscape Security Services (NSS) library (libnss), which has some major compliance advantages over OpenSSL library (libssl) ... at least originally (OpenSSL has improved thanks to some Red Hat and other contributions). Some components couldn't be open sourced (3rd party closed source licensing), so portions were either abandoned or re-written -- e.g., [Fedora] LDAP Admin GUI. The Netscape Certificate System was 'split off,' from LDAP, as the Dogtag Project. 389 DS 1.2 added support for (up to) 20 Multi-masters, and that was a new feature in iPlanet v9. Since Oracle-Sun abandoned their Sun One product's iPlanet support by that time, Red Hat Directory Server v9 is really the only iPlanet implementation left. 389 DS 1.3 became v10, etc... *[B] Red Hat shipping, but not supporting, the RPM openldap-server as an OS-level directory store* Red Hat still ships the RPM openldap-server package in RHEL, but does not support it as an OS-level directory store. This is because Red Hat only wants to support either IPA (RHEL Built-in Enterprise IdM) or, in the fallback case, *'raw' *389 DS (RHEL add-on Red Hat Directory Server) -- see [C]. I.e., in RHEL8+, openldap-server is now in the 'Code Ready' repository (neither Base OS nor Application Stream channels), which is geared more towards developers, like application and other services. E.g., openldap-server still makes a great, albeit more standalone, LDAP store for application-level objects. *[C] Superset IPA is 'free' with RHEL, Subset 389 DS is not* This seems to be a misnomer at first, because IPA -- which is a superset of 389 DS + all sorts of other components -- is included as the RHEL 'built-in' Enterprise IdM, while 389 DS is a RHEL add-on called Red Hat Directory Server (RHDS). Why? Support costs. I.e., a 'raw' 389 DS (RHDS) LDAP is a PITA to manage. IPA is, like ActiveDirectory, 95% manageable from a GUI. ;) IPA is honestly cake to administer, full GUI, while still backwards compatible as a generic, even legacy, LDAP, Kerberos, Certificate, DNS, etc... service. It's designed to be 'as easy' to use as ActiveDirectory. But unlike ActiveDirectory, which uses NT/LAN Manager attributes and RPC services, IPA is for POSIX (UNIX/Linux) systems out-of-the-box, with advanced features for GNU/Linux platforms like policies and auditing (hence: Identity, Policy, Audit ==> IPA). Again, compliance has pushed Red Hat to nuke pam_ldap and pam_krb5 from RHEL8+. There are ways to interject local SSSD with attributes from an IPA server, such as ID Mapping overrides (specific for that system). Once you go IPA, you never go back ... ever. ;) *[D] SSSD is Required for Compliance Reasons* The System Security Services Daemon (SSSD) brought in a lot of Netscape 389 DS and other services ... from the client side (e.g., policy objects support), although it's been largely re-written to use OpenLDAP libraries (including additives by Red Hat). I could write a book on it, so I'll skip those details. Although IPA requires SSSD, just like AD requires NT's Local Security Authority (LSA). But just like the NT LSA, which has Security Service Providers (SSPs) to work with other facilities, SSSD offers countless modules, which then come through its PAM (e.g., pam_sss) and NSS support. The big reason for Red Hat pushing SSSD is compliance. E.g., userX under domain Y needs to be different than userX under domain Z, from a compliance standpoint. SSSD does that. Legacy PAM modules do not. There are major issues with Winbindd and other compliance aspects, where SSSD should be used instead, even when connecting to ActiveDirectory. I could go into the deep list, but in-a-nutshell, SSSD (and IPA) started with Red Hat's own Samba developers, and what was required. Samba is still really only designed for NT/LAN Manager attributes and services -- i.e., Windows. SSSD (and IPA) are designed for POSIX attributes and services -- i.e., UNIX/Linux. -- 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 [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
