Commit my stuff to 3.0?

[Andrew Bartlett]

Volker.Lendecke at SerNet.DE wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi!
> 
> 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
asthetics)

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

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

		get_domain_user_groups(p->mem_ctx, &num_gids, &gids,
server_info->sam_account);

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
that's minor.

Andrew Bartlett

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