samba - Aug 2004 - Clarification on a few concepts, for a FAQ I'm writing

Hi All,

I am currently writing a FAQ that provides an overview of available
options for authentication backends which can potentially be used with
Samba.  Initially I was looking into these issues for my own use, but
I figure that if I document my findings then it may save others some
headache :-) From the Official Samba-3 HOWTO: "Samba offers the
greatest flexibility and choice of account databases of any SMB/CIFS
server technology available today".  However, with this flexibility
comes a degree of complexity - I seem to have hit a wall in my
understanding of how a few bits and pieces fit together.  I'll explain
things as I understand them and highlight the questions I have for
each section - if I'm wrong anywhere, by all means go nuts and show me
where/how.  Hopefully if someone knowledgeable answers these
questions, anyone else who has similar uncertainties will benefit as
well :-)

**********
Assertion 1
**********

As far as I have been able to derive, in a situation where one wishes
to use accounts stored on an existing Windows Server, there are two
options:

1) "Simple" authentication redirection.

It is necessary to create and maintain matching user accounts on the
Samba side to make sure each client has a valid Unix User UID and
Group ID (GID) to map to. This can either be done manually, or
automated by specifying an "add-user" script in smb.conf which gets
run when a user is added on the Windows box.

--
My Question: Can this be achieved simply by using "security = domain"
in smb.conf and pointing to the WINS address of the Windows box that
stores the account information, or is WinBind required somewhere in
this picture?
--

2) "Advanced" authentication redirection.

There is no need to set up matching user accounts on the Unix side.
The winbind daemon automatically assumes control of operations
performed on the Samba machine by generating and maintaining the
'winbind_idmap.tdb' file for appropriate mapping of UID and GID to
Windows ? SID's, using UNIX UID's/GID's from within a pre-specified
range configured in smb.conf.  The accounts are never actually fully
created locally.

--
My Question: WinBind is obviously needed for this, but is PAM
necessarily required?  As far as I can tell, it's not, because WinBind
is able to interact with the Windows box appropriately all on its own
(i.e. handing off authentication duties to the Windows box and doing
all the necessary mappings).  All we need to do here is modify
'nsswitch' appropriately, set up WinBind in smb.conf with the UID/GID
range to use, and start 'winbindd'. No WinBind/PAM interaction
required, correct?
--

**********
Assertion 2
**********

If we want to provide access to services (e.g. ssh) on the Samba box
for users that _only_ have accounts on the windows machine (i.e. no
local accounts on the Samba box), _this_ is when we need PAM and
WinBind interaction.  This requires installing the 'pam_winbind.so'
module that comes with the samba distribution, and setting up PAM to
relay login requests to the Windows box through WinBind.  This
essentially extends the local user database to incorporate the user
database on the Windows box, for that service (ssh).  Correct?  And
the same principle could be applied to any other PAM-enabled account
database, for ssh or other services, yes?

**********
Assertion 3
**********

This relates to the difference in _function_, if any, between the list
of "Account Information Databases" provided in Chapter 10 of the
Official Samba-3 HOWTO:

plain text
smbpasswd
ldapsam_compat
tdbsam
ldapsam
mysqlsam
xmlsam

and the list in "PAM-based distributed authentication" provided in
Chapter 24 of the Official Samba-3 HOWTO:

/etc/passwd
Kerberos
LDAP
NetWare Bindery
SMB Password
SMB Server
Winbind
RADIUS

--
My Question: As far as I understand, in terms of usage context, both
lists present options for the storage of user/account information. 
The only difference between these is that the first list refers to
account backends that are "built-in" to Samba (provided they are
compiled when installed) and the ones listed in the second list
require PAM to work.  Is this the only difference?  So, one could
essentially choose to use any of the options from either list in
specifying a password backend to use for connection authentication, Is
this right?  If this is correct,  what then is the difference between,
say, the "Built-In" LDAP support and the "PAM-based" LDAP
support (or
the "Built-in" plain text support and the "PAM-based" plain
text
support, for that matter)?  Is this just the obvious answer: "The PAM
options provide more flexibility because of the nature of the PAM
mechanism"?
--

Any help here would be greatly appreciated.  I'm intending to make
this document available on the web for all who are interested, and
will publish the URL when finished.  Thanks in advance! :-)

Regards,
Robert Balbir-Brott

-- 
Thousands of candles can be lit from a single candle, and the life of
the candle will not be shortened. Happiness never decreases by being
shared. - Buddha