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
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
