Alan McKinnon <[EMAIL PROTECTED]> wrote: > Actually, these industry people are being quite pragmatic. Like a > site has implemented AD and would like to take advantage of Linux > machines in cases where Linux has a proven track record. But they > don't want to end up with two authentication systems and as AD is > already there, they are asking "Please get this *nix box to use > what I already have"
"Two authentication systems"? I think you're stating the answer based on a _different_ question. ;-> First off, single sign-on, including password updates, is quite achiveable -- not, let me rephrase that -- damn easy between peer LDAP systems. Why? Because LDAP has *NOTHING* to do with authentication. Just because you have separate directory services does _not_ mean they have to use separate authentication systems. Secondly, a shocker to most people is the fact that your KDC doesn't have to be a Windows RPC service. In fact, it's a security _nightmare_ to put the KDC on the same system as a RPC service. Lastly, this is where "Samba knowledge" is *NOT* enough. Samba is a set of Windows _client_ compatible RPC services. Samba is *NOT* a set of _enterprise_ Linux infrastructure solutions. The "problem" is getting people to realize that. ;-> So, again, don't answer an ignorant question. Educate them so they can ask an _enterprise_ Linux question. ;-> > By PDC/BDC I meant AD style authentication, not NT style. Do you _know_ what "DC" means? A network-wide SAM. That's it! In fact, it has more to do with the design of NTFS (and workarounds) than any "networking" (don't get me started ;-). And do you _understand_ the difference between a SAM-only DC (PDC/BDC) and a DNS/Kerberos/LDAP-integrated, peer-replicating DC (ADS DC)? Really? It's how the SAM is passed around. So I hope you _realize_ that the "DC" functionality of a PDC, BDC or ADS DC is _no_different_ than the common _falicy_ of a difference between a "workgroup" and a "domain"? In other words, Samba can do _any_ DC functionality. What you're talking about has *NOTHING* to do with "DC." What you're talking about is 100% RPC services and related, proprietary schema built _around_ the DC functionality. Please do *NOT* "dumb it down" until it's factually _incorrect_. ;-> > Tridge tells us that is still to come in SAMBA 4. Where I live, > there is a real demand for that level of functionality > [snip details of how ADS works] What Tridge is saying is that people want Samba 4 to be a _real_infrastructure_ set, and not just a set of Windows _client_ compatible RPC services and only the basic DC functionality. In other words, people want a "fixed, integrated" infrastructure set, and not the current, flexible, peacemeal solution. And he's going to build it so it acts like ADS. Acting like ADS is _not_ always ideal (and that's me talking as a MCSE too! ;-). > I'll not argue this point with you as > a) we don't disagree and > b) I'm not an expert. It's not about "disagree" or "agree." It's about _technical_facts_. Sorry, it's not about "disagree" or "agree" at all. People think products, not technologies. I think technologies, not products. And that's why I make the big bucks. ;-> > I was simply reporting what my employer's customers want, The problem is ... hint, hint ... they do *NOT* know what they want. The bigger problem is that they want an infrastructure that works with Windows _clients_ and add-on _services_ "out-of-the-box." In other words, they want a specific ADS version set and capability. And when an older version of ADS doesn't work, they will upgrade, paying all those upgrade costs, etc... As any Microsoft Gold Partner, the design is that companies _must_ upgrade _all_ clients, servers, etc... every 2-3 years. Why? Because companies keep deploying specific Windows technologies that require specific Windows services that only work on specific Windows versions with specific LDAP schema and related services. That's not even "proprietary" anymore. "Proprietary" requires long-term support from a vendor that "values" it's own, "proprietary" standards. There are better terms -- "Orphanware" and "Hostageware." You either "Orphan" yourself or you become a "Hostage" to upgrades. Linux will *NEVER* solve the problem of "vendor lock-in." Samba does its best in many aspects, but at some point, you have to *CHOOSE* not to deploy an "Orphanware/Hostageware" solution. That's why enterprise, *MAJOR* enterprise, maintain a separate LDAP tree and Kerberos realms from ADS. In fact, they often use the LDAP tree and its Kerberos realms as the "master" for the corporation. Why? Because when they upgrade from ADS 2000 to 2003 to "Longhorn," they can have *1* base tree and credential reference. In other words they synchronize to the *NON* Microsoft, Linux-hosted "infrastructure" instead of trying to get ADS 2000, 2003 and "Longhorn" servers to talk to each other. ;-> Now do you "see" what I mean? @-ppp Educating people on this fact is not only difficult with clients, but I *HATE* the fact I have to *FIGHT* 97% of Linux consultants. So, no, you're not in that 3% with me and others. Maybe it's only 0.3%? ;-> > and the ability for something other than a Windows server to > provide ADS functionality is on that list. Their reported > reasoning: cost, and stability Did they ever stop to think that selecting "Orphanware/Hostageware" was the root cause? No! They just want Linux to "solve" _their_ decision to put *ALL* of their infrastructure into an "Orphanwere/Hostageware" solution. ;-> If they want to do that, they *MUST* be willing to pay for "Hostageware" upgrades every 2-3 years. I've had this discussion over 1,000 times, and I'll have it again 1,000+ times more. If you want it, pay Microsoft for it and quite talking about "cost and stability." If you want to build a _perpetual_, _flexible_ and _open_ network infrastructure -- you use "open" systems. They exist! They have *BEFORE* ADS was introduced. Samba is merely trying to implement and emulate all of the endless proprietary RPC services and related schema in the LDAP store. I wish them the continued, best of luck doing so. But the reality is that they will always be 2-3 years behind Microsoft's current "Hostagware" solution, and only capable of providing "an exit" from the, now 2-3 years later, "Orphanware" solution Microsoft _previously_ offered. > In summary, the current roadmap for LPIC-3 accurately reflects what > industry is asking for in my neck of the woods. I don't see how that has anything to do with what you discussed above. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-discuss mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-discuss
