- Overview
- Authentication Configuration Changes
- Configuring Active Directory
- Multi-domain controllers in LDAP
- Security requirements
- Multi-domain environment configuration
- Additional resources
Overview
This article focuses on configuring authentication for users logging in to 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 the 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.
Authentication configuration changes
Previous versions (before v6.0)
In earlier versions of the Login Enterprise, user access was managed using two predefined permission levels:
- Administrator: Full, unrestricted access to the Appliance, allowing users to modify settings and configurations.
- Read-Only: Limited access to view the Dashboard, Charts, Events, and export data, with no permissions to modify system settings.
If a user was assigned to both groups, they inherited the higher-level access. For example, a user assigned to both Administrator and Read-Only would receive Administrator permissions.
New version (starting with v6.0)
With the introduction of Role-Based Access Control (RBAC) in v6.0, administrators have the flexibility to create custom roles with specific permissions. This provides more granular control over user access, allowing roles to be tailored to meet specific needs.
To ensure backward compatibility, a migration process automatically creates roles and user groups corresponding to the Administrator and Read-Only LDAP groups, provided you had previously set them up. For details, see Migration of Existing LDAP Groups.
For more information on configuring roles and permissions, see Role-Based Access Control (RBAC).
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:
|
Field |
Value |
|
AD Search Base |
The fully qualified domain name (FQDN) of the domain used for authentication. |
|
Domain controller |
The domain controller responsible for processing the requests. You can configure up to 5 Domain Controllers for LDAP authentication. |
|
Port |
The port utilized for LDAP. |
|
SSL/TLS Settings |
|
|
AD Timeout |
The Active Directory controller's response time. You can extend the default 60-second AD timeout up to 180 seconds. |
3. Click Save Changes to apply your AD authentication integration. Following this, you can log out and log back in using your domain account.
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 fail-over 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
As of Login Enterprise 4.4, multi-domain configurations are also supported. 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 domainname\username format. It will report an authentication failure.
Additional resources
- For troubleshooting login problems with LDAP/Active Directory, see Login problems with LDAP/Active Directory (Note that this is a workaround/temporary solution if you’re using Login Enterprise 5.6, or higher).