In this example, we will illustrate how to configure external authentication via a Windows Active Directory server.

Settings in LDAP Server

We have created a server under the domain sctc.domain.local, defined a group called "developers" and added a user "didac gil" with logon name "didacgil9".

In the figure we can notice that users authenticate with the suffix "@sctc.domain.local". We will have to take account of this value for providing the correct settings in Expedition to complete the user authentication.

Defining LDAP Server in Expedition

In Expedition, we will first define the LDAP authentication server. Only Superusers have rights for server registration or modification.

Approach 1. User needs to enter full logon name

In our case, we our server responds at sctc.domain.local port:389 and we have named LDAP_approach1.

The users that will use this server for authentication belong to the developers group, therefore we have provided the following Search DN: "CN=developers,DC=sctc,DC=domain,DC=local". Contact your Active Directory administrator to verify your correct Search DN parameters.

After saving, we will test the server settings clicking on the diagnostics icon. We will be required to enter an existing user's credentials.

A feedback will be provided with the results of the connection.

Through this approach, users will have to provide their full account name for authentication. In our case, didacgil9@sctc.domain.local will be the user name account required to have a valid authentication.

Approach 2. Server specifies the user suffix

In this case, we will facilitate the user's logon, providing the suffix already in the server settings. This way, a user will only have to write their account name "didacgil9".

Notice that using this approach, all users must share the same suffix in order to be able to validate their credentials.

The LDAP connection is via simple bind connections. We use the user's credentials itself to verify that those credentials are valid.

The credentials are transferred via the request without ofuscation, but the connection is done via HTTPS. However, as pointed out by psuJohn, the request should be moved to a POST request so it is not even stored in the httpd logs.

We will make this change.

When testing the connection, we will provide the user's account and password, and we should be able to get the feedback on the transaction, stating that either all went fine or that there was an error such as not being able to reach the LDAP server or that the provided settings (DN or user credentials) are not valid to authenticate the user.