The Lightweight Directory Access Protocol LDAP can be used to communicate with Microsoft Active Directory service to authenticate web console users. Under this authentication provider configuration, a user's username and password must match their domain username and password exactly.
Here is more detail regarding each of the fields you see when creating a new authentication provider of this type.
Name: A label for this particular configuration.
Provider Type: Currently, only LDAP for Active Directory is supported.
Servers: A list of servers used for validating administrative user credentials. The list will be tried in order. The names should be separated with commas or newlines and may be either IP addresses or host names.
Encryption Protocol: DeepSurface requires that any communication with LDAP servers be encrypted. There are two types currently supported.
Port Number: The TCP port number of the LDAP service corresponding to the encryption protocol chosen, generally 636 for SSL/TLS or 389 for StartTLS.
Windows Domain: The Windows domain of users associated with this Authentication Provider.
For example, suppose the Windows domain is ACME and there is a user, alice, associated with that domain. Alice's password will be validated by an attempted LDAP bind as ACME\alice (with the user, alice, entering their password).
If the field is left blank, each user account's username must configured with the form [Domain][user name], or in Alice's case, ACME\alice. You might want to do that if you have multiple domains where a single set of domain controllers can authenticate users for all of those domains, which would allow you to have just a single Authentication Provider configuration.
If you specify a domain, then each user account's username must not include the domain name. In the example, if the administrator set the domain to ACME, then Alice's username must be set to "alice" and Alice would enter this exact string as the username during login. This is configuration is simpler for users to remember, but would require a separate authentication provider configuration for each domain.
Trust on First Use (TOFU): If an LDAPS or LDAP/StartTLS service presents a certificate that isn't signed by a known certificate authority (e.g. a self-signed certificate), then DeepSurface will reject this certificate (unless TOFU is enabled) and the authentication provider will be rendered non-functional.
Visit the Trust on first use (TOFU) to learn more about how it works and what the limitations are. TOFU allows for a much simpler deployment while minimizing the window of opportunity for man-in-the-middle attacks. However, in high-security environments, DeepSurface Security recommends TOFU be disabled and that every service be configured with a signed certificate from a trusted certificate authority (CA). If your organization maintains an internal CA, you can add the CA certificate on the certificates administration page.