Commit my stuff to 3.0?
Volker.Lendecke at SerNet.DE
Volker.Lendecke at SerNet.DE
Sun Oct 13 07:48:00 GMT 2002
-----BEGIN PGP SIGNED MESSAGE-----
> 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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 3700000
-----END PGP SIGNATURE-----
More information about the samba-technical