Am Sonntag 26 Oktober 2008 schrieb Dieter Kluenter: > Wilhelm Meier <[EMAIL PROTECTED]> writes: > > Am Samstag 25 Oktober 2008 schrieb Dieter Kluenter: > >> Wilhelm Meier <[EMAIL PROTECTED]> writes: > >> > Hi, > >> > > >> > I think this is a relative simple question but I did not use > >> > the meta/ldap-backend before. > >> > > >> > We have an openldap-server for user authentification. The user > >> > bind as > >> > > >> > uid=<user>,ou=Benutzer,dc=kmux,dc=de > >> > > >> > where <user> is the actual username. > >> > > >> > We have a diffent application where only users of a special > >> > posixGroup "Archiv" should be valid. The application is not > >> > capable of doing some sort of filtering. > >> > > >> > So, I thought it must be passoble to do this filtering with > >> > the meta or ldap-backup using the original ldap-db: > >> > > >> > the filter should look like: > >> > > >> > (&(cn=Archiv)(memberUid=<user>)(objectClass=posixGroup)) > >> > > >> > where <user> is the username as above. > >> > >> You don't provide an example of the applications searchstring, > >> so only as a general hint, the rewrite engine of back-ldap, > >> back-meta or back-relay might meet your requirements, man > >> slapo-rwm(5), man slapd-meta(5), slapd-relay(5) provide some > >> information. > > > > The structure of the DIT is that we have the users below > > ou=Benutzer,dc=kmux,dc=de with dn as described above. They are of > > ObjectClass posixAccount, ... > > > > Then we have the PosixGroups below ou=Gruppen,dc=kmux,dc=de, e.g. > > cn=Archiv,ou=Gruppen,dc=kmux,dc=de. The posixGroup objectClass > > has the user-objects as the multi-value attribute memberUid. This > > is the normal case for pam-authentification. > > > > My simple thought was to transparently "filter out" the > > user-objects not belonging to the correct posixGroup: construct > > an DIT where all non-"Archiv" user are not visible, for the > > example above. > > > > The application users should then bind to the meta-ldap uri with > > a different base-dn, e.g. ou=Archiv,dc=kmux,dc=de. > > > > This leads to the generell problem to make all the users of > > posixGroup xyz visible under the ou=xyz,ou=Gruppen, ... > > You may configure back-meta or back-relay, some rudimentary > samples: > > database meta > suffix cn=Archive,ou=Gruppen,dc=kmux,dc=de > uri ldap://<host>/cn=archive,ou=Gruppen,dc=kmux,dc=de > > database relay > suffix cn=Archive > relay cn=archive,ou=Gruppen,dc=kmux,dc=de > overlay rwm > rwm-suffixmassage "cn=archive" > "cn=archive,ou=Gruppen,dc=kmux,dc=de" > > Depending on the authentication framework, you may have to define > rewrite rules for the authentication string.
Sure, but I still miss the point ;-) Consider the following objects: a user: dn: uid=tester,ou=Benutzer,dc=kmux,dc=de objectClass: inetOrgPerson objectClass: posixAccount uidNumber: 1000 gidNumber: 1000 ... another user: dn: uid=tester,ou=Benutzer,dc=kmux,dc=de objectClass: inetOrgPerson objectClass: posixAccount uidNumber: 1001 gidNumber: 1000 ... a group: dn: cn=Archiv,ou=Gruppen,dc=kmux,dc=de objectClass: posixGroup gidNumber: 1010 memberUid: tester memberUid: tester2 ... another group dn: cn=CMS,ou=Gruppen,dc=kmux,dc=de objectClass: posixGroup gidNumber: 1011 memberUid: tester2 ... The application binds with the user-dn (and password). What I want to (must) do is to "hide" all the user-dns who are not in the group "Archiv" for this special application. That is, if their uid is in the memberUid-attribute of the special posixGroup "Archiv", the bind is granted, otherwise not. I don't see how to make this work with the rwm-overlay or some sort of acls. But I'm sure, I missed something ... -- Wilhelm
