I am not too sure if this is a bug, but a few tcpdumps lead me to believe it is, however if its not, cool.
Description:
On startup wildfire 3.1.0B2 attempts to bind to the LDAP server. A tcpdump reveals that the wildfire server is sending the adminDN but not the baseDN with the result that the bind request will fail as it needs both to autorise the bind.
Workaround:
This problem can be worked around by adding your baseDN to the end of your adminDN;
example:
Reproduction:
Configure LDAP auth. against an known reliable LDAPv3 server.
The admin DN is indeed supposed to be a full DN for the user account. Wildfire doesn’‘t try to append the base DN. So, I don’‘t think this is a bug, but it might not be clear enough in the documentation? I’'ll take a look.
I actually thought that Wildfire 3.1 would have a GUI where one can enter this information during initial configuration.
I usually use the full DN as it makes little sense to specify baseDN: “dc=com” and adminDN: “cn=admin,ou=foo,o=bar” - but one could improve the documentation and describe which rights adminDN needs. These are afaik read-only, so far away from admin rights.