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