Overview of Administrator Login Methods and Configuration
Introduction
The EgoSecure Management Console provides multiple authentication methods to accommodate different environments and security requirements. Administrators can log in using local credentials, Active Directory accounts, legacy SSO, or Kerberos SSO. Login behavior is influenced by the selected checkboxes in the login dialog and can be configured at the server level via registry keys.
Before you start
- The Console login UI is intentionally generic (Server, Port, Login, Password) to support all authentication types.
- Using AD or Kerberos SSO is recommended for enterprise deployments for improved security and simplified login.
- Future updates may provide a native admin option to select login type, but currently, registry keys control behavior at the server level.
Starting Point
After launching the EgoSecure Management Console, administrators are typically presented with the login dialog. This dialog provides a simple and consistent interface to enter the server, port, login, and password information. Depending on the configuration and selected options, the login dialog can support local credentials, Active Directory credentials, or single sign-on (SSO) methods such as legacy SID-based SSO or Kerberos.
Below, we show an example of the Management Console login dialog:
Login Methods Overview
Username & Password
The console allows login using username and password, which can either be local EgoSecure credentials or Active Directory (AD) credentials. This method requires the Use username and password checkbox to be selected in the login dialog.
Local Credentials
- Authentication is performed against local EgoSecure accounts.
- Security depends on password complexity and HTTPS usage.
- No special registry key is required.
- Provides flexible login for small deployments or environments without AD integration.
Active Directory Credentials
- Administrators can use their existing AD accounts to log in, centralizing identity management and enforcing domain password policies.
- Requirements:
- User must be an AD-configured EgoSecure administrator or super administrator.
- Console connection must be secured via HTTPS.
- User must have “Access this computer from the network” permissions on the EgoSecure server (Local Security Policy or GPO).
- Required Registry key: WindowsAuthenticationOn = 1
- Username must be entered in domain\username format.
Single Sign-On (SSO)
When the Use username and password checkbox is not selected, the console attempts single sign-on (SSO). Two types are supported:
Legacy SSO
- Automatically authenticates the currently logged-in Windows user using the SID-based mechanism.
- Simple and convenient for small or single-domain environments.
- Less flexible for multi-domain or multi-tenant environments.
- Registry key: AllowSSOAuthentication (0 = disable, 1 = enable)
Kerberos SSO
- Provides strong, ticket-based authentication, integrating seamlessly with enterprise identity infrastructures.
- Uses Windows user’s Kerberos tickets (TGT and Service Tickets).
- Requirements:
- User must be an AD-configured EgoSecure administrator or super administrator.
- Server and clients must be able to reach the Key Distribution Center (KDC) to obtain and validate tickets.
- Console connection must be secured via HTTPS.
- Legacy SSO must be disabled (AllowSSOAuthentication = 0 Registry key).
- Registry key: KerberosAuthenticationOn = 1
- Checkbox Use username and password must remain unchecked.
- Recommended for enterprise SSO deployments.
Security Considerations
Local Credentials
- Flexible login option for local credentials.
- Security depends on password complexity and HTTPS usage.
Active Directory Credentials
- Centralized identity management reduces password sprawl.
- Password policies are enforced via the domain.
- HTTPS is required to protect credential transmission.
Kerberos Authentication
- Stronger authentication compared to legacy SSO.
- Ticket-based (TGT and Service Tickets) SSO ensures secure identity verification.
- Requires network access to KDC.
- HTTPS is required for secure communication.
Legacy SSO
- Automatically authenticates the logged-in Windows user.
- Simple but less flexible in multi-domain or multi-tenant environments.
- Can be disabled if Kerberos or AD login is preferred.
Login Options Comparison
The following table provides a side-by-side overview of all available login methods in the EgoSecure Management Console. It summarizes the security level, requirements, and registry keys for each option, allowing administrators to quickly assess which method best fits their environment.
| Login Option | Security / Authentication Strength | Requirements | Registry Keys | Notes |
|---|---|---|---|---|
| Username & Password (Local) | Standard password-based authentication | User must know local credentials; Console via HTTPS recommended | None (local credentials only) | Flexible for small environments; security depends on password policy |
| Username & Password (AD) | Centralized authentication, password policies enforced | User must be an AD-configured EgoSecure admin; Access this computer from the network; HTTPS required | WindowsAuthenticationOn = 1 | Enter username as domain\username; checkbox Use username and password checked |
| Legacy SSO (SID-based) | Medium, automatically authenticates logged-in Windows user | User must be logged in to Windows; multi-domain setups may be limited | AllowSSOAuthentication = 1 (0 to disable) | Simple, but less flexible for multi-tenant/multi-domain environments |
| Kerberos SSO (New) | Strong, ticket-based SSO | User must be an AD-configured EgoSecure admin; User must have valid Kerberos tickets (TGT/Service tickets); server must reach KDC; HTTPS required | AllowSSOAuthentication = 0 (disable legacy SSO), KerberosAuthenticationOn = 1 | Checkbox Use username and password must be unchecked; best for enterprise SSO |
Registry Keys
This section lists all registry keys that control authentication behavior on the EgoSecure Server. These keys allow administrators to enable or disable specific login methods, configure Active Directory and Kerberos authentication, and manage legacy SSO.
- To add the registry keys, open the Registry on your Endpoint Data Protection server
- Navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EgoSecureServer\Parameters
- Add one of the following registry key, depending on your requirement
| Key | Type | Values | Purpose |
|---|---|---|---|
WindowsAuthenticationOn |
DWORD (32-bit) | 1 = enable AD credentials login | Required for AD logins using username/password |
AllowSSOAuthentication |
DWORD (32-bit) | 0 = disable legacy SSO, 1 = enable | Controls whether legacy SID-based SSO is allowed |
KerberosAuthenticationOn |
DWORD (32-bit) | 1 = enable Kerberos SSO | Enables Kerberos authentication; requires AllowSSOAuthentication = 0 |
Recommended Configurations
Based on common deployment scenarios, this section provides guidance on configuring login methods for optimal security and usability. It includes recommendations for enabling AD login, Kerberos SSO, and disabling legacy SSO where appropriate.
AD Credential Login
- Enable WindowsAuthenticationOn = 1.
- Check Use username and password in the login dialog.
- Enter username in domain\username format.
Kerberos SSO
- Disable legacy SSO: AllowSSOAuthentication = 0.
- Enable Kerberos: KerberosAuthenticationOn = 1.
- Ensure Use username and password is unchecked.
- Ensure clients and server can reach the KDC and obtain valid tickets.
Disable Legacy SSO
- Set AllowSSOAuthentication = 0.
- Users attempting legacy SSO will receive: “This authentication type is not allowed”.