They used to say the same thing about NSS/389/Dogtag. Now every distribution is hacking in support for SSSD and IPA. Why is that? ;)
E.g.., how many people used to not only OpenLDAP was the only open source directory server, but say inherent, multi-master replication wasn't available or didn't work well? I. e., cannot help if people are unfamiliar, and distributions don't get enough maintainers to port it. The first time someone sees AD Forest Trusts at work, they are instantly drawn to it. Heck, just the SSSD portion draws them. So, let me re-iterate my point one more time ... AD Group Policy Objects (GPO) are used to manage Windows attributes. So why would we include them in a POSIX (UNIX/Linux) security exam? There are no free or open source implementations that add POSIX support to GPOs, only proprietary solutions. Ergo ... If we're going to add any 'Policy' objectives to any POSIX security exam, they should be the POSIX attributes that can be stored in a LDAP set of schema instead. And I'd argue the most 'standarized' set of 'Policy' Objects are the ones that cover certificates, SSH, sudoers, auto_home, etc... These were popularized in NSS/389/Dogtag (fka iPlanet Security/Directory/Certificate, well proliferated in major installations), acquired by Red Hat in 2004, fully open sourced in 2005 (a few components were re-written), including its inherent, multi-master replication, and most people implement in Identity, Policy, Audit (IPA) out-of-the-box. Other than certificate, this schema can also be implemented in OpenLDAP as well. Most distributions have been hacking in SSSD/IPA support, after ignoring NSS/389/Dogtag for a decade, because unlike Samba-Winbindd/OpenLDAP, it actually addresses a crapload of interoperability and security issues, let alone provides a "canned" Policy set that is a serious PITA to setup in a generic LDAP server, like OpenLDAP or 389 itself for that matter. It was also, heavily written by Samba maintainers, especially IPAv3 components that add AD Forest Trusts. Because AD schema isn't designed for POSIX attributes, but Windows ones. And in an AD Forest, all domains and systems have to have the same schema. Microsoft, prior to Windows 10 (Server 2016), only supports basic IETF RFC2307bis (IDMU), no POSIX Policy. And with 10/2016, they are dropping it. In other words ... one cannot store POSIX Policy Objects and Attributes in AD, so GPOs are useless for POSIX systems. Meanwhile, Microsoft has dropped even basic POSIX attributes from the latest AD/Server, because IPA exists with its AD Forest Trust. That way AD Forest can stay "pure Windows attributes" like 99% of AD architects expect (let alone too many AD admins are ignorant of), and all POSIX attributes and resources go into an IPA domain. Including Samba Servers being in an IPA domain, instead of AD. That way, via the AD Forest Trusts, the POSIX architects/admins can put AD Security groups in IPA [Resource] Groups that have access to Samba shares. All the meanwhile, the same IPA domain can push down actual POSIX (UNIX/Linux) policies on the actual POSIX/Samba server, something AD with it's GPOs cannot do outside of the Samba server itself 'emulating" itself as a Windows server (quite literally nothing). I cannot help of people are wholly unfamiliar with how AD, GPOs, schema/attributes (especially Windows v. IETF/POSIX) works, especially how limited Samba is, and why many Samba contributors took 389/Dogtag and basically invented AD for POSIX. Same thing goes for distributions that snubbed NSS, and didn't integrate 389/Dogtag, but are now scrambling to add SSSD/IPA because it's a killer service set that has no equal. It's certainly not because Red Hat/Fedora doesn't put maintainers time on other distributions (like a lot of what they do, even employer other distributions maintainers), but because too many users don't work in huge, corporate environments where 389/Dogtag already exists because of OpenLDAP limitation, and now love what SSSD/IPA finally addresses. Ignorance is bliss. ;) -- bjs DISCLAIMER: Sent from phone, please excuse any typos -- Bryan J Smith - Technology Mercenary b.j.sm...@ieee.org - m...@bjsmith.me - http://linkedin.com/in/bjsmith On Sep 21, 2016 06:22, "Mark Clarke" <m...@jumpingbean.co.za> wrote: > I don't do a lot of work with Samba, other than fairly vanilla > implementations, but can comment on the IPA/FreeIPA that has been included > in the security cert. The issue I have IPA/FreeIPA is the only distro that > supports it is Fedora/Feroda and is largely unsupported in the rest of > them. Seems like a distro specific feature? > > On 21/09/2016 06:11, Kenneth Peiruza wrote: > > Hi, > > Why do we have openldap on the same course as Samba? > > We lost t'he 'centralized auth' ldap part when LPIC 301 passed away. > > IMHO, FreeIPA would make a lot more sense in this de facto 'Centralized > Authentication Services' LPIc rather than in LPIc 3 security. > > Regards, > > > > Sent from my Mi phone > On Bryan Smith <b.j.sm...@ieee.org> <b.j.sm...@ieee.org>, Sep 20, 2016 > 2:41 AM wrote: > > Policies? That's really a 100% Windows client aspect. > > I don't see how it has anything to do with POSIX (UNIX/Linux), and > requires an entire discussion of Windows client assumptions, from the > NT Local Security Authority (LSA) on down. Furthermore, on the AD > Forest side, even Samba4 has limited, AD Forest support and related > tree/domain delegation/trust. Most of its limited support has been > hacked in from IPA contributions (long story). It's really a topic > for Microsoft's dedicated policy and security exams in their tracks. > > Again, it's a Windows aspect, because AD schema is only designed to > manage Windows schema.** The only non-Windows, like POSIX, support > with Policy Objects are all costly, proprietary add-ons. I haven't > seen a free one yet. The free ones only provide similar functionality > to SSSD and, more legcy, Winbindd. And even when it comes to basic > IETF 2307bis -- aka Identity Management for UNIX (IDMU), Microsoft has > announced they are no longer going to provide it with Windows 10.** > > -- bjs > > **P.S. In-a-nutshell, Microsoft has all but agreed Red Hat has the > right idea by using IPA domains, keeping POSIX objects and schema > _away_ from AD, because AD admins don't install/use IDMU, much less > populate. It's much easier to use AD Forest Trusts between AD domains > and IPA domains, with AD admins designating what AD resources external > IPA groups have access to, and vice-versa. > > On Mon, Sep 19, 2016 at 8:11 PM, alexbm...@gmail.com > <alexbm...@gmail.com> wrote: > > Gentlemen, > > > > It would be interesting to insert GPO referring to samba. > > > > To: Relevance of NT4 domains vs. AD domains. > > > > > > > > > > > > > > On 09/18/2016 01:07 PM, Bryan Smith wrote: > > > > Well, Samba 3 and Samba 4 aren't much different. The protocol in > > Samba 4 is the same as Samba 3. > > > > Samba 4 introduces the DC option, but not all distros include it. > > E.g., Red Hat has gone the IPA route for AD Forest Trusts, instead of > > allowing a Samba Server to be a DC in a native AD Forest. > > > > > > On Sun, Sep 18, 2016 at 9:17 AM, G. Matthew Rice <m...@starnix.com> > wrote: > > > > +1 for these changes...samba 3 should definitely go. > > > > I know there are a lot of samba3 installs still out there....but there > > shouldn't be. :) > > > > > > On Sep 17, 2016 2:17 PM, "Fabian Thorns" <ftho...@lpi.org> wrote: > > > > Dear all, > > > > taking a look at > > > > https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1 > > > > You will notice that it's time to review the current LPIC-300 objectives > > to ensure they are still up to date. Therefore I'd like you all to share > > your thoughts about our current objectives with the list, including > wishes > > what should be changed in the next update. We have however to obey that > it > > will be "minor update", so we can't fundamentally turn the while exam > > around. > > > > Some things we should discuss from my point of view would be: > > > > * Relevance of NT4 domains vs. AD domains > > * Same for NBNS vs. DNS > > * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble, > > though) > > > > However, I don't want to limit the discussion on these points. Just go > > ahead and point out what you think. As usual, I will comment when > necessary > > and condense all the comments into a draft for potential updated > objectives > > which we will then review altogether again. > > > > Looking forward to an interesting discussion, > > > > Fabian > > > > > > _______________________________________________ > > lpi-examdev mailing list > > lpi-examdev@lpi.org > > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > > _______________________________________________ > > lpi-examdev mailing list > > lpi-examdev@lpi.org > > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > > > > > > -- > > Alex Clemente > > 11 979919870 > > a.clementesi...@uol.com.br > > alexbm...@gmail.com > > Analista Linux e Unix > > Instrutor Linux e Open Source > > Alex Clemente > > 11 979919870 > > a.clementesi...@uol.com.br > > alexbm...@gmail.com > > Analista Linux e Unix > > Instrutor Linux e Open Source > > Linux+ – CompTIA Linux+ (Powered by LPI) > > SUSE CLA 11 – Certified Linux Administrator > > SUSE CLP 12 – Certified Linux Professional > > SUSE 11 Tech Espec – Technical Especialist > > LPIC-1 – Linux Professional Institute Certified Level 1 > > LPIC-2 – Linux Professional Institute Certified Level 2 > > > > > > _______________________________________________ > > lpi-examdev mailing list > > lpi-examdev@lpi.org > > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > -- > > -- > 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 > > > > _______________________________________________ > lpi-examdev mailing > listlpi-examdev@lpi.orghttp://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > -- > > > -- > Mark Clarke > 📱 +2711-781 8014 > 🌠www.JumpingBean.co.za > > > _______________________________________________ > lpi-examdev mailing list > lpi-examdev@lpi.org > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
