PASSDB: local and domain accounts

[Gerald Carter]

Simo Sorce wrote:
> 
> > 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 in 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?

A BDC should be configured by 

	security = domain
	domain logons = yes

You are in effect saying, I'm getting the accounts from 
a PDC.  And since I can authenticate domain logons, that
should make be a BDC.  (Or we need to come up with a better 
way of defining behavior)

The fact is that the BDC gets the entire SAM from 
the PDC and store a copy of it locally.


> > 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
                                       ^^^^^^^^^^^
Should be "synchronization"

> > 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?

ok.  Think for a second.  Have I ever advocated the removal
of Samba's dependence on UNIX uids?  Nope.  :) btw...that 
proposal is being discussed on tng-technical right now
if anyone is interested.

> 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?

You do not need an entry in /etc/passwd per say.  Rather 
just a uid.  Think about for a second.  Have you ever
deleted an entry from /etc/passwd and later found files
that only showed up a uid in the output from '/bin/ls -l'?
Same principle.  

Take a look at the winbind implementation first.  Read the 
paper Tim and Andrew wrote on samba.org.  Winbindd allows
you to define a range of uids and gids from which it can 
allocate as necessary for domain accounts.  This mapping
is stored in a TDB.

Since you as the sysadmin have defined the range to be used,
the only way you can have a conflict with an entry in 
/etc/passwd is if you do it yourself.

> 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?

See above comments.

> I think that local passdb users should always be present 
> in local /etc/passwd (also through nis or other nss modules).

If my explanation above doesn't convinve you of my intent,
let me know and I'll try again.


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

Huh?  Winbindd does this now.  I don't see your point.
You lost me.  Sorry.

Really...read up on the current winbindd implementation
and let's talk again.





Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com/  VA Linux Systems   gcarter at valinux.com
       http://www.samba.org/       SAMBA Team          jerry at samba.org
       http://www.plainjoe.org/                     jerry at plainjoe.org

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )