On Mon, 2016-11-21 at 10:19 +0000, msarmadi(a)arissystem.com wrote:
Thank you, You are right about one problem.
However, I believe what you are proposing is not a solution to the problem I'm
talking about. Just because, in the problem I'm addressing, I can't and it is not
possible to use your method.
As I said, the applications we are using are not all of them supporting search or group
check. So for those which does not support your method, I posted this problem. Your
solution is not addressing this problem and is for the case which application supports
No, look. There are two ways to check.
First is where the application does a search for the group, and checks
the dn is in the member attribute.
But *every* application will have a userfilter yes? In that filter, if
you have the memberOf plugin turned on, you are filtering on an
attribute of the user that is their membership to a group. IE
Because you are asking about filtering, obviously you have filtering
capability on the users. Just look at memberOf plugin, and you can then
filter on the users memberOf attribute that shows what group they are
Are you telling me that your application that supports ldap does not
support a user filter configuration option?
Additionally, to support my idea of ACI on Bind, I think having ACI on Bind operation
just like others(read,write,...) has many advantages. I could talk about many things like
improve security. For example think of an environment which you want to protect your
directory from unwanted access, even "bind", based on a policy, time or ip for
Please mention that this mechanism is available in some other products, and also some
vendors have developed policy aware directory or a proxy which adds those to the simple
directory. (e.g. netiq edirectory or ldap proxy) I mean this need / requirement is actual
You already can control bind by time and ip in the directory, but not
easily at the same time as attribute I don't think. Plus aci's are not
the answer here IMO.
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Red Hat, Brisbane