PASSDB: local and domain accounts
Simo Sorce
simo.sorce at polimi.it
Wed Nov 15 14:17:46 GMT 2000
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!
More information about the samba-technical
mailing list