PASSDB: local and domain accounts

[Simo Sorce]

Gerald Carter wrote:
> 
> Folks,
> 
> Here are my current thoughts on winbindd, passdb, group
> mapping, etc... (after talking with JF and Tim).  Comments
> welcome :)
> 
...
snip
...
> This gives us a nice distinction between local
> and domain accounts.  Here is my taxonomy:
> 
>   o security = user
>         - Samba as a standalone server
>         - Samba as a PDC
>   o security = domain
>         - Samba as a BDC
>         - Samba as a domain member
> 
...
snip
... 
> 4)
>   o NT as a BDC replicates the domain SAM into a
>     copy in the local sam
> 
>   + Samba as a BDC should replicate the domain SAM
>     into a copy n the local passdb storage

BDC as PDC has only one local db (replicated from PDC)
why you put it in "security = domain" section and not in "security =
user" section?

> Group mapping should be integrated into the passdb
> for local accounts.  This would fit with what
> Jean-Francois has already started on.  The winbindd
> daemon already handles mapping between remote domain
> accounts and the dynamically allocated gid.
> 
> Here are some thoughts from Tim...
> 
...
snip
...
> 
> >  - use winbind users and pam_winbind
> 
> winbindd can point to a local Samba PDC running on the
> same host.
> 
> > Be able to choose combinations of all the above
> > as required.  The appliance is a good example - it needs
> > to be able to use local passwd users and winbind users as
> > a domain member but not display any local users itself.
> 
> So for our network appliance example, as a domain member
> you will have accounts in \\DOMAIN and \\SAMBASERVER.
> Viola!  The above proposed solution works.
> 
> There is one minor problem.  Really it has not so much
> to with Samba as it does with winbindd and pam_winbind.
> Consider the case where you would like to configure sshd
> for authenticating against remote domain accounts.
> This is only case when operating as a domain member
> (not as a PDC).
> 
> In this case, winbindd will only check against domain
> accounts.  However, I can envision cases where you would
> want to validate against local Samba accounts as well.
> There is currently no way to access these.
> 
> No you may be thinking to yourself, "but local
> Samba accounts already exist in /etc/passwd.  You can
> use those."  However, consider the unification of
> passwords.  What if the Samba lanman/nt password is
> different than /etc/passwd?  Also consider the case
> of uid allocation upon demand for creating new local
> accounts in samba.  These would never exist in
> /etc/passwd.  Only as a uid in a Samba TDB.

Hey, wait!
You mean that local passdb and /etc/passwd will be unallineated?
Generating local uid only in local passdb and not in /etc/passwd
may cause big troubles.
How do you serve files to users not present in /etc/passwd?
what about file permissions and ownership?
What happen if a user created on /etc/passwd maps to the same uid
of an existent local passdb user will the samba user be able to read
/etc/passwd user files?
I think that local passdb users should always be present in local
/etc/passwd (also through nis or other nss modules).

> 
> This problem can be solved in one of two ways:
> 
>   1) make winbind check local accounts on the
>      samba server (via MS-RPC) as well as domain
>      accounts on the PDC
> 
> or,
> 
>   2) develop as pam_passdb.so and nss_passdb.so
>      module.
> 
> I like #2 better as it maintains the distinction
> of passdb handling local accounts and winnbindd
> handling remote accounts.
> 
> What is required to make all this work is an account
> management tool.  The following functions implemented
> by the passdb API are used to actually update persistent
> storage
> 
>         BOOL pdb_update_sam_account(SAM_ACCOUNT*);
>         BOOL pdb_add_sam_account (SAM_ACCOUNT*);
>         BOOL pdb_delete_sam_account (char* username);
> 
> If you want to add update capabilities to the passdb
> (/etc/passwd for example), then you write these routines.
> Currently the pdb_add_sam_account() call for smbpasswd
> requires that the UNIX account already exist.  The 'add
> user script' is called before pdb_add_sam_account() is.  This
> should be moved below the API.  smbd should not have to
> worry about this.  By moving the 'add user script' to
> a lower layer, things like "smbpasswd -a <user>" will work
> even if the UNIX account did not exist beforehand.
> 
> Make sense?  We can support user manager as tool.  If so,
> the I really think that we should follow the rpcclient /
> samedit path as well.
> 

As stated before I think local accounts should always be present in
/etc/passwd and /etc/group (Only users and group not machine accounts)
to avoid confusion and uid overlapping.
A standard set of functions should be used to create users on local
/etc/passwd (or equivalent) and this set of calls may use an
add_user_script if told so (or do nothing if nss_passdb is to be used; I
think this solution is the better and should be proposed as default for
PDC-BDC samba servers).
We should also define a configurable uid range to be reserved on
/etc/passwd to generate global users mappings (for domain members) but I
think again nss_passdb+pam_winbind should be highly recommended.

Just my 2 eurocents ;)

Simo.

-- 
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
-----------------------------------------------------------------
Be happy, use Linux!