Over the last few months, we have slowly been trying to achieve a 'SAM by Stealth'. That is, using the existing passdb code to get something that might approximate a 'real' SAM.
So, the idea is the remove the basis of 'unix uid/gid' from the passdb. We are actually pretty close, but we currently substitute the knowledge of the uid/gid with the ability to getpwnam(). This causes us problems - for one we require two sources of the user data. Furthermore, the calls required become quite expensive - a pdb and nss lookup at the very least. The intention is to replace this with a more elegant solution. This is what IDMAP is about - make the passdb just deal with the NT RID, and the other NT attributes, and have a simple interface that converts *any* SID to a UID. For the purpose of this interface, the local domain is not special. For the purpose of the implementation, we will have two layers: A cache and a backend. The cache will avoid the expensive lookups, and the backend will behave as configured. One configuration option will effectively be 'no change' (winbindd tdb and local 'passdb' lookups), but another option will be things like a pure ldap solution. So, where do groups fit into this? 'Group mapping' breaks this abstraction. Instead, we should have 'groups' - the interface should not tell us *how* the users are put into the groups, or even the unix GID. Instead, we should have: - get users in group - get groups for user - add user to group - delete user from group - set group members - delete group (or something like that). This interface would then wrap the group mapping tdb, for a backward compatible setup, but for LDAP, I would propose we use the following attributes: - cn - rid - memberuid or - uniquemember and play a couple of games to either base this on either posixGroup, if by some strange co-incidence the admin sets these to the same object :-) We should create the right magic in IDMAP to make sure that we always keep this stuff in one record. (ie, the record with the user/group). If not, then create the right ldap magic to cope with our own structural objectClass. I hope that this makes some things clearer. 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
signature.asc
Description: This is a digitally signed message part