Commit my stuff to 3.0?

[Volker.Lendecke at SerNet.DE]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

I do not really like the idea of mixing two approaches. Ok, you can
make reasonably sure that both do not clash with a high enough
algorithmic rid base. Hmm. From a functionality point of view, it is
mainly asthetic. And fearing that we might miss corner cases. Not
giving anything back from pdb_getsampwnam when the user is not in SAM
is much more obvious than a user magically popping up.

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

I would vote for 'NO'.

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

I would not see this as a problem. The same happens if you delete a
user between backup and restore. Messing with the user database kills
backups even under unix most of the time.

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

My solution for this is mapping users not in the 'rich' pdb backend to
S-1-5-33-uid (no typo!). This is the newly created 'local unix
auth'. lookupsid should return 'not mapped', as NT4 would after that
look up 'local unix auth'#1c... W2k shows the SID in plain text, NT4
shows 'local unix auth\account unknown'

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

I remember the word SURS.... ;-) I think this would not help. We will
never be perfect NT, we will always have rough edges. But at least if
the behaviour is known and documented, I would be happy. I need to
*explain* that stuff to people sitting in courses. For this simplicity
is really important.

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

Ok, thanks.

Volker

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 3700000

iD8DBQE9qSSdZeeQha3jd9gRAkK8AJwJAmUZEeOo1k4u9jvQJMtLXovWsQCfVA9u
0G+zQs04cxXKep1s086xxxU=
=D7mS
-----END PGP SIGNATURE-----