I know I'm way late on this, but since people are talking LPIC-2 again, if I might add something for Sections 210.x?
Instead of getting detailed into installing a LDAP server, which can vary greatly, based on implementation (e.g., 389 v. OpenLDAP -- let alone 389/Kerberos-based IPA) ... Why no cover the more _practical_ experience if configuring System Security Services Daemon (SSSD)? SSSD replaces a lot of legacy (sometimes broken or very non-compliant with various programs these days) PAM, NSS and other services. In fact, it uses newer OpenLDAP libraries than older pam_ldap and related modules and projects. It's really a modern, single concentrator for network authentication and object access and caching. In fact, when I talk to more Windows admins, I relate SSSD as Linux's implementation of a Local Security Authority (LSA) subsystem and related Security Service Providers (SSPs). SSSD has built-in, and more deterministic caching than nscd, and it is superior to Samba's Winbindd now (especially for multi-domain support). And one of SSSD's most powerful features is it's ability to directly use the IETF RFC2307 schema if IdM for UNIX is configured and attributes actually populated in AD (i.e., Windows admins populate both Windows and POSIX-UNIX/Linux attributes), removing the need for "remapping" via Winbindd, let alone countless all those countless proprietary add-ons (Centrify, Qwest, etc...). When the discussion is around _client_ services, SSSD really should be in LPIC-2. I have yet to find anyone who hasn't deployed SSSD, including on Debian or Ubuntu (although old, broken versions are always an issue), that doesn't sing it's praises. It just concentrates everything. What normally "trips people up" is when they try to paint SSSD as Red Hat-centric or related to sister projects. It's not. Yes, SSSD is typically used _with_ authconfig (a tool for auto-configuring PAM, NSS and SSSD) in the Fedora/RHEL sphere, but SSSD is completely separate. And while SSSD is required for the IPA client, it is separate from IPA, and can be used with AD, LDAP, Kerberos, etc... services unrelated to IPA. -- bjs P.S. On the LPIC-3/Samba4 end, I hope everyone recognizes that Red Hat is going a completely different route than the samba4-dc approach, and has patched Samba4's file and other services to support a multi-domain, multi-trust model. Instead of trying to emulate Windows attributes in an AD forest with its own, Windows-centric schema, Red Hat is using a separate, POSIX (UNIX/Linux) schema and domain model in IdM (IPA). It then establishes an AD Forest Trust when AD interoperability is required. That way the "IPA Domain" (POSIX domain) has its own schema and attributes (where "UNIX/Linux" groups and servers "live"), and the "AD Forest(s)" (Windows domains) have their own schema and attributes (where "Windows" groups and services "live") I.e., all IPA does is leverage the existing AD Forest model, because even AD admins cannot all agree on what schema and attributes Windows domains should have either, including trusts and related "best practices". E.g., AD Forest1 "security group" (with users) is added to AD Forest2 "domain local group" which is applied as an access control entry on the actual resource in AD Forest2 they wish to access. In the same regard, the AD Forest2 could actually be an IPA Domain with a group that is assigned to a Samba resource, and vice-versa. -- Bryan J Smith - UCF '97 Engr - http://www.linkedin.com/in/bjsmith ----------------------------------------------------------------- "In a way, Bortles is the personification of the UCF football program. Each has many of the elements that everyone claims to want, and yet they are nobody's first choice. Coming out of high school, Bortles had the size and the arm to play at a more prestigious program. UCF likewise has the market size and the talent base to play in a more prestigious conference than the American Athletic. But timing and circumstances conspired to put both where they are now." -- Andy Staples, CNN-Sports Illustrated On Sat, Aug 3, 2013 at 4:57 AM, Harald Maaßen <har...@nwa-net.de> wrote: > Hi everyone, > > I know, that it is a little bit late for changes to LPIC-2 Version 4, > but wouldn't it be usefull to change the order under Topic 210 like this: > > Topic 210: Network Client Management > 210.1 DHCP configuration (weight: 2) > 210.2 Configuring an OpenLDAP server (weight: 4) > 210.3 LDAP client usage (weight: 2) > 210.4 PAM authentication (weight: 3) > > That would give some didactic advantage for books and other > coursematerials, because: > 1. Install the LDAP-Server > 2. Use it for practice with LDAP-Client > 3. Integrate 1. and 2. with PAM > > What do you think? > > Best regards > Harald > > > _______________________________________________ > lpi-examdev mailing list > lpi-examdev@lpi.org > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
