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

[Feizhou]

Bryan J. Smith wrote:

>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
>  
>
Yes, I was wondering whether you were trying to say that Samba could do 
the extra cruff MS threw into their Kerberos/LDAP/DNS thingamich.

>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
>  
>
So not Samba 3.0 + non-MS Kerberos + non-MS LDAP but Samba directing all 
to an ADS DC.

>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.
>
>
>  
>
:) So how do you provide a non-MS Kerberos single login for Windows 
2000/XP clients where the user account management is centralized?