Configuring Authentication

Overview

This section focuses on configuring authentication for users logging into the Login Enterprise web interface. This is distinct from Test Users, which are used specifically for running Tests within the Virtual Appliance.

To enhance user access to the Login Enterprise Virtual Appliance, administrators can integrate it with Active Directory (AD). This integration allows for more granular control over permissions within the organization, moving away from the reliance on local administrator credentials.

Login Enterprise supports Role-Based Access Control (RBAC), enabling administrators to define custom roles with specific permissions. RBAC provides flexibility in managing user access, as administrators can create roles tailored to different user needs. For more information on how roles and permissions work, see Role-Based Access Control (RBAC).

Administrators can also specify an Active Directory LDAP Authentication timeout. This feature addresses scenarios in larger, more complex domains where the default timeout of 55 seconds may be insufficient for successful authentication.

Configuring Active Directory

1. In the Login Enterprise sidebar menu, navigate to Other > Access Control.

2. In Access Control, select LDAP from the tab bar menu and provide the following:

3. Click Save Changes to apply your AD authentication integration. Following this, you can log out and log back in using your domain account.

The Multi-Domain Controller in LDAP

The support for multiple domain controllers allows the configuration of up to five domain controllers for LDAP authentication. This ensures that if the primary domain controller becomes unavailable, the system will automatically attempt to connect with the next available controller in the list. The feature enhances the system’s availability and reliability by enabling a failover mechanism across multiple domain controllers (DC).

To configure and utilize it, as a Login Enterprise administrator, you need to have administrative access to the Login Enterprise.

Configuring Multi-Domain Controllers

1. Access the Access Control panel: Navigate to the LDAP settings in your system’s administration console.

2. Update Domain Controllers list: Input the domain controllers in the order of priority in the field Domain controller as a semicolon-separated list. For example: devqadc1.internal.cloudapp.net; qadevdc2.internal.cloudapp.net; devqadc3.internal.cloudapp.net; devqadc4.internal.cloudapp.net; devqadc5.internal.cloudapp.net

a. All DCs must be available, and the configured port (389) must be open.

b. Otherwise, the application throws an error message with incorrect DCs:

3. Save and apply changes: Confirm the settings and apply them to enable the feature.

4. Log off and log in again.

Using Multi-Domain Controllers

Once configured, the system will handle authentication requests across the specified domain controllers without further user intervention.

1. In case one of the DCs is unavailable (stopped), the corresponding info is logged to the IdentitySerever container log:

[19:34:28 INF] Attempting to connect to LDAP server
[19:34:28 INF] Connecting to devqadc5.internal.cloudapp.net:389 (ssl: False)
[19:34:28 ERR] Connection failed to ldap://devqadc5.internal.cloudapp.net:389: Connect Error (Ldap result #91 Connect Error)
LdapException: Unable to connect to server devqadc5.internal.cloudapp.net:389 (91) Connect Error
System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (00000005, 0xFFFDFFFF): Name or service not known
[19:34:28 INF] Connecting to devqadc1.internal.cloudapp.net:389 (ssl: False)
[19:34:28 INF] Connected to LDAP server
[19:34:28 INF] Attempting to bind to LDAP server with username: LEAdminAcct@czdemo.ad
[19:34:28 INF] Binding user credentials
[19:34:28 INF] Bind succeeded, authentication DN: LEAdminAcct@czdemo.ad

2. The same if the port is closed:

[09:50:45 INF] Connecting to devqadc5.internal.cloudapp.net:389 (ssl: False)
[09:50:45 INF] Checking if port 389 is open
[09:50:45 INF] Connecting to 10.0.0.9:389
[09:50:50 ERR] Connection failed to ldap://devqadc5.internal.cloudapp.net:389 due to configured timeout of 5 sec for port open check.
[09:50:50 INF] Connecting to devqadc1.internal.cloudapp.net:389 (ssl: False)
[09:50:50 INF] Checking if port 389 is open
[09:50:50 INF] Connecting to 10.0.0.5:389
[09:50:50 INF] Port 389 is open
[09:50:50 INF] Connected to LDAP server
[09:50:50 INF] Attempting to bind to LDAP server with username: LEAdminAcct@czdemo.ad
[09:50:50 INF] Binding user credentials
[09:50:50 INF] Bind succeeded, authentication DN: LEAdminAcct@czdemo.ad
[09:50:50 INF] Successfully bound to LDAP server

Security Requirements

The minimum requirements for secure AD Authentication / LDAPS (port 636) are:

• Protocol TLS 1.2

• 2048-bit certificate

Multi-Domain Environment Configuration

Login Enterprise supports multi-domain configuration. This setup requires a different configuration of the above AD Authentication parameters.

Because the Group name is not guaranteed to be unique across multiple domains, the Group's distinguished name is required. Thus, the configuration will look more like the example below:

Login VSI has tested and supports using a single parent domain with two direct subdomains. Resources from any domain can be used in this configuration. Users can reside in a subdomain while the domain controller and groups are used from the top-level domain. 

When you have multiple domains and need to specify groups using their Distinguished Names, you need to log in with UPN name format: either just the username or username@domainname.dom. You can’t use the domainname\username format. It will report an authentication failure.

Troubleshooting

Login Problems with LDAP/Active Directory

Issue Overview

When you attempt to log in to the Login Enterprise Appliance using an Active Directory (LDAP) account, the web page initiates a request to the appliance, which in turn executes an LDAP query against the configured directory server. If an unexpected issue occurs within the appliance, it may respond with a 504 Server Error to the web page. It's important to note that this 504 error originates from the appliance's backend service rather than directly from the directory server.

Troubleshooting 504 Server Error during the AD Login Process

This is a workaround/temporary solution. If you have any questions or concerns, contact Login VSI Support at support@loginvsi.com.

If you get errors logging in to a domain, verify that Login Enterprise can talk to the domain at all. For this:

1. Log in to Login Enterprise with the local admin account.

2. In the Sidebar menu, scroll down and find Other > Access Control.

3. In Access Control, verify that you can save your existing AD configuration by clicking Save Changes. (You might need to make a trivial change to test saving the settings).

4. Pay attention to whether the Save Changes action completes within the “AD timeout” setting configured on that page.

5. If your AD test is taking too long, your authentication attempt will take the same amount of time. Our AD test is nothing more than a test-authenticating with the provided user account.

6. Try changing to a different domain controller, in case the one you have currently selected is impaired.

How to Access Log Files

LDAP errors are reported in the Login Enterprise container logs, in the IdentityServer log. You can access the log files in 2 ways:

• From the Sidebar menu > System > Container Status > Download all log files.

• Using SSH to log in to the Appliance as the local admin user and looking at files in /loginvsi/logs.

Look for files named IdentityServer{date-time}.log. For example, IdentityServer20240215.log