30. General Settings » User Authentication

If you need to configure LDAP, RADIUS, SAML 2.0 (SSO) or HTTP Authentication authentication, or enable pop-up notifications during/after login, open Configuration » General Settings » User Authentication.

USER_AUTHENTICATION

User Authentication Settings parameters:
● User Authorization – Determines how the Authentication Realms (listed below) will be used:
▪ Local accounts – Only authenticates users defined in General Settings » User Management with Authentication = Remote
▪ Local and remote – Also allows authentication of users not defined locally, as long as they can be authenticated by the listed services
● Login Theme – Selects the login page’s visual theme: Blue Legacy (the classic blue-gradient login page), Flat Gray, or Flat Blue
● Persistent Sessions – Enables cookie-based authentication when a user selects Remember on the login page. Once authenticated, sessions for that user skip the login prompt for the Persistent Period set below
● Persistent Period – How long a persistent session stays valid before the login prompt returns: 1 day, 7 days, 30 days, 90 days, or 1 year (default 30 days)
● Authentication Realms – The grid of authentication services. Use Add Service to add an LDAP, RADIUS, SAML 2.0 (SSO) or HTTP Authentication service, Modify Service (or a double-click) to edit the selected one, and Delete Service to remove it. Console queries the services from top to bottom and stops at the first successful login — drag a row up or down to change that order. The grid columns are:
▪ Enabled – Activates or suspends the service without deleting it; clear the checkbox to skip the service during authentication
▪ Service Type – LDAP, RADIUS, SAML or HTTP Authentication
▪ Host / URL – The LDAP or RADIUS host, or the IdP SSO URL for a SAML service
▪ Template Users – The Template User(s) that remotely authenticated users map onto (see the per-service sections below)
● Pop-up Notification inside the Login Window (HTML) – Optional HTML shown in a pop-up on the login page itself
● Pop-up Notification after Successful Login (HTML) – Optional HTML shown in a pop-up immediately after a user logs in

Note

The [Save] button inside a service dialog only records that service in the Authentication Realms grid. Adding, modifying, deleting, enabling or disabling, and reordering services all take effect after you click [Save] at the bottom of the User Authentication panel. Deleting a service requires the Administrator role.

30.1. LDAP

USER_AUTHENTICATION_LDAP

LDAP Service parameters:
● LDAP Host (required) – The IP or hostname of the LDAP server. For SSL connections, use ldaps://<IP>:<port>/
● Timeout (seconds) – How long to wait when connecting to the LDAP server before giving up and moving on to the next Authentication Service (minimum 1, default 5)
● Login Attribute – The LDAP attribute containing the username. Common choices: sAMAccountName or mailNickname for Active Directory, or uid for OpenLDAP or IBM Directory Server
● Base DN – The starting point in the LDAP hierarchy where Console should begin searching for usernames for authorization requests. The base DN may be something equivalent to the organization, group, or domain name (AD) of the external directory: dc=domain,dc=com
● Bind User DN – The distinguished name of an LDAP user allowed to search the Base DN
● Bind Password – The password for the Bind User DN
● Role Mapping – Grid that maps LDAP users to a Console Template User, managed with [Add / Edit / Delete Mapping]. Each row pairs a Search Filter with a Template User; remotely authenticated users without a local Console account inherit the privileges of the matched Template User. Rules are tried top-down — for each row, Console combines its Search Filter with the Login Attribute lookup for the username, and the winner is the first row that resolves to exactly one entry whose password bind succeeds. A blank Search Filter matches any user; a user matching no row is denied. Filter example: |(department=*NOC*)(department=ISP) matches any user in a department containing NOC or exactly ISP — the initial | (pipe) is a logical OR across each parenthesized expression
● LDAP Tester – (collapsed by default) [Test Connection] checks the host, timeout and bind credentials; [Test as User] prompts for a username and password, then replays the full Role Mapping lookup for them, reporting which rule matched and the resulting Template User

Note

For troubleshooting the LDAP Service, try these commands:

✔ tcpdump -i <ethernet interface> -n -X host <LDAP IP> displays the packets exchanged between the Console and the LDAP host
✔ ldapsearch -x -LLL -H “<LDAP Host>” -D “<Bind User DN>” -b “<Base DN>” -w “<Bind Password>” -E pr=2000000/noprompt -o ldif-wrap=no dumps the entire LDAP structure, which helps you find the correct Search Filter

30.2. RADIUS

USER_AUTHENTICATION_RADIUS

RADIUS Service parameters:
● RADIUS Host (required) – IP address or hostname of the RADIUS server
● RADIUS Port – Port on which the RADIUS server listens for authentication (new services default to 1812)
● Auth. Protocol – Select the authentication protocol used by your RADIUS setup (new services default to CHAP):
▪ PAP – Password Authentication Protocol (simple 2-way handshake)
▪ CHAP – Challenge-Handshake Authentication Protocol
▪ MSCHAP1 – Microsoft’s version of CHAP
▪ MSCHAP2 – Enhanced Microsoft CHAP v2
● Shared Secret – The shared secret (password) used to authenticate the Console to the RADIUS server
● NAS-IP – (optional) The NAS-IP-Address sent in the Access-Request, identifying the Console to the RADIUS server. Must be a valid IPv4 or IPv6 address; leave blank to use the backend default
● Timeout (seconds) – How long to wait for a response from the RADIUS server before giving up and moving on to the next Authentication Service (minimum 1, default 5)
● Role Mapping – Grid that maps RADIUS replies to a Console Template User, managed with [Add / Edit / Delete Mapping]. Each row pairs an Attribute Number and Attribute Value with a Template User; remotely authenticated users without a local Console account inherit the privileges of the matched Template User. After an Access-Accept, rules are tried top-down and the first whose (Attribute Number, Attribute Value) pair is present in the reply wins. A blank Attribute Number is a wildcard that matches any reply. When at least one rule is defined, a reply matching no row is denied
● RADIUS Tester – (collapsed by default) [Test Connection] verifies the host, port, secret and timeout; [Test as User] prompts for a username and password, then sends an Access-Request for them and reports the result and the resulting Template User

30.3. SAML 2.0 (SSO)

Single Sign-On lets users authenticate through an external SAML 2.0 Identity Provider (IdP) such as Microsoft Entra ID, Okta, Google Workspace, Keycloak or ADFS. The Console acts as a SAML Service Provider: when at least one provider is enabled, an additional SSO button appears to the right of Log In on the login page and redirects the user to the IdP. Multi-factor authentication is delegated to the IdP.

USER_AUTHENTICATION_SAML

SAML 2.0 (SSO) parameters. The Identity Provider section is expanded by default; Service Provider, Attributes & Roles, Role Mapping and Endpoints are collapsed. Fields marked (required) must be filled before [Save] is enabled:
● SSO Button Description (required) – Friendly name for the provider, shown on the login page’s SSO button menu when more than one provider is configured
● Default Template User (required) – SSO users without a local Console account inherit the privileges of this Template User, exactly like LDAP / RADIUS remote authentication. Role Mapping can override it for specific IdP groups
Identity Provider
● Entity ID (required) – The IdP’s unique identifier (issuer), copied from the IdP metadata
● SSO URL (required) – The IdP endpoint to which authentication requests are redirected
● SLO URL – (optional) The IdP single logout endpoint
● X.509 Signing Certificate (required) – The IdP’s X.509 signing certificate (PEM); assertions must be signed with it
Service Provider
● Entity ID – (optional) Override the SP identifier (audience) presented to the IdP; when left blank, the SP Metadata URL is used as the identifier
● Base URL Override – (optional) External base URL used to build the SP endpoints (ACS, Metadata, Login); set it when the Console is behind a reverse proxy or load balancer whose public address differs from what the Console sees
● SP Certificate – (optional) Service Provider X.509 certificate (PEM); signs AuthnRequests and decrypts encrypted assertions
● SP Private Key – (optional) Private key matching the SP Certificate
● Sign AuthnRequests – Signs the outgoing SAML authentication request with the SP key (needs the SP Certificate / Private Key)
● Require Signed Assertions – Rejects assertions not signed by the Identity Provider certificate (recommended, enabled by default)
● Expect Encrypted Assertions – Rejects assertions that are not XML-encrypted; needs the SP Certificate / Private Key to decrypt them. Off by default — enable only if the IdP is configured to encrypt assertions
Attributes & Roles
● Username Attribute – The assertion attribute carrying the Console username. Leave blank to use the SAML NameID
● Group Attribute – (optional) The assertion attribute carrying the user’s group memberships, used by Role Mapping
● NameID Format – The SAML NameID format the Console requests from the IdP; an editable list with presets emailAddress, persistent, transient and unspecified. Leave blank to send unspecified and let the IdP decide
Role Mapping
● (optional) Grid of per-group overrides for the Default Template User, managed with [Add / Edit / Delete Mapping]. Each row pairs a Group Claim Value (matched against the Group Attribute) with a Template User; rows are evaluated top-down and the first whose group matches the user wins. Users in no listed group keep the Default Template User
Endpoints (register these with your IdP) – read-only; populated after the first [Save]
● ACS URL – Assertion Consumer Service (reply) URL: https://<console-address>/login.php?acs=<id>
● Metadata URL – Service Provider metadata URL: https://<console-address>/saml.php?action=metadata&id=<id>
● Login URL – SP-initiated login URL: https://<console-address>/saml.php?action=login&id=<id>
● SP Entity ID (effective) – The Service Provider identifier actually in use — the Entity ID override if set, otherwise the Metadata URL

Note

Because the Console can be installed on many machines with different hostnames, the Endpoints are derived from the address used to reach the Console (or from the optional Base URL Override), so they appear only after the configuration is first saved. Register the ACS URL and Metadata URL with your Identity Provider, and ensure the IdP releases a NameID or username attribute that matches a Console username, or that a Role Mapping rule covers the user’s group.

30.4. HTTP Authentication

Use this service to delegate authentication to the web server hosting the Console. When the web server authenticates users itself through HTTP Basic Authentication (for example, Apache with mod_auth_basic, possibly backed by an SSO module), the Console trusts the username already authenticated by the web server and logs the user in directly.

USER_AUTHENTICATION_HTTP

HTTP Authentication parameters:
● Template User – Remotely authenticated users without a local Console account inherit the privileges of this Template User