Sorry about that. I'll check and see if there are any docs on it.
First off, we are moving away from the bind template, and moving to a more generic search filter approach. I'll explain the bind template first, then what we will have in the next release.
The bind template is used to map a username into a DN that we can bind against in any external LDAP server to authenticate the username.
For example, in our system, "firstname.lastname@example.org" is stored in LDAP as:
If "email@example.com" in *your* system maps to:
then your bind template would then be:
When a user tries to login, we take the username they type at the login prompt (or pass via the IMAP/POP protocol), apply the bind template, then take the resulting DN and password and attempt to bind in the external LDAP server.
Hope that helps. Let me know if it is still unclear.
The bind template works fine if there is a simple mapping from user's in our system to users in yours. But if you happen to store users in an org fashion instead, then a bind template falls short.
For example, you might have:
It isn't possible to define a simple template to handle both joe and steve, but if you define a simple search filter like:
then we'll do a search using that query, and use the DN from the result to auth against. Depending on your schema, you might want to make that a more complex search, like:
It is also crucial that the search filter only returns a single result. If there is a more then one DN that matches the filter, we'll log an error in the system log and return an auth failure.
As I mentioned, the seach filter approach will be in the next release. The server and admin console have both already been updated.