More proposed passdb changes: users without local unix uids.

[Andrew Bartlett]

Make pdb_add_sam_account() and pdb_upate_sam_account() refill their
buffers

I'm looking into some various changes to the passdb code - the item of
interest to me at the moment is finally killing off the machine trust
accounts in /etc/passwd (but I'm looking at crazy ideas about users not
in /etc/passwd as well).

As such I've made some modifications to the smbpasswd code so that it
can store users without an /etc/passwd entry.  This is done by using the
uids above 6000 and converting them to rids in line with existing
practice.

Of course the uid field never makes it to the SAM_ACCOUNT struct, but
this method is backward-compatible (as far as I can tell) because the
smbpasswd format is unchanged (unless you are a site with over 6000
users in smbpasswd, and I highly doubt there are any, given the
performance problems).

As such, the user is stored with a rid of 0 (which I understand to be
invalid) and they are assigned a new rid when their record is saved.

Anyway, I was looking at what that would imply for the
rpc_server/srv_samr_nt.c:_api_samr_create_user() function.  Firstly I
have modified it to not call local_password_change(), it uses the pdb_
interfaces directly (allowing any of the acb flags to be set from the
client without code adjustment).  

The two issues I can see are:  Should we, on creating a new user, be
setting fields in the SAM based on /etc/passwd entries and defaults
(like full name, profile path) implicitly, or leave these things at
their NULL value.  I assume on NT you are expected to do these manually,
on a passdb backend it doesn't matter (not stored) and on an LDAP
backend it all work because of the 'is default' flags stuff jerry is
doing.  My vote is to extend that kind of thing to tdbsam and leave it
at that.

The other issue is what should the SAM_ACCOUNT look like after an
'update' or 'add' operation has been conducted on it.  I was thinking
that it would be nice if the update also refreshed the SAM_ACCOUNT, so
that it now stored the values that a subsequent 'read' would show.  This
is important because one of those values that *will* change is the rid -
it now has a real value, but also a value that can't be determined
before the 'store' operation.

Anyway, not all of this is finished being written, but I am interested
in comments.

While I'm at it wrapping the pdb_update and pdb_add methods, I'll also
ensure we can kill off/allow non-unix accounts with a simple smb.conf
setting.

I want to do a similar thing with LDAP (which is the backend I actually
want to use), but I'll leave that till I've had a *long* discussion with
Jerry :-).

I'll certainly not commit this until I'm satisfied it a) works, b) fits
in with what others want in this area :-).

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