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

From: "Bryan J. Smith <b.j.smith at ieee.org>"
> So?  I've been authenticating Samba against NIS servers since
> the mid-'90s ...
> You can even use pGINA to replace your NT/200x/XP login to
> authenticate against other servers ...
> If you are the former, you _can_ switch _away_ from CIFS altogether!
> Samba will _never_ reverse engineer all of Microsoft's LDAP schema ...
> You really need an independent architect to come in and make your
> life easier.  Because it seems your department isn't aware of all your
> interoperability options.
I want to point out one thing.  Understand Samba is a collection of
services designed of and for CIFS/SMB.  It is _not_ a complete
"enterprise directory solution."

Samba includes:  
- A Legacy Registry-SAM compatible password store
- A Legacy NetBIOS-WINS naming service and protocol
- A Legacy NTLM (NT LAN Manager) authentication protocol

And then "wraps into" traditional UNIX services like UNIX
resolver (DNS, NIS, NSSwitch, etc...), UNIX authentication
(files, NIS, PAM, LDAP, etc...), etc...

Newer versions of Samba 2.2 include:  
- MS ADS subset schema for LDAP (OpenLDAP often used)

And Samba 3.0 also introduces:  
- SASL authentication with Kerberos stores (either MS ADS
Kerberos or a MS'ized UNIX Kerberos client/KDC services).

Samba strives to be a "drop in replacement" for a native
Windows DC and file server, including naming (browser)
and authentication.

But you do _not_ have to use Windows-centric naming or
authentication.  You can build a network where you either
are UNIX/Linux NsDS/OpenLDAP "tree'd" with or without
Kerberos, possibly authenticating against native MS ADS
DCs or even Samba emulating ADS DCs, or maybe using
pGINA on the clients, or you can even have a completely
segmented NsDS/OpenLDAP tree/network from native
MS ADS network, and use some synchronization between
the two.

Samba itself is definitely _not_ a UNIX client designed
service.  And even if you have native MS ADS deployed,
you should be running services on the DCs to present
UNIX-like interfaces for authentication, naming, etc...
on the server, not trying adhoc, manual, kludge in things.
And if you're old MS CIFS/PDC, get off of it.  Get your
network to NsDS (now Red Hat Directory Server) before
it's too late -- even if just for your UNIX portion.  Or at
least introduce 23+ year-old NIS for things.

Golden Rule:
The _client_ is always right.

Always present the _native_ interfaces of the client OS
from a server when it comes to:
1) naming
2) directory/store
3) authentication
4) file services

Whether you are a true UNIX, e.g.,
  DNS/NIS, NIS, hash, NFS (NIS)
  DNS/NIS, NIS, Kerberos, NFS (NIS-Kerberos)
  NIS+, NIS+, RSA, NFS (NIS+)
  DNS, LDAP, RSA, NFS (Sun One)
  DNS, LDAP, hash, NFS (LDAP)
  DNS, LDAP, SASL/Kerberos, NFS (LDAP-SASL/Kerberos)

Or maybe a Windows, e.g.,
  NetBIOS/WINS, SAM, NTLM, SMB (CIFS)
  DNS, MS LDAP, MS Kerberos, SMB (ADS)

Or maybe even a Novell, e.g.,
  SAP, Bindery, hash/RSA, NCP (Bindery)
  NLSP, X.500/DAP, RSA, NCP (NDS aka eDirectory)

You should interface with your clients with what _they_
expect, not what your "back-end" is by default.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

>But you do _not_ have to use Windows-centric naming or
>authentication.  You can build a network where you either
>are UNIX/Linux NsDS/OpenLDAP "tree'd" with or without
>Kerberos, possibly authenticating against native MS ADS
>DCs or even Samba emulating ADS DCs, or maybe using
>  
>
Are you saying that Samba can emulate ADS DCs?