SmarterMail, LDAP, and Active Directory

Non-SmarterMail Authentication Providers come in two configurable categories: Active Directory (AD) and LDAP. The difference between these two options is more in the authentication process rather than functional differences.

Both providers operate using the LDAP protocol, but the SmarterMail Active Directory authentication provider requires Kerberos/NTLM authentication provided by SSPI (Win) or GSSAPI (Linux) and assumes an Active Directory searching structure. LDAP Providers also operate using the LDAP protocol, but utilize basic authentication and don't assume an Active Directory structure. You can connect to a Microsoft Active Directory using either connector although using the LDAP Provider will require TLS/STARTTLS to connect to Active Directory using basic authentication without explicitly enabling it for the domain.

Basic authentication provided for an LDAP Provider configuration must be a supported fully qualified distinguished name (i.e., cn=admin,dc=testing,dc=local), and supports cn= or uid= scheme usernames as preferred by the target directory. Users added from an LDAP providers will be required to be under the configured Base DN so if "ou=admins,dc=testing,dc=local" is configured as the Base DN, the authentication provider will only resolve users that belong to the "admins" ou. No configured Base DN assumes all users at the root of the server are to be resolved.

Active Directory Providers require service credentials be configured for either Kerberos on Linux or NTLM on Windows for a user/service account capable and authorized to query the directory. Active Directory Providers work similarly to LDAP Provider's Base DN configuration but with just an "Organization Unit" field specific instead of general Base DN. This works functionally identical to the LDAP Providers with the addition of the "Domain Name" configuration, as the rest of the Base DN is assumed from a combination of Organizational Unit and Domain Name.

As a final clarification, OpenLDAP tends to be case-sensitive with properties by default and Active Directory is not. This can cause problems as sometimes "OU=" does not equal "ou=". A list of the currently supported properties for each tested provider are included below.

• LDAP and AD Connections will automatically use the SmarterMail username to attempt to query an authentication provider based on the configured Base DN for LDAP and the Organizational Unit for Active Directory.
  • Prior to these changes, an OpenLDAP connected authentication provider required the username to match exactly what it expected in order to verify that the user exists (i.e. cn=Testing User,ou=people,dc=testing,dc=local) and that functionality didn't work with the refresh token which attempted to search for a user specifically by ‘samaccountname’ which is a property that is only available in an Active Directory LDAP connection.
  • SmarterMail uses a search-first process for AD and LDAP user verification and authentication based on searching for either a samaccountname OR a uid for the specified user. (Where uid is the OpenLDAP equivalent to samaccountname.) As a result the previously required "Active Directory Username" during new-user creation utilizing an authentication provider isn't explicitly required anymore for either Active Directory or OpenLDAP connections.
• SSL/TLS configurations settings have changed, fixing cross-platform TLS and STARTTLS connections across all tested platforms (Debian 13, Windows Server 2025, MacOS) for both Active Directory and OpenLDAP connections.
  • Previously, aggressive certificate chain verification settings and no connection timeouts caused cryptic hangs and failures for both Active Directory and LDAP Connections. The only protocol client in SmarterMail that supports additional chain verification is SMTP Out that has settings that allow it to be disabled, and this authentication provider has been changed to match the majority of the other clients that don't do explicit additional chain verification. This should allow customers leveraging self-signed and/or internal ca certificates to leverage connection encryption more intuitively.
  • The certificate requirements for an authentication provider server are as follows:
    • The certificate for the provider server must be issued by CA trusted by the host running SmarterMail and match the DNS-resolved SNI Hostname entered into the "Authentication Provider" configuration.
  • Additionally, any LDAP connection to an Active Directory provider will deny connections using basic authentication unless the connection is using TLS/STARTTLS unless the server providing the LDAP connection and domain is specifically configured to.
• Linux dependency packaging resolution changes have resulted in hardcoded version-specific references to "libldap-2.5.so.0" being replaced at the OS level with non-version named alternatives ("libldap.so.2").
• Language strings in the "new-user" modal to correctly resolve to LDAP_ACCOUNTNAME for LDAP providers instead of showing ACTIVE_DIRECTORY_USERNAME for both provider types.
• Feedback is now included on the "directory-service-provider" modal to indicate that a request is processing.

Right click and select "Open Image in New Tab" to download this table

• `samaccountname` and `userprincipalname` are Active Directory-specific with no direct OpenLDAP equivalents. `samaccountname` is commonly referenced as `uid` in OpenLDAP implementations and Smartermail is configured to resolve users by whichever property is available depending on the target platform. `userprincipalname` is utilized as a mail address source in addition to the `mail` property and doesn't affect it's usage as an authentication source.
• Password-related attributes (`pwdlastset`/`pwdChangedTime` and `lockouttime`/`pwdAccountLockedTime`) require the **ppolicy overlay** to be loaded
  • These properties are present and populated in an Active Directory environment by default but require and extension in OpenLDAP to provide it's closest-equivalent.
  • Smartermail could be altered to support the OpenLDAP extension properties but currently doesn't. As a result, directory integrated password last set and lockout time variables are not populated.