And, I just want to say, this is absolutely outstanding work for a very inclusive 'first shot.' Well done!
Hopefully we'll get a lot of additives. One thing I've been doing is a lot of 389/IPA Troubleshooting as of late (have a broken setup we'll be replacing soon, but it won't happen overnight), and maybe we should add some generic LDAP search/modify commands that are related. - bjs On Thu, Jan 24, 2019, 15:48 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 >>> [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
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
