BTW, I fully want to recognize ... 1) Regarding SSSD - We've integrated some objectives into other exams, even levels. So that has been a great add.**
2) Regarding 300 - I also understand not all of this will fit into 300, and there were the 301/302 retirements. So where this all fits, I don't know. So, from the standpoint of ... A) 303 - Add in the SSSD capabilities, especially SSH (sss_ssh_authorizedkeys), which is in heavy, Enterprise use. E.g., even the US Treasury uses it (with eDirectory) last time I checked. B) 300 - maybe move AD Forest Trusts from 303? Add basic concepts/commands of putting IPA Domain Groups in AD Domain Local Groups that are assigned to resources? I think that's similar to Samba aspects. C) 300? 301 (un-retire)? - Most of the other details are LDAP schema-related, so they would be more 301 like. Don't know if that should be in 300, since we cover OpenLDAP. I just cringe anytime I see OpenLDAP covered, but not 389, given my Enterprise exposure -- albeit it's been limited to largely North America, and more limited in Europe. On Tue, Oct 16, 2018 at 4:29 PM Bryan Smith <[email protected]> wrote: > 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 > -- -- 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
