Some notes on IDMAP and GROUPS

[Andrew Bartlett]

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                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030323/02628bbb/attachment.bin