[CentOS] Re: Fix passwd/shadow/group files? -- Samba is not an enterprise directory solution ...

Bryan J. Smith b.j.smith at ieee.org
Sun Jul 17 14:40:08 UTC 2005


On Sun, 2005-07-17 at 22:20 +0800, Feizhou wrote:
> What is this KDC**?

Key Distribution Center (KDC) aka "the key server" for Kerberos.

It is the server that must be the most secure on your network.
My #1 problem with MS ADS is that the KDC is also a RPC server
offering other services, hence hackable, hence a _bad_ idea for
a KDC.

Before you attempt to understand UNIX/Linux and Windows
interoperability, you should _really_ read up on what ADS is really
is:  
  DNS naming
   + MS defined schema LDAP store
     + MS modified Kerberos authentication

In reality, it's only the MS defined schema, and the interfaces around
that schema, that are the issue.  But more on that in a moment.

> Are you then saying that we can get a Samba 3.0 box to be an ADS DC for 
> Windows 2000/XP workstations?

First off, again, Samba is _not_ the "only option" for Windows.
Samba started off as just the Server Message Block (SMB) file protocol.
The other interfaces that have built around it are just for support, but
they are _not_ required if you know how to deploy a set of enterprise 
services.

So, yes, Samba 3.0 with MS modified Kerberos can emulate all the
authentication needs of Windows 2000/XP clients, while its SMB service
provides the file services.  It also has its own, basic LDAP schema,
some of which that can support part of the hierarchial nature of ADS,
along with DNS services -- to a point.

But, if you don't use the default GINA in Windows 2000/XP in the first
place, then you don't need to emulate Microsoft's protocols for
authentication.  By replacing it with Pluggable GINA (pGINA), you can
authenticate Windows 2000/XP against whatever you want.  This can be
Kerberos, but it doesn't have to be -- it can be legacy NTLMv2**.

Then when you provide Samba SMB network file services to Windows 2000/XP
clients, you can complete the authentication/authorization how you wish.
If you want to use local authentication -- possibly because all your
Samba servers are in the Kerberos realm as well, or maybe you're even
using a legacy password store like TDB that is distributed -- then do
ahead!  Samba doesn't have to provide anything other than the SMB
network file service, you can leave everything else to _other_, _native_
services.

People don't seem to separate this fact.  They think they need Samba to
do everything.  In reality, all Samba has to do is provide the SMB
network file services, and maybe some added LDAP schema and interfaces
for a few services, or maybe a few legacy interfaces (NTLM,
NetBIOS/WINS, etc...).  Everything else can be another solution --
including DNS, the Kerberos KDC (which Samba may or may not use
directly, it may use "local authentication" because the individual Samba
file servers are already Kerberos clients), direct LDAP schema and
services, etc...

The key is breaking down what ADS is, what Samba provides, and what you
can do with UNIX and _replacements_ for Windows clients -- e.g., pGINA.
pGINA was largely developed by Bynari, who typically works with IBM
Global Services on providing 10,000+ node _enterprise_ networks with
reliable collaboration systems.  I.e., networks that don't easily do
well with Microsoft ADS-centric services.

That's what "architects" do.  They don't work with "products," they work
with "technologies."  Even Exchange is quite limited (largely a
_client_-side collaboration solution) and many open solutions more
capable (e.g., _true_ "server-side" collaboration solutions).

**NOTE:  Ironically, many legacy client services in Windows 2000/XP
_still_ rely on legacy NetBIOS/Windows and at least NTLMv2
authentication for various capabilities.  You can't turn them off
without breaking a lot, hence why it's not difficult for Samba 3.0
servers to be "member servers."  In a nutshell, even ADS "Native Mode"
is _not_ really "native" -- because Windows clients still use a _lot_ of
legacy services.  The Samba technology-specific docs are very good in
explaining these "limitations" in Microsoft's enterprise design,
especially the client issues when you disable "legacy" things.


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





More information about the CentOS mailing list