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 b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;->