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] <mailto:[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 <http://ieee.org> or me at bjsmith.me
<http://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
