PASSDB: local and domain accounts
gcarter at valinux.com
Tue Nov 14 18:06:52 GMT 2000
Here are my current thoughts on winbindd, passdb, group
mapping, etc... (after talking with JF and Tim). Comments
Basically we need to deal with a couple of design problems
(or issues, however you look at them).
o What is the relationship of and interaction between
the local passdb storage and winbindd?
o local vs. domain accounts
I see winbindd and the passdb storage at the same
abstraction layer (with possibly one abstraction
layer covering the two to make them appear as a
single mechanism). So it would appear something like
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
I am ignoring security = share because it is really
just a variant on user mode security from the passdb
perspective. I am also ignoring security = server
because it should be superseded by domain level security.
Now given the way an actual NT host works, we have
o NT as a domain member has a local sam as well
as access to the domain sam
+ Samba as a domain member should have a local list
of account (those stored in the local passdb storage)
and use winbindd for access to the domain SAM
o NT as a standalone server has only a local sam
+ Samba as a standalone server should utilize only
the local passdb storage
o NT as a PDC has no local SAM. Rather the local
sam becomes the domain SAM
+ Samba as a PDC should utilize the local passdb
storage for domain accounts. No local accounts
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
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...
> OK here is a bit more info on some ideas for
> passdb stuff. In my opinion you need to be able to:
> - Read/write/update sam entries in a tdb on a pdc.
> - Read entries from the unix password file (may have to
> store encrypted passwords in an adjuct file).
> - Use local users from the passwd file (may need to
> store encrypted passwords in an adjnct file)
This brings up my next thought: "The relationship between
passdb and clear text authentication."
The combining on /etc/passwd and the passdb
storage into one logical volume is an interesting
problem. I propose the following rules...
o If there is no passdb local storage
implemented, use /etc/passwd as the local
SAM and fake up account information such
as rids, profile path, etc... as we currently
do for smbpasswd.
o if a local passdb storage exists, use **only**
that as the local SAM.
This means that only accounts (and groups) in the
current local passdb storage should be enumerated.
These could be ones from /etc/passwd (if there is
no passdb storage defined) or Samba's own SAM
implementation in a TDB or LDAP.
Now for plaintext authentication, this solution will
still work. I should say that all passdb will work with
plain text passwords. The main distinction made by as
passdb storage module is which accounts should be
considered to be in the local SAM.
This solution will also work for the 'update encrypted = yes'
scenario as well.
Intuitively, things look like this
libpdbpasswd.so /etc/passwd and fake
up SAM_ACCOUNT. This
one is the default in the
absence of any other modules.
libpdbsmbpasswd.so identical in functionality
to libpdbpasswd.so with the
addition of support for
libpdbtdbsam.so full local SAM stored in a TDB
libpdbldapsam.so full local SAM stored in an LDAP
> - use winbind users and pam_winbind
winbindd can point to a local Samba PDC running on the
> 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.
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
2) develop as pam_passdb.so and nss_passdb.so
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
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.
-- 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
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
More information about the samba-technical