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.
Any hints?
Wilhelm Meier wilhelm.meier@fh-kl.de 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.
-Dieter
Am Samstag 25 Oktober 2008 schrieb Dieter Kluenter:
Wilhelm Meier wilhelm.meier@fh-kl.de 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, ...
Thanks in advance for any hints!
Wilhelm Meier wilhelm.meier@fh-kl.de writes:
Am Samstag 25 Oktober 2008 schrieb Dieter Kluenter:
Wilhelm Meier wilhelm.meier@fh-kl.de 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.
-Dieter
Am Sonntag 26 Oktober 2008 schrieb Dieter Kluenter:
Wilhelm Meier wilhelm.meier@fh-kl.de writes:
Am Samstag 25 Oktober 2008 schrieb Dieter Kluenter:
Wilhelm Meier wilhelm.meier@fh-kl.de 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 Meier wrote:
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 ...
You probably didn't read slapd.access(5) where it discusses the "filter" form of the <what> clause.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Am Montag 27 Oktober 2008 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
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 ...
You probably didn't read slapd.access(5) where it discusses the "filter" form of the <what> clause.
Thank you for this advice, but it doesn't fully solve the problem:
access to attrs=userPassword,shadowLastChange dn.regex="uid=([^,]+),ou=Benutzer,dc=kmux,dc=de" filter="gidNumber=998" by dn="cn=admin,dc=kmux,dc=de" write by anonymous auth by self write by * none
This limits the authentication to users whose posix primary (!) group hat the gid-number 998 (the dn.regex in the example above isn't needed).
But that's not the whole story. We want to grant access also to those users with one of their secondary (!) posix groups is some special group, e.g. cn=archiv,ou=gruppen,dc=kmux.dc=de
So it must be possible to search for an object of objectclass=posixGroup with the attribute memberUid=<uid>, where <uid> is the value of the uid-attribute of the user, who tries to bind to the slapd. If this search returns one (or more) results, the user should be authenticated.
Wilhelm Meier wilhelm.meier@fh-kl.de writes:
Am Montag 27 Oktober 2008 schrieb Pierangelo Masarati:
Wilhelm Meier wrote:
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 ...
You probably didn't read slapd.access(5) where it discusses the "filter" form of the <what> clause.
Thank you for this advice, but it doesn't fully solve the problem:
access to attrs=userPassword,shadowLastChange dn.regex="uid=([^,]+),ou=Benutzer,dc=kmux,dc=de" filter="gidNumber=998" by dn="cn=admin,dc=kmux,dc=de" write by anonymous auth by self write by * none
This limits the authentication to users whose posix primary (!) group hat the gid-number 998 (the dn.regex in the example above isn't needed).
But that's not the whole story. We want to grant access also to those users with one of their secondary (!) posix groups is some special group, e.g. cn=archiv,ou=gruppen,dc=kmux.dc=de
So it must be possible to search for an object of objectclass=posixGroup with the attribute memberUid=<uid>, where <uid> is the value of the uid-attribute of the user, who tries to bind to the slapd. If this search returns one (or more) results, the user should be authenticated.
This approach can be solved by sets. http://www.openldap.org/faq/data/cache/1133.htm An search the mail archive, there can be found numerous examples.
-Dieter
Dieter Kluenter schrieb:
This approach can be solved by sets. http://www.openldap.org/faq/data/cache/1133.htm An search the mail archive, there can be found numerous examples.
The linked document does not exist.
Marc
Marc Patermann hans.moser@ofd-sth.niedersachsen.de writes:
Dieter Kluenter schrieb:
This approach can be solved by sets. http://www.openldap.org/faq/data/cache/1133.htm An search the mail archive, there can be found numerous examples.
The linked document does not exist.
Thank you Marc, the 'l' has been somehow dropped, this is the correct link: http://www.openldap.org/faq/data/cache/1133.html
-Dieter
----- Wilhelm Meier wilhelm.meier@fh-kl.de ha scritto:
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.
Is the application binding? If it is, you can restrict what data its identity can access using ACLs (see the "filter" form of the <what> part of ACLs in slapd.access(5)).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
openldap-software@openldap.org
-
Dieter Kluenter -
Marc Patermann -
Pierangelo Masarati -
Wilhelm Meier