Hi John, John Morris wrote: > A simple OpenLDAP ACL won't work. You really should do "ACL" type activity in your LDAP server. PLA doesnt enforce LDAP security (no reason to, as the LDAP server can do that job better). One reason why I have included any "security" type features in the PLA, is so that PLA users dont get the false impression that they are securing their LDAP server (by configuration options in PLA) - as the "smart" user can use another tool to talk directly to the LDAP server to "bypass" anything that PLA can do.
That being said, there was an "allowed_dns" paramater set up to authorise who could use PLA (as you pointed out). It can do a normal filter search on your ldap server, so see if it returns a DN (and thereby authorising the user). I use groupOfUniqueNames for my "user membership", which controls who can log into a host (and therefore, who could use PLA, since it is DNs). It also enables me to setup LDAP ACLs so that if the users "go around" PLA, the LDAP server will still reject those users if they are not in the right group (for the operation they are trying to do). If this doesnt work for you, I'll happily take a patch that enables allowed_dns to use an attribute of the user (eg: uid) and see if that attribute values is also listed in a DN (and thereby authorising the user). For example (&(memberuid=%uid%)(gid=x)) If you dont think you can create the patch, log it as a feature request on SF, and maybe somebody else will create a patch... ...deon ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ phpldapadmin-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/phpldapadmin-users
