The account name that needs to be matched against the AXIGEN internal user database is the "sAMAccountName" property. This property contains exactly the username required for the login procedure. Having this information will help us set up an LDAP search filter, later on, that will isolate a particular user in the Active Directory structure.
Active Directory doesn’t allow anonymous queries in its database. For this reason, any lookup should be performed by an already existing user in the AD. The returned information will then be forwarded to the proxy service and the authentication will be performed. This user may be a regular one (they have access to the database by default) or the domain administrator, as the one in the example below. In LDAP terms, the value of the Bind DN should reflect a user account that will have to be set up appropriately in the LDAP connector settings.
The search base, which is the top most organizational element, contains all entries we are querying and needs to be known beforehand. Common to all the users, we are trying to authenticate as, is the LDAP path. Since AXIGEN can perform recursive lookups in the directory structure, this top unit may contain any number of smaller organizational units that comprise the actual accounts.
The host name and port should be defined, in a similar manner, as for any other LDAP server. The default port on which the Active Directory can be contacted is the same, 389. The Bind DN field should contain a user account value similar to the one below:
CN=administrator,CN=Users,DC=example,DC=tld
The default location for the "administrator" account in the Active Directory is the "Users" container, right inside the root of the defined domain ("example.tld" in the above example). The password for the used account should be entered as the bind password.
To use a search base that will identify all accounts in the same container as the "administrator" account, the following type of string for its value should be set:
CN=Users,DC=example,DC=tld
The used search pattern must identify particular user entries in the directory. For this reason, the above mentioned value will be used to isolate particular accounts:
(sAMAccountName=%u)
For each database entry we are searching for, this attribute should have exactly the same value as the user name (%u). The variable "%u" will expand as the username.
The server should be configured to use only the first value found in the lookup. This should prevent errors if more than one match is found in a lookup.
Even if users are authenticated in Active Directory, they still need to exist on the back-end servers. If a user account does not exist, the authentication will be successful but the Inbox will not be selected. The only use for an Active Directory account that has no mailbox is to send emails through the SMTP service using authenticated credentials.
If routing is used within the cluster environment (more than one node is present in the background), then a certain property must be defined for all the user accounts in the Active Directory. Any inactive property can be used for this purpose, but it is recommended that one of the extra added properties is used.
The property values should contain the IP address of the back-end server holding the account and the property name has to be set up in the LDAP connector settings. It is very important for all accounts to use the same property as all will be looked-up in the directory by the same connector.
The routing process can be set up using a local file instead of the LDAP connector. This removes the need of manually editing the values in Active Directory and is relatively hassle-free. However, using local files to process the routing information can increase the proxy servers overhead. Moreover, if there is more than one proxy, the same file version must be used across all nodes to ensure the cluster integrity and stability. The synchronization process has to be performed manually after each change.
