| This issue is definitely not 'Fixed'. Cosven yin is right. If you are using an LDAP server that has strict ACLs that prevent anonymous bind to read the LDAP tree, it is still not enough to enter Manager DN user/pass. Here's an example ACL that is granting access to just a few users/groups that have a certain gidNumber. The users and groups with these gidNumbers are given permissions in Jenkins already. }}{{olcAccess: {7}to filter=(&(|(objectClass=posixAccount)(objectClass=posixGroup))(|(gidNumber=1000)(gidNumber=1002)(gidNumber=1003)))
{{ by dn="cn=specialACLUser,dc=example,dc=com" read}}
{{ by * none}} Using that specialACLUser user/pass in Linux internals like /etc/nslcd.conf, /etc/pam_ldap.conf, SSH etc is sufficient to grant auth. Therefore, we know the ACLs work, as does the password.., with the same DN, User and Group OU search bases... why does Jenkins behave differently with the same settings? But to me, here's the bigger bug: even if one creates a special user in the ACL and grants them access to * in the whole LDAP tree, but sets their ACL to 'auth' rather than 'read', Jenkins still throws the same error. This suggests that it is not binding with the Manager DN/pass provided before searching. If you set the ACL for such special ACL userto a system-wide one (no other filtering or DN subtree): to * by dn="cn=specialACLUser,dc=example,dc=com" read yes, it works for Jenkins. But then, if an LDAP-wide ACL that grants 'read' access is required for Jenkins, then it's not safe, anyone who knows this specialACLUser DN can read the LDAP tree anonymously.. In short, Manager DN bind auth doesn't seem to work if you have any sort of ACL set for that user on the LDAP side.. |
