[CentOS] Re: Fix passwd/shadow/group files? -- Samba 3.0 v. ADS v. CIFS

[Bryan J. Smith]

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.  ;->