Commit my stuff to 3.0?
abartlet at samba.org
Sun Oct 13 00:19:01 GMT 2002
Volker.Lendecke at SerNet.DE wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Discussion moved to samba-technical.
> > Instead of just doing a pdb_getsampwnam() on the name from pass struct,
> > I would prefer that we instead change the callers. Most of the callers
> > can be changed to do the pdb_getsampwnam() instead of Get_Pwnam(), now
> > that we have unixsam giving us access to all users. (This is why we
> > didn't do this before).
> To be honest I would like to get rid of the necessity of unixsam for
> encrypted passwords. One case where this breaks: You want a
> workstation to join your domain. You do not want to use 'add user
> script', so you add the wks account to
> /etc/passwd. _api_samr_create_user says user exists, and after that
> set_userinfo creates the account in passdb. And boom, you again have
> algorithmic mapping in your rich passdb backend.
I know why 'only algorithmic' mapping is a pain - we can't do migration
from NT, but why is adding algorithmic RIDs a problem here? (Other than
But yes, this is one of the ugliest parts of the unixsam approach. It
also has implications for the 'add computer to domain' priviage.
Basicly, we have to decided if unix users not in a SAM backend are in
The problem is that we currently allocate them a SID as if they are
members of the domain. And we need to be able to preserve that
allocation, even if we add them to smbpasswd - sombody could have aimed
an NT backup tool at us, and we gave the OLD SID as a the owner, and
when we 'restore' it's 'gone'.
Or we have a domain user, who owns files on a workstation. This user's
smbpasswd record is deleted - should we no longer map that SID to the
users unix name? (Quite possibly the answer is yes). Should users not
in smbpasswd be mapped uid->sid->name at all? Currently we do, and some
NAS products use this behaviour.
Also we have things like users in NIS. Should the mapping change
depending on if the NIS server is up or down? (This may be smbpasswd
with unix users in NIS, or even our SAM in currently unreachable LDAP).
We have many of these problems already, but they get worse when
allocated RIDs are the norm, rather then the exception. Perhaps we
should move SID->uid and uid->SID stuff into a seperate module? This
was somthing we were looking at for the 'new SAM', but maybe we need it
sooner. (It is not dependent on the rest of the work).
Anyway, I'm not saying I have answers to these - but we need to make
sure we can address or dismis these issues.
> I am not sure if metze's new passdb code covers this case, but there
> are so many cases like this where pdb_getsampwnam succeeding just from
> unixsam is not transparent enough for the caller.
No, metze's code just dealt with changing values within a record.
> > Given that we need passdb and groups in 3.0, I woud support merging it
> > in there. In particualar this should simplify greatly the 'name -> sid'
> > and 'sid -> name' code. (Add calls for these to the interface).
> If I started to rewrite the group mapping API, I would like to remove
> the enumgroups call. This is just too ugly for large numbers of
> groups. And people *will* use lots of groups, especially as we do not
> have support for nested groups.
This been certainly needs work. BTW, there is a getgrouplist() call,
which returns, without great expense, the list of groups a user is in.
get_domain_user_groups(p->mem_ctx, &num_gids, &gids,
call in srv_netlogon_nt.c we can actually use the information in the
'server_info' struct. We have it all there already.
> And when automagically creating group mappings, I would like to create
> them as domain groups and not as aliases. I think this is what users
> would expect. It also removes the annoying messages that NT does not
> like aliases as a user's primary group.
I think this is one of the 'not like NT, but what admin expects' things
- and I agree. Possible make groups < 100 'aliases' by default, but
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical