From: Feizhou
You assume too much and you are not clear enough in what you post.
You didn't even know what a KDC was, so my assumptions were pretty easy to make. You keep saying "Samba, Samba, Samba" over and over like Samba does it all. It does _not_.
Geez....I've been trying to get whether you are saying there was a way to do the whole ADS DC thing without a MS-Kerberos in the mix.
And I've been trying to tell you that: 1) MS Kerberos extensions are now part of UNIX/Linux Kerberos 5 implementations 2) Hence why Samba 3.0 does _not_ provide this, it merely uses it.
So _yes_, you _can_ bypass the need for a native Windows ADS DC on your network! But _no_, Samba 3.0 does not provide functionality for sync'ing Samba DC to MS ADS DC.
It's an "all Samba" or "all MS DC" choice.
How do you get centralized user account management without MS Kerberos?
Again, MS Kerberos are just extensions to Kerberos, ones supported in new, open source Kerberos 5 servers. If they hadn't, then Samba 3.0 would not be able to act as either a member server in a MS ADS network, or emultate a MS Kerberos KDC without one. This has *0* to do with Samba.
There are thousands upon thousands of enterprises running with Novell eDirectory, NsDS, Sun One, etc.. using their own management suite for Windows clients. In many cases, a few are vastly more experienced, featured and superior IMHO.
I think what you're looking for is an experience where all the interfaces and schema are emulated to you can run any Microsoft management tools, tools written explicitly for undocumented MS schema and interfaces. You're looking at the problem from an impossible solution standpoint.
That's the problem.
How do you get centralized user account management without MS Kerberos?
Again, MS Kerberos are just extensions to Kerberos, ones supported in new, open source Kerberos 5 servers.
Ok. Which ones? heimdal? MIT?
If they hadn't, then Samba 3.0 would not be able to act as either a member server in a MS ADS network, or emultate a MS Kerberos KDC without one. This has *0* to do with Samba.
Yeah, I know. But you say Samba could emulate a MS Kerberos and I don't remember see anything about open source Kerberos V implementations such as heimdal or MIT supporting MS Kerberos extensions. So that makes me wonder whether you are trying to say the Samba team is doing their own LDAP and KDC.
There are thousands upon thousands of enterprises running with Novell eDirectory, NsDS, Sun One, etc.. using their own management suite for Windows clients.
and by installing their own GINA?
In many cases, a few are vastly more experienced, featured and superior IMHO.
I think what you're looking for is an experience where all the interfaces and schema are emulated to you can run any Microsoft management tools,
No. I don't care too much about Microsoft management tools so long as there is one under Unix.
tools written explicitly for undocumented MS schema and interfaces. You're looking at the problem from an impossible solution standpoint.
That's the problem.
Could be. That's why I am trying to understand just what part of MS Kerberos can be found in open source Kerberos servers as you say.
On Mon, 2005-07-18 at 08:41 +0800, Feizhou wrote:
Ok. Which ones? heimdal? MIT?
Both have some compatibility with MS Kerberos -- both its non-compliant with Kerberos 5 handshakes/datagrams as well as some extensions.
Can they act like a Windows ADS DC? Of course *NOT*! Why? Kerberos is just the authentication portion, it does not provide RPC services for Windows. Samba uses these newer Kerberos services, with its RPC capabilities, to provide those features at winlogon and other points.
All I'm saying is that if you purposely put on the (actually _invalid_) constraint that Windows systems can only be managed by a combined set of services that act 100% like a MS ADS DC, then there's no point in even discussing this. The idea that every Microsoft administrative tools, schema extension and its tools, etc... will work with a 100% Samba 3.0 (_no_ MS ADS DCs) using Kerberos and LDAP for stores will simply be unlikely in the near future.
But can an set of "open systems" authentication, directory, naming and file services completely replace all the functionality you expect in a well-managed Windows network? Of course! But no, native MS ADS DCs aren't going to listen to it. But MS Windows 2000 Server and even Server 2003 _can_ be "member servers" under it -- just like Samba 3.0 can be a "member server" when true MS ADS DCs are "in charge."
It all depends on what you use.
Bryan J. Smith wrote:
On Mon, 2005-07-18 at 08:41 +0800, Feizhou wrote:
Ok. Which ones? heimdal? MIT?
Both have some compatibility with MS Kerberos -- both its non-compliant with Kerberos 5 handshakes/datagrams as well as some extensions.
Can they act like a Windows ADS DC? Of course *NOT*! Why? Kerberos is just the authentication portion, it does not provide RPC services for Windows. Samba uses these newer Kerberos services, with its RPC capabilities, to provide those features at winlogon and other points.
Please don't cut out relevant stuff. This was purely about account management. I never asked whether heimdal or MIT kerberos can do ADS. The relevant stuff was:
------------------------
How do you get centralized user account management without MS Kerberos?
Again, MS Kerberos are just extensions to Kerberos, ones supported in
new, open source Kerberos 5 servers.
Ok. Which ones? heimdal? MIT?
------------------------
All I'm saying is that if you purposely put on the (actually _invalid_) constraint that Windows systems can only be managed by a combined set of services that act 100% like a MS ADS DC, then there's no point in even discussing this. The idea that every Microsoft administrative tools, schema extension and its tools, etc... will work with a 100% Samba 3.0 (_no_ MS ADS DCs) using Kerberos and LDAP for stores will simply be unlikely in the near future.
Forget administrative tools. Just the plain user account management regardless of administrative tool. Are you saying that a heimdal/MIT Kerberos server will be able to handle Windows 2000/XP clients without having to map kerberos principals to local accounts on each individual machine?
But can an set of "open systems" authentication, directory, naming and file services completely replace all the functionality you expect in a well-managed Windows network? Of course! But no, native MS ADS DCs aren't going to listen to it. But MS Windows 2000 Server and even Server 2003 _can_ be "member servers" under it -- just like Samba 3.0 can be a "member server" when true MS ADS DCs are "in charge."
It all depends on what you use.
So what do we use to do provide the single logon Kerberos environment for Windows 2000/XP clients for an enterprise (you seem to use this for environments where there are hundreds if not thousands of desktops, that is what i mean here)?
On Mon, 2005-07-18 at 16:00 +0800, Feizhou wrote:
Please don't cut out relevant stuff.
On my Treo, I don't always see the whole message when I respond, and I sometimes forget to download the whole thing before responding. I have to manually cut'n paste to bottom-post, and I haven't found a good mail client for my Treo yet (not even Eudora honors many things).
This was purely about account management. I never asked whether heimdal or MIT kerberos can do ADS.
But Kerberos does _not_ do "account management" at all!
Kerberos is a ticketing service, and its KDC is typically used as a password store separate from the platform-specific services (such as LDAP schema for various clients).
If you want account management, you want to deploy a directory service, and store your accounts there. NIS is simplistic in that it acts like UNIX flat files. NIS+ and LDAP offer far more extensive features. LDAP is typically deployed with Samba 2.2 and, more 2000/XP-focused, 3.0 schema so you can manage users, groups, domains, etc... in a single repository, with LDAP tools. There are now a number of web and standalone programs, both free and commercial, that can manage Samba 2.2/3.0 schema in an LDAP tree.
Forget administrative tools. Just the plain user account management regardless of administrative tool.
There is _no_ "universal administrative tool interface" for "any type of account management."
It depends on: A. What your directory service is, how it stores objects, etc... B. What platform you are administering, what objects it expects, etc... C. What interfaces the "administrative tool" expects
I do _not_ have to store the platform object (e.g., SAM) schema in my directory service. I can store whatever schema I want, even something the platform doesn't like, _if_ I replace the authentication/logon mechanism (e.g., GINA).
But let's say I don't want to replace the authentication/logon mechanism (GINA). I still do _not_ have to provide the exact same directory service (ADS' LDAP), I only have to store the platform-specific objects (SAM), and emulate the client platforms interfaces (e.g., Kerberos ticketing, RPC services, etc...). Depending on what level of "support" I want, I can often get away with only a small subset of services.
If I had to guess, you think user management is related
Are you saying that a heimdal/MIT Kerberos server will be able to handle Windows 2000/XP clients without having to map kerberos principals to local accounts on each individual machine?
Of course not! That's not even true on a native MS ADS DC! But on a native MS ADS DC, it does this for you.
But also _same_thing_ with many open and commercial Samba management tools, it handles relating Samba's objects (typically in an LDAP schema/store) to Kerberos principles! This really has *0* to do with Samba v. MS ADS DCs, and 100% to do with your enterprise design and management approach.
In reality, you actually don't have to use Kerberos and a Kerberos store. You could store passwords in the Samba store (e.g., LDAP), and use NTLMv2. But then you don't get all the benefits of Kerberos, agreed.
So what do we use to do provide the single logon Kerberos environment for Windows 2000/XP clients for an enterprise (you seem to use this for environments where there are hundreds if not thousands of desktops, that is what i mean here)?
You have 2 options:
1. Replace Windows 2000/XP GINAs with pGINA, and directly authenticate in a UNIX/Linux Kerberos realm.
2. Don't modify Windows 2000/XP, setup Samba 3.0 with a store for its Windows objects (typically in a LDAP schema), and a KDC. Samba 3.0 will handle the "native" logon process as Windows 2000/XP expects and Samba will service it as a domain member. Now you can manage Samba objects with its administrative tools (and possibly more and more Windows 2000/XP admin tools as Samba emulates more and more Windows Server RPCs).
You can't do _either_ if you have a "native" Windows ADS DC, _period_.
-
Bryan J. Smith -
Feizhou