On Tue, 2006-06-20 at 15:26 -0200, [EMAIL PROTECTED] wrote: > And why having winbind as part of the samba exam and not as part > of the auth exam would prevent this?
Because Winbindd on the Samba exam will take away from SMB and other network file service concepts such as access controls and authorization. At the same time, Winbindd on an auth/dir/name exam will be with _other_, related object authentication and naming concepts that can _also_ be used by other services, which are covered on other exams. "Common denominators" to object authentication and naming go on the auth/dir/name exam. Otherwise we'll quickly find ourselves covering, recovering and even more recovering the same "common denominators" and more and more exams. > And in the real world, how many companies use winbind without other > samba services? ISP/ASPs do! Seen it many times for Apache! I've also seen UNIX/Linux file servers that used it for authentication against an ADS domain, but did _not_ provide SMB (only NFS or AFS). At the same time, I've seen ADS integration _without_ Winbindd. They used PassSync or other synchronization tool instead, and keep the objects local to the UNIX/Linux network. > We should test for common scenarios and not for the exception ones. I do _not_ consider what you suggest "common" to an "enterprise" network. You're talking HOWTO/Cookbook non-sense that works for departmental and _standalone_ servers where you're doing local authentication. I consider the "standalone" and "local-only" focus to have nothing to do with "enterprise." > We can't test for all conceivable scenarios. :-) I'm not suggesting that. You keep thinking that I'm suggesting that. Why? Because you're designing the Samba-only exam for 1-2 auth/dir/name scenarios. And then every other exam for 1-2 auth/dir/name. I'm trying to _avoid_ "scenarios" all-together! I'm trying to say things like ... - "Here's how you configure Kerberos' KDC, setup principles, etc..." - "Here's how you configure NTLM authentication with Winbindd." - "Here's how you map to native SAM objects." - "Here's how you can store native SAM objects in TDB, LDAP, etc..." - "Here's how you leverage native UNIX/Linux network objects." - "Here's how you can configure local UNIX/Linux name switch." - Etc... And that way we can do on other exams ... - "Here's how Samba passes authentication." - "Here's how Samba gets its user/group mapping." - Etc... That _removes_ scenarios entirely! We don't want to be testing "scenarios." We do _not_ want to be testing "cookbook" methods. We want to be testing _tasks_ -- tasks that, when put together as a whole, "do something" _across_ an "enterprise." > On the other side, how could someone manage a winbind server and not > knowing the remaining samba stuff? Quite easily! You authenticate the system into the native SAM (Windows) domain. You configure your smb.conf for only Winbindd components. You start the service without smbd! You do _not_ have to run smbd! Hell, you can even run nmbd _without_ smbd too! And vice-versa in _all_ cases. Just because smbd, nmbd and winbindd are not mutually exclusive doesn't mean they have _any_ dependency on each other what-so-ever! ;-> -- Bryan J. Smith Professional, technical annoyance mailto:[EMAIL PROTECTED] http://thebs413.blogspot.com ---------------------------------------------------------- The existence of Linux has far more to do with the breakup of AT&T's monopoly than anything Microsoft has ever done. _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/mailman/listinfo/lpi-examdev
