[EMAIL PROTECTED] wrote: > > -----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'.
My problem with this is the behaviour change - suddenly these things that did work won't, and the need for a uid->SID for more than just smbpasswd users. For example, to construct a meaninful NT_TOKEN, we really need a uid->sid mapping for: force user force group guest account any secruity=share user And I think we should always have an account mapping onto the 500 and 501, administrator and guest. > > 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. My worry is NAS stuff, and fileservers. When an admin adds a password, I'm not sure that they expect a change in SID... > > 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' This could have interesting security implications - becouse each fileserver will be serving rids in the same RID space, and becouse of how NT copies ACLs with a file. When you copy this file back, it's now got permissions in 'unexpected' groups. Under NT these groups would be full SIDs, so be restricted as such - but under this they would map back to gids, which have a different meaning. > > 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. Yes, we need a simple solution, but I'm not sure there is one... Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
