A late response, but this is my supplement to the following KB article
Barracuda allows the LDAP query to be customized. In the end, I decided that LDAP from Barracuda was not usable, given the limitation of SmarterMail LDAP. This is what I learned in the process,.
The list of LDAP attributes supported by SmarterMail is undocumented and appears to be unknown.
Here is a list of the attributes that I have confirmed can be recognized by the SmarterMail LDAP server. There may be others. Curiously, I could not find the LDAP attribute name for the "City" portion of a mailing address.
- c: (country)
- cn: (common name)
- o: (organization)
- otherMailbox: (same as mail)
- postalCode: sn: (surname)
- st: (state)
- uid: (user portion of email address)
Configuring LDAP Data from the SmarterMail GUI
In previous versions, a mailbox import would populate name components (first, middle, last, suffix), but these values could not be configured from the GUI. I suspect that is still the case.
LDAP scope: are all addresses visible, as long as they are Global Catalog visible?
Unfortunately, No. My testing indicates that LDAP returns usernames and alias names, but not Mailing List names, even though my configuration says to include Mailing Lists in the Global Catalog. Barracuda does not support use of an explicit user list combined with an LDAP list, so there is no viable workaround.
LDAP query syntax
Barracuda uses this LDAP query by default:
Since SmarterMail LDAP server does not recognize the attributes for proxyaddresses or userPrincipalName, it seems best to omit these from the LDAP query, even though my testing found no failures caused by the extra attributes. The sufficient query is
I have domain aliases, which are now supported by the SmarterMail LDAP server. However, Barracuda gets confused when I search for username@aliasdomain becauser SmarterMail returns a result of mail=username@primarydomain.
The workaround is to modify the Barracuda field "LDAP UID" to use "uid" instead of "mail". This performs a match on just the username portion of the email address, which solves the problem.
What we need:
- Mailing List names to be visible in LDAP
- ObjectClass to be supported, so that we can filter for user accounts, alias names, and mailing list names independently.
- A UserDisabled flag so that disabled users can be excluded from the LDAP query, whether disabled explicitly or disabled from receiving mail due to quota exhaustion. I do not think there is any standardized atttribute name for a disabled account. For active directory, not-disabled is detected with this LDAP syntax: