I take that back, it seems it does cover POSIX (UNIX/Linux) clients too. I'll need to review more before I say more.
That said, Objective 397.X, add ... - [pam_]faillock - /var/lib/sss/db/ I think as much of the Authentication Client support of these should be pushed down to LPIC-2 and some real basics pushed down to LPIC-1, if possible, and LPIC-3 focus on the advanced client setup, including customized PAM (possibly push up from LPIC-2). BTW, I'm fine leaving these in and discussing this with LPIC-3 (3xx), so it's 'documented' as 'lower level' for the next revision of those exams. Overlap is always going to happen, especially between revisions. - bjs On Thu, Jan 24, 2019 at 4:36 PM Bryan Smith <[email protected]> wrote: > > I think (Fabian can correct me if I'm wrong) this is the Windows > client-centric exam, and not the POSIX (UNIX/Linux) client centric > exam. > > The only mention of IPA is part of generic SSSD/IPA authentication as > a client. Although some of that could be a candidate for, or shared > with, LPIC-2. > > - bjs > > On Thu, Jan 24, 2019 at 4:18 PM Kenneth Peiruza <[email protected]> wrote: > > > > Hi Fabian, > > > > Good update. However, I think there's too few freeipa and maybe some things > > like set/getfacl & tdb backup are already covered in LPIc 2. > > > > I'd suggest to add some CA management with freeipa as well, and to get a > > deeper dive into ssh-keys and sudo management with freeipa. > > > > > > Regards! > > > > Kenneth > > > > On Jan 24, 2019 9:48 PM, Fabian Thorns <[email protected]> wrote: > > > > Dear all, > > > > it took some time to follow up, but we finally have a draft for the new > > LPIC-300 objectives: > > > > https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V3.0 > > > > It would be great if you could review the draft and share your opinions > > here. Nothing is set in stone yet, so make sure to bring up any concerns so > > we can finalize the objectives soon. > > > > Fabian > > > > PS: Before you ask, there will be some new regarding the other LPIC-3 exams > > soon, too. > > > > > > On Tue, Nov 27, 2018 at 12:53 AM Fabian Thorns <[email protected]> wrote: > > > > Hi there, > > > > it seems we agree to drop most of the topics 390 and 391 from the 300 exam, > > move over 326.3 (User Management) and 326.4 (FreeIPA) from 303 and add some > > more FreeIPA and SSSD. > > > > We currently cover the LDAP basics (including ldapmodify) in 202, so we > > could expect candidates to handle LDAP in general. Would you still cover it > > in the 300 exam? > > > > Assuming that we don't (and correct me if I am wrong here), what do you > > think of a potential objectives outline similar to this one? The > > xx*-topics/objectives would be the new structure, the 39*-objectives show > > where the current objectives would be placed in the new objectives. The old > > objectives still contain their original weight, I've added a '-' (and I > > think no '+') where I'd like to propose a change in weight. > > > > = Topic xx1: FreeIPA Domain Management (weight: 15) > > > > xx1.1 FreeIPA Concepts and Architecture (3) > > - Service > > - Replication topology > > - Domain Levels > > - DNS > > - Awareness of PKI > > > > xx1.2 FreeIPA Domain and IDM Server Management (weight: 3) > > > > xx1.3 FreeIPA User Management (weight: 3) > > > > xx1.4 FreeIPA Policies and Access Control (weight: 4) > > > > xx1.5 FreeIPA and Active Directory Integration (weight: 2) > > 326.4 FreeIPA Installation and Samba Integration (weight: 4) > > > > > > = Topic xx2: Linux Authentication (weight: 8) > > > > xx2.1 PAM and NSS Authentication (weight: 4) > > 391.1 LDAP Integration with PAM and NSS (weight: 2-1) > > 326.3 User Management and Authentication (weight: 5-3) > > > > xx2.2 SSSD Authentication and IPA Client Management (weight: 4) > > > > > > = Topic xx3: Samba Basics (weight: 8) > > > > xx3.1 Samba Concepts and Architecture (weight: 2) > > 392.1 Samba Concepts and Architecture (weight: 2) > > > > xx3.2 Samba Configuration and Tools (weight: 3) > > 392.2 Configure Samba (weight: 4-1) > > Add registry based configuration > > > > xx3.3 Samba Maintenance and Troubleshooting (weight: 3) > > 392.3 Regular Samba Maintenance (weight: 2-0.5) > > 392.4 Troubleshooting Samba (weight: 2-0.5) > > > > > > = Topic xx4: Samba File and Printing Services (weight: 11) > > > > xx4.1 File Shares (weight: 3) > > 393.1 File Services (weight: 4-1) > > > > xx4.2 Advanced Access Controll (weight: 3) > > 393.2 Linux File System and Share/Service Permissions (weight: 3) > > > > xx4.3 Print Shares and Printing Drivers (weight: 2) > > 393.3 Print Services (weight: 2) > > > > xx4.4 CIFS Integration (weight: 3) > > 397.1 CIFS Integration (weight: 3) > > Move smbmount and mount from 393.1 to 397.1 > > > > > > = Topic xx5: Samba Active Directory Services (weight: 15) > > > > xx5.1 AD Directory Maintenance / DC (weight: 4) > > 395.2 Samba4 as an AD compatible Domain Controller (weight: 3) > > 396.2 Active Directory Name Resolution (weight: 2-1) > > > > xx5.2 AD User Management (weight: 3) > > 394.1 Managing User Accounts and Groups (weight: 4-1) > > > > xx5.3 AD Domain Membership (weight: 6) > > 394.2 Authentication, Authorization and Winbind (weight: 5-1) > > 395.3 Configure Samba as a Domain Member Server (weight: 3-1) > > > > xx5.4 Windows Client Management (weight: 2) > > 397.2 Working with Windows Clients (weight: 2) > > Add awareness and capacities of GPOs > > > > > > = Drop: > > > > - 391.2 Integrating LDAP with Active Directory and Kerberos (weight: 2) > > - 390.1 OpenLDAP Replication (weight: 3) > > - 390.2 Securing the Directory (weight: 3) > > - 390.3 OpenLDAP Server Performance Tuning (weight: 2) > > - 392.5 Internationalization (weight: 1) > > - 395.1 Samba as a PDC and BDC (weight: 3) > > - 396.1 NetBIOS and WINS (weight: 3) > > > > Sorry if this looks messy, I hope you're getting what I mean. > > > > As usual, this is in no way final, it's intended to feed the discussion. > > Once we've put it in a proper share we will work out the details. > > > > Let me know what you'd like to see changed, > > > > Fabian > > > > > > On Tue, Oct 23, 2018 at 9:57 PM Dirk Streubel <[email protected]> > > wrote: > > > > Hi, > > > > i think Bryan is right. In the 300 exam must be the 389 Server and or the > > FreeIPA Part. > > > > After the decision from Red Hat and Suse not to support OpenLDAP in the > > future it makes sense to enlarge the exam with this two points. > > > > Another Point is 395.3 : Joining Samba to an existing NT4 domain > > > > In my opinion this point can be canceled. In my work i doesn't see any NT4 > > domain any more. > > > > Perhaps in the world are some NT$ Domains but i think this is a handful of > > domains. And how big is the chance to met them? > > > > Best regards > > > > Dirk > > > > > > > > Am 16.10.2018 um 22:29 schrieb Bryan Smith: > > > > Fabian Thorns <[email protected]> wrote: > > > > I think we will have some fundamental discussions about this exam; i.e. > > regarding the relevance of NT4 domains, of the amount of Windows knowledge > > covered in the exam, about the real relevance of FreeIPA > > > > > > First off: The "iPlanet lineage" (389) "Real World" > > > > I've been quiet since my initial barking, since LPI ignored the 2005+ open > > sourced version 8 of iPlanet, aka "389 Server," since inception of the > > level 3 program, so I don't know where to start. 100% of the Enterprise > > environments (several dozen) I've worked in (going back to even the very > > late '90s) have all been iPlanet-based, whether they were all, newer Red > > Hat Directory Server (RHDS) from the get-go, or they migrated from Sun One > > or another iPlanet implementation when Oracle shutdown the product line > > earlier this decade (one was even Netscape from the get-go). > > > > Multi-master replication is pretty important to Enterprises, which is why > > everyone still runs 389 -- unless they had eDirectory, of course, or just > > didn't care to centralize IETF/POSIX attributes at all, some don't. Some > > even just use NIS on loopback, using a configuration management system to > > 'push down' the maps to each system. And all of the OpenLDAP Server > > environments I've worked in have been very small implements. That said ... > > > > > > Secondly: Schema is what is important > > > > I really don't care what people run. What I care about is schema for > > centralizing SSH public keys (w/SSSD sss_ssh_authorizedkeys), Sudoers, > > Automounter maps (especially w/SSSD caching, chucking legacy LDAP > > integration), SELinux rules (this only applies to SELinux enforcing > > systems, of course), etc... I live in a world of SSSD as standard, and > > I've yet to meet a single Debian or Ubuntu sysadmin that doesn't praise > > SSSD once they deploy it for the first time, so it's not just us Red > > Fedoras either. > > > > Because once you have SSSD, you want to take advantage of all of its > > capabilities that can be stored in the LDAP schema. E.g., in the last few > > financial services industry (FSI) enterprises I worked in, centralizing SSH > > public keys made multi-factor authentication (MFA) painless as the user > > would get the key challenge, followed by another -- whether password, > > additional certificate, etc... -- but still only got no more than one > > prompt (if any in the case of key + certificate). > > > > Hence the second point. ;) > > > > So, that all said ... > > > > > > Third: No more AD-IDMU -- either nothing, proprietary or AD Forest Trusts > > > > Microsoft deprecated ActiveDirectory Identity Management for UNIX (IDMU) in > > Windows Server 2012R2, and it's utterly removed as of 2016. IDMU was > > really basic in the first place, compared to various LDAP schema out there > > for managing all sorts of things, but it was something. But now that it's > > gone, it that means enterprises have two (2) choices for centralizing > > IETF/POSIX attributes with Windows/ActiveDirectory integration ... > > > > 0) Nothing - don't centralize, enumerate at the end-system (won't pass an > > audit) > > 1) Proprietary - install a proprietary solution with costly CALs > > (Canonical punts things here) > > 2) IPA - the AD Forest Trust FTW > > > > I really don't understand how we can cover Samba, but ignore all of the > > work done between the IPA-SSSD and Samba teams to address all sorts of > > issues in Samba that IPA already addressed first. (HINT: virtually all of > > Red Hat's Samba contributors are on IPA-SSSD, and solved things in the > > former, then ported over to the latter) Multi-domain enumeration for > > starters, which the IPA teams added to SSSD, then worked into Samba. > > Especially in a world where almost everything is Kerberosized too ... which > > IPA brings to-the-table, and not in a way that is only useful for Windows > > services, like Samba. > > > > So, to recap ... IPA brings all of the benefits of iPlanet legacy over > > other implementations (#1), with the 'built-in' schema that enterprises > > want (#2) and then offers MIT Kerberos with MS Kerberos compatibility, > > offering those nice, External AD Forest Trust options for dealing with the > > pesky lack of integration now that AD-IDMU is gone. So IPA Domains can > > access AD Domain resources (put IPA User Groups in AD Domain Local Groups), > > and vice-versa, right down to those principals and ID mappings across > > REALMs (domains). > > > > The entire pipe dream of non-Windows and Windows using the same schema was > > always just that -- separate AD Forests are required because the schema > > differs since IETF/POSIX cannot use Windows/NTuser attributes, and > > vice-versa. This is just the reality, and why a Samba DC in an AD Domain > > was never going to be able to address the reality of what end-IETF/POSIX > > systems. This tri-fecta also cleans up a lot of hacking, messes and other > > things when systems are assuming things, instead of actually seeing the > > full principals across REALMs, along with storing security, etc... -- e.g., > > I hate hacking up rpc.idmapd (don't get me started). And then IPA brings a > > host of other features. > > > > I mentioned MFA before, and IPA also offers TOTP or HOTP and the option for > > 3rd party integration with FreeRADIUS built-in. And there are yet other > > features. So ... > > > > At some point we're really looking at either breaking out all of these > > features one-by-one ... or just covering IPA. I'd rather just cover IPA, > > especially since Red Hat is building everything around it ... along with > > Ansible Tower for remediation and validation ... and not just for Red Hat > > products, or even OSes ... but networking equipment too. I know people > > look at IPA-SSSD as Red Hat-only, just like they did 389-RHDS before it. > > > > LPI can continue to do that if it wants. But IPA-SSSD is being adopted in > > a lot of environments. One doesn't have to be a LDAP or Kerberos expert > > anymore in an IPA environment, and has the bonus of addressing > > inter-operability in _both_ directions with AD, not just one. > > > > > > -- > > 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] > > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > > > > _______________________________________________ > > lpi-examdev mailing list > > [email protected] > > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > > > > > > -- > > Fabian Thorns <[email protected]> GPG: F1426B12 > > Director of Certification Development, Linux Professional Institute > > > > > > > > -- > > Fabian Thorns <[email protected]> GPG: F1426B12 > > Director of Certification Development, Linux Professional Institute > > > > > > _______________________________________________ > > lpi-examdev mailing list > > [email protected] > > https://list.lpi.org/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 -- -- 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
