From: Dag Wieers
Bryan, and you're still belittling people in discussions and get into long arguments as a result. Pretty please stop doing that.
I apologize for any belittling. It is not my intent, but I do see a repeat theme. People thing in single products/projects, not breaking down things into their multiple technologies.
That's all I meant by "artificially limiting."
Even if you think you're right, leave some room for the possibility you're not.
It has nothing to do with right/wrong. There is just this farce out there that you must have ADS or every native Windows Server 2003 interface to have quality Windows client management. Various teams, including Samba, have done a wonderful job of reverse engineering many.
But the reality is that if you can avoid deploying services that require MS' sprawling (and sometimes self-incomaptible) schema, then you don't need native MS ADS DCs. Enterprises do it all-the-time.
People always need some room in arguments, unless you want to corner them. And I'm sure that's not your intent anyway.
I _did_ ask the questions, what is ... - ADS? - MS (schema) LDAP?
It goes to the heart of the viewpoints and dicussion. Especially for components that are not Samba, but most people only look at for _limited_ Samba use. E.g., MS Kerberos _only_ for authentication of Samba as a member server in a MS ADS DC controller domain (NOT ;-). UNIX/Linux Kerberos servers can do _far_more_ than that, even for 200x/XP clients.
Sometimes I think the best marketing done for Windows and Microsoft products is by UNIX/Linux people because they don't even know what services and capabilities are actually offered by UNIX/Linux platforms - be it open source, commercial, etc... ;->
People thing in single products/projects, not breaking down things into their multiple technologies.
That's all I meant by "artificially limiting."
Well, MS made extensions to its LDAP implementation by giving it new RPC calls for its special MS Kerberos data did it not?
So if I don't break it down, how else would I point out that ADS DC on open source is not possible unless these extensions are also available in open source implementations of these technoluogies?
Even if you think you're right, leave some room for the possibility you're not.
It has nothing to do with right/wrong. There is just this farce out there that you must have ADS or every native Windows Server 2003 interface to have quality Windows client management.
Right, but you got me interested in whether an actual open source solution to native Windows MS-Kerberos account management exists when you say that Samba 3.0 could be an ADS DC.
Various teams, including Samba, have done a wonderful job of reverse engineering many.
But the reality is that if you can avoid deploying services that require MS' sprawling (and sometimes self-incomaptible) schema, then you don't need native MS ADS DCs. Enterprises do it all-the-time.
and native MS account management on Unix?
On Mon, 2005-07-18 at 08:54 +0800, Feizhou wrote:
Well, MS made extensions to its LDAP implementation by giving it new RPC calls for its special MS Kerberos data did it not?
In a nutshell, yes you are correct in that Samba handles the "winlogon" process and other RPC services. I'm just saying there's a lot that Samba does not have to handle.
I think you keep mixing the fact that there _are_ other ways to manage Windows clients _other_ than with 100% emulated Windows RPC. If you want 100% full MS ADC DC emulation, it's going to be quite awhile.
Right, but you got me interested in whether an actual open source solution to native Windows MS-Kerberos account management exists when you say that Samba 3.0 could be an ADS DC.
To a point. You do _not_ have to have any MS ADS DC on your network to do a lot, trust me. The problem is that most people assume the only way. It's quite the opposite -- it's putting MS in charge, and that's something you want to avoid or segment.
and native MS account management on Unix?
By "native" -- what do you mean? You mean 100% MS schema in their LDAP? Again, that's going to be awhile.
Now the Samba team has their own, both CLI (net) and additional projects are out there. But that's still looking at it "narrow-mindedly."
Consider, for a moment, an entire Windows enterprise that relies on an open-backend, like NsDS, Sun One, etc...? Heck, even Novell eDirectory. Novell has a lot of management tools for Windows, some work pretty damn good too (like Xen).
But even that aside, you can do quite a bit with NsDS (or OpenLDAP), Samba 3.0's added schema and RPC functions, and SASL/Kerberos for the password store. But if you expect it to support all the nuiances and all the little schema that are in all sorts of MS services (like MS SQL, Exchange, etc...), that's going to be a _long_time_.
But don't think you have to have a native MS ADS DC to manage Windows clients -- not at all!
Right, but you got me interested in whether an actual open source solution to native Windows MS-Kerberos account management exists when you say that Samba 3.0 could be an ADS DC.
To a point. You do _not_ have to have any MS ADS DC on your network to do a lot, trust me. The problem is that most people assume the only way. It's quite the opposite -- it's putting MS in charge, and that's something you want to avoid or segment.
I just want Kerberos. I am not interested in the LDAP part of ADS.
and native MS account management on Unix?
By "native" -- what do you mean?
centralized Kerberos account management that Windows 2000/XP clients will accept in domain mode.
You mean 100% MS schema in their LDAP?
Forget LDAP.
Again, that's going to be awhile.
Yes, i know the openldap guys have not shown much interest in adding MS-LDAP rpc stuff.
Now the Samba team has their own, both CLI (net) and additional projects are out there. But that's still looking at it "narrow-mindedly."
eh?
Consider, for a moment, an entire Windows enterprise that relies on an open-backend, like NsDS, Sun One, etc...? Heck, even Novell eDirectory. Novell has a lot of management tools for Windows, some work pretty damn good too (like Xen).
That requires a different GINA right?
But even that aside, you can do quite a bit with NsDS (or OpenLDAP), Samba 3.0's added schema and RPC functions, and SASL/Kerberos for the password store. But if you expect it to support all the nuiances and all the little schema that are in all sorts of MS services (like MS SQL, Exchange, etc...), that's going to be a _long_time_.
But don't think you have to have a native MS ADS DC to manage Windows clients -- not at all!
Right, so what open source option(s) do we have to single-logon Kerberos? (please assume apps are also kerberosized)
On Mon, 2005-07-18 at 15:57 +0800, Feizhou wrote:
I just want Kerberos. I am not interested in the LDAP part of ADS.
Remember, all Kerberos does is provide authentication and ticketing. Even Kerberos, on its own, will _not_ provide much for UNIX/Linux clients. I think you don't seem to realize this.
Furthermore, if you want to use Windows XP Pro clients and Windows Server 2003 member servers "as is" with the Microsoft administrative tools, then you need _all_ of the added LDAP schema, RPC services built around them, etc... That's why there is a Samba schema added to LDAP, to support some of this (as well as Samba's stores).
centralized Kerberos account management that Windows 2000/XP clients will accept in domain mode.
But what is "domain mode"? Do you even know what "domain mode" is?
"Domain mode" isn't really about the Windows server. It's about the assumptions the Windows client makes with regards to naming (browser) and authentication/authorization (controller).
In fact, the differences between "workgroup" and "domain" are little more than what assumptions the Windows client makes. Hence why Samba, as a server, does _not_ see any difference.
At the "lowest level," the "browser" portion of a "domain" means domains can span multiple subnets. That's all! This is an _artificial_ Windows client limitation, one that I covered and even showed an example of in Chapter 33 of Samba Unleashed ("Cross Subnet Browsing" -- please excuse the "quality" of that chapter, I wrote it in 1 weekend for the author who was behind on publication). ADS merely takes this to a point where you can have multiple domains in a larger tree, and now uses passive DNS (with an option to manage it inside of ADS' LDAP schema), with WINS for legacy compatibility, instead of more active NetBIOS broadcasts (although, yes, WINS was also used before as well).
At the "lowest level," the "controller" portion of a "domain" means NT's Security Accounts Manager (SAM) is accessible domain-wide. This is actually to address a limitation and inherit design flaw with NTFS (yes, the filesystem, long story) as much as to make user management easier. Older NT 4.0 used NT LAN Manager (NTLM) then NTLMv2 as its authentication. NT5.x (2000+) now uses Kerberos, but clients can fall back to NTLMv2 (which is what Samba 2.2 can do, or even Samba 3.0 without a Kerberos back-end).
Again, _all_ ADS does over older NT4 DCs is re-organize how it handles these details, as well as uses DNS for network naming by default, as well as Kerberos for authentication. Pretty much nothing else really changes, _unless_ you start adding in services that extend the schema. Otherwise, an ADS domain is just a "feature rich" domain in comparison to NT4. Because Windows "domains" are really little more than naming, authentication and some way to store the NT-SAM "domain-wide" -- servicing Windows clients who make assumptions based on whether or not they are in a "workgroup" or "domain." Again, all a "domain" is from the standpoint of a Windows client -- is a set of assumptions!
Samba 3.0, and even Samba 2.2, was pretty good at handling all the details you need. This includes its own SAM stores for even _multiple_ domains -- ideally in an LDAP store (hence the Samba 2.2 and 3.0 schema for LDAP). It can provide the Kerberos chat that Windows clients expect (as well as a native Windows ADS DC, if native Windows ADS DCs already control your network). And some RPCs have been reverse engineered so you can use _some_ NT5.x (2000+) Windows tools to modify things, but not nearly as well as the older NT4.x (NT4.0) tools. And there are both web and traditional GUIs for maintaining Samba 2.2 and 3.0 LDAP schema, including managing users, groups, domains, etc...
Forget LDAP.
Then what are you going to use for your network store?
Kerberos only does authentication and ticketing. You still have to distribute information network-wide, be it with NIS, NIS+, LDAP, etc..., for even UNIX/Linux clients.
Yes, i know the openldap guys have not shown much interest in adding MS-LDAP rpc stuff.
Well, I'm not even looking at OpenLDAP anymore, now that Netscape Directory Server is available as GPL as Fedora/Red Hat Directory Server. Red Hat's purchase of NsDS basically said they don't think OpenLDAP is worth developing any further (and I had been asking for this years ago ;-).
eh?
I think you keep thinking that you have to have a 100% MS ADS DC equivalent. I don't think you realize from the standpoint of a Windows 2000/XP "client," the "domain" is really not much.
That requires a different GINA right?
Yes and no.
Samba 2.2 and, 3.0 even more so, can use the _stock_ Windows 2000/XP GINA, and provide services to it. Logon, tokens, etc... Samba will uses its store (typically LDAP for Samba 3.0 with added ADS assumption compatibility, multiple Windows domains, etc...) and Kerberos for the password store and services to Kerberos clients (and a Kerberos client if its talking to an existing Windows ADS DC -- that's the delimiter).
But if you don't want to deal with all the Windows client "assumptions," you can replace its GINA, yes. Then you can provide more "raw" authentication -- local UNIX, NIS, NIS+, Kerberos, LDAP-stored hash, etc...
Right, so what open source option(s) do we have to single-logon Kerberos? (please assume apps are also kerberosized)
Kerberos _never_ provides "logon" facilities. Kerberos provides the authentication and ticketing portion for "logon" facilities.
Samba's RPC capabilities can _use_ Kerberos' logon facilities to provide for the "assumptions" of Windows clients who think they are in a "domain." Again, you have to think about what a domain is, from the standpoint of a Windows client.
Of course, if you have a native Windows ADS DC on your network, then you are _forced_ into providing the same services it provides. Hence the delimiter -- once you introduce *1* ADS DC, Samba can't play without it. If you don't, Samba can do what it wants to make Windows clients happy -- even Windows 2000/XP quite nicely.
I don't think you're seeing that.
-
Bryan J. Smith -
Feizhou