The Advanced LDAP authentication mechanism offers the maximum amount of flexibility when authenticating against an LDAP directory.

When authenticating against Active Directory, try the standard LDAP Authentication first. It is designed specifically for default configured Active Directories when the base DN matches the email address domain (i.e. dc=example,dc=com).

(*) Some people believe that port 3268 is the default LDAP port in Active Directory. This is not true. Port 3268 is used for the global addressbook lookups, it won't work to authenticate against. Use port 389 instead.

When authenticating against the Filetransfer appliance, it need to somehow work out the users email address. This can either be accomplished by having

• LDAP Search Key pointing to the complete email address; or
• LDAP Search Key pointing to the username part of the email address, together with a specified LDAP Domain to build the complete email address

a common misconfiguration happens when the LDAP Search key points to the complete email address, and the LDAP domain is added as well, this will lead to the system trying to authenticate user@example.com@example.com.

If the LDAP Search Key points to the complete email address, leave the LDAP Domain blank.

If for whatever reason, you don't have any LDAP search keys in your directory that neither matches the username part of the email address, or the email address itself, the LDAP authentication won't work. Please use the IMAP authentication option instead.

These examples below are primarily focused around Microsoft Active Directory, but should work with all directories.

The user configured in these examples are

In this example the LDAP directory is configured as follows

Authentication test

This is a pretty standard configuration where the LDAP search key points to the email address and as expected, the users needs to enter their email address to authenticate to the Filetransfer appliance.

For domains with this structure, the Advanced LDAP Authentication mechanism does not need to be used. The standard LDAP Authentication would have worked just as well.

In this example the LDAP directory is configured as follows

Authentication test

This example has another popular Active Directory configuration, with the internal domain being configured as company.local. By specifying the sAMAccountName as the search key, which points to the username only, together with the LDAP Domain, the system will be able to work out the correct email address.

In this example the LDAP directory is configured as follows

Authentication test

When authenticating with john.doe@company.com, john.doe@company.com would be search for in the uid LDAP search key. When authenticating with john.doe, this would actually succeed, but with no LDAP domain configured, the email would be sent From: john.doe, with no domain - which would not work when sending emails.

In this example the LDAP directory is configured as follows

Authentication test

If your users login with something else, like the employee number in this example, unless their email is on the format 12345@company.com, this won't work.

The Filetransfer appliance needs to be able to access the users email address. Either directly or by specifying the domain if the desired LDAP search key only contains the username. But the username in this case must match the username part of the email address.

The first step in troubleshooting LDAP Authentication is to look at your directory with an LDAP browser, such as: http://www.mcs.anl.gov/~gawor/ldap/. This will display the structure of the directory like this:

This is the view from Active Directory from a Windows 2003 system with the domain set as dc=allard,dc=local. The alternative configurations that could possibly work with this directory are