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
