refactoring idmap code in smbd
vorlon at netexpress.net
Thu Jul 10 02:08:56 GMT 2003
On Wed, Jul 09, 2003 at 05:06:11PM +0000, Jeremy Allison wrote:
> > The new code has been checked in. Please see
> > docs/README.idmap-and-winbind-changes in CVS for details.
> > I'm sure there will be a lot of discussion on this.
> Adding a password and group database source to winbindd allows
> easy migration of existing NT SAM databases (all the new users/
> sids get auto created by winbindd and are now seen by the rest
> of the system), and also the creation of machine accounts without
> having to have them in /etc/passwd (winbindd creates the entries
> in its own db).
> smbd is greatly simplified as it can always assume that any account is
> really a unix account and a sid mapping exists. When we need a
> new account we use the 'create script' if the admin defined one,
> otherwise the new capability of winbindd to create a user or
> group account if the admin permits it.
Now, the README says:
> 3) New functions have been added to winbindd to emulate the 'add user script'
> family of smbd functions without requiring that external scripts
> be defined. This functionality is controlled by the 'winbind enable local
> accounts' smb.conf parameter (enabled by default).
> However, this account management functionality is only supported in
> a local tdb (winbindd_idmap.tdb). If these new UNIX accounts must be
> shared among multiple Samba servers (such as a PDC and BDCs), it
> will be necessary to define your own 'add user script', et. al.
> programs that place the accounts/groups in some form of directory
> such as NIS or LDAP. This requirement was deemed beyond the scope
> of winbind's account management functions. Solutions for distributing
> UNIX system information have been deployed and tested for many years.
> We saw no need to reinvent the wheel.
So assuming that Samba is configured to disallow creation of accounts
within winbind (in the case of an LDAP-using site that needs consistent
ids, for example), does this mean that there will not be an actual idmap
stored anywhere -- that Samba will simply run the create user script,
which allocates an available uid, and assigns a DOM\user name to that
uid? This is attractive, but dangerous; not only would it depend on
being able to resolve an SID to a name before mapping to a uid, there's
also the issue of username reuse in a foreign domain -- NT is careful to
never reuse an SID after the user it belongs to is deleted, but a
name-based map would let a user inherit any Unix filesystem access
belonging to the predecessor.
Or maybe my understanding is flawed here. Is there something that will
store a direct SID-uid map, in the case of a non-winbind managed
 Caching can alleviate some of the problems here, but it wouldn't
address the case of an SID that doesn't correspond to a trusted domain
-- it still would need to be mapped if ACLs are to be kept intact!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20030709/2750bb79/attachment.bin
More information about the samba-technical