-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > pdb_smbpasswd and pdb_unixsam both use the code in passdb.c > (pdb_fill_sam_pw()) to construct their SAM_ACCOUNT, and to do uid->sid > mapping. In fact, becouse of this, smbpasswd already uses the gid code > to determine the primary group RID on the fly.
My thought was that pdb_smbpasswd has to tell get_group_from_gid that in this particular case we need the algorithmic mapping. The RID allocator will interfere with the algorithmic mapping for uids for smbpasswd. > > What crazy stuff do you mean? unixsam_update_sam_account? > > That certainly sounds familure. And I'm still looking at the consequences of that hack. I'll tell you what I think later :-) > As long as we have never made an implicit mapping between that uid and > RID, then it's fine. That's what I'm trying to hammer out currently. > One of the ideas with the new SAM stuff is that we always control > this mapping - it's the autoalgoirthmic stuff that kills us here... Diggin through the muddy waters of fallback_pdb_* ... > The only other trick is 'outside modification'. When people put this > stuff into LDAP, they often like to modify it directly. This may be 'a > bad thing', but it's also somthing we must at least tolerate. (I > certainly do it at my site). Therefore having the max rid stuff in LDAP > might be benifitial. Yes. As I said, this was code of about 3 hours. But following Eric Raymond: Release early, release often. Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 3700000 iD8DBQE9lAsYZeeQha3jd9gRAox4AJ0eDQw8c1S05kUclULqA1O3WQ34aACdEAht kPkFtryKEpHxUu+x5u5BBsI= =nBSk -----END PGP SIGNATURE-----
