Administrator manual¶

Description¶

Excalibur utilizes the user’s smartphone to act as a secure hardware token for any and all authentication and authorization needs. The ultimate goal is to move all forms of authentication and authorization away from passwords, replace them seamlessly with smartphone-based strong but user-friendly multi-factor authentication.

One of the core innovations of Excalibur is its ability to defeat all attacks on credentials as Excalibur is able to automatically change a password on each login. In the Excalibur user flow – the password is no longer entered by the user – the user never even knows the password, it is just a random string used in the background, seamlessly injected into the login process by Excalibur. The user instead just interacts with the smartphone – using it to provide various authentication factors as required by the defined security policy.

Excalibur supports all main platforms and authentication protocols - due to this fact the company can use old applications which require additional integration. To deal with such situations, Excalibur supports an operating mode in which the password does not change automatically (Static mode).

This allows a heterogeneous implementation - e.g. - Login with Excalibur to Windows, or login with a password to old applications which are not the part of SSO Excalibur system

Static Dynamic mode can be configured for selected or all users by the needs of the company.

In static password mode, deployments develop easily and pose no risk to the organization - because a password can always be used.

Architecture¶

Client part¶

Excalibur Token - Excalibur uses the smartphone as a security token, that is why we call the smartphone with the Excalibur application the Excalibur Token. It is used for interaction with the User - entering authentication factors, showing session history, and providing the capability to remotely lock/terminate active sessions. Excalibur Token utilizes phone-based biometry and hardware-backed secure element whenever possible.

Excalibur Client - in the context of Excalibur - Client is an end-point that requires login or authorization of the user via its Token. The client also provides an Excalibur login screen - Excalibur Credential Provider (CP​) which is in case of login into OS launched on the main screen. Clients also mean integration into endpoint SW points, such as integration into VPNs or websites.

Server part¶

Excalibur Server (application) - provides a persistent network & storage central point, must be reachable by all components, also provides the Management Interface - Dashboard as well as WebSDK​ which takes care of communication and operations with integration components.

Excalibur Facade - Active Directory integration component, must be installed on at least one Active Directory server, runs as a system service, and integrates with AD via Directory Replication Service (DRS) Remote Protocol with fallback to LDAP. The user does not communicate with this component.

Excalibur CA (cloud) - The Excalibur Certificate Authority manages intermediate (company) certificates for companies that use the Excalibur Enterprise system. It also issues (user) certificates for Excalibur Enterprise system components in these companies upon request (Certificate signing request). The existence of Excalibur CA in the system architecture is conditioned by two aspects:

• securing and control of licensing - in the form of the period of validity of the company certificate, which is issued only for the contractual / agreed period.
• elimination of single point of failure - placement of the company certificate in the cloud (outside the company administration) increases the security of the system in case of company compromise. In this case, the attacker is unable to issue valid user certificates.

User management¶

User roles in Excalibur Enterprise system- Dashboard.

User - is the end-user who is using Excalibur to Authenticate, Authorize or Verify against the company client by using their token and manages its sessions if the client allows it. The user can also authenticate their colleagues (if allowed and required), change their authentication factors, and also change the expired password on the client (if necessary). Each user can also log in to the Excalibur Dashboard, where a regular user can only see their account details, actions, and sessions.

Manager - In addition to user privileges, the manager has access in the Dashboard to other data related to his account, as well as to the accounts of users he/she manages, and also has the ability to remotely terminate their sessions. The manager cannot change security rules (he can only view them) and also does not have access to multiple parts of the Dashboard, such as groups, roles, security policies, or auditing. A manager is a role that routinely verifies sensitive actions or actions with incidents of his subordinates.

Administrator - in addition to Manager privileges, the administrator has access to all data available in the Dashboard, he also has the right to change security policies, geofences, groups, and other settings for anyone. The Administrator is also the person in the company designated to install and configure Excalibur, as well as the person responsible for configuring the company's environment following Excalibur's requirements. It is the highest user role in Excalibur as well as in the Dashboard.

There are also user roles with specific permissions in the Dashboard, such as Service Desk or Auditor.

It is important to note that even the administrator is not able to edit the history of Excalibur events, such as the event log, timeline, sessions, incidents or verifications, and errors as they occur in the event sequence.

Activities and procedures¶

List and description of administrator activities¶

Excalibur Facade¶

• Installation and update of service system.
• Restart/\Stop in case of crash service.
• Obtaining and sending logs/dumps for debugging purposes

Excalibur Server¶

• Installation and update of the application server.
• Change the configuration parameters of the application server (certificates, ports, log levels...).
• Obtaining and sending logs from clients and facades for debugging purposes
• Monitoring the operation of the Excalibur system via application monitoring.
• Adding (WebSDK) components, changing security policies, group administration…

Excalibur Client¶

• Installation and update of service system.
• Restart/\Stop in case of crash service.
• Obtaining and sending logs/dumps for debugging purposes

List of parameters and configuration files¶

Excalibur Server¶

Directory structure - /opt/excalibur

• 3.2.1* - folder with Excalibur Server aplication files. ( * Number of current installed version of Excalibur Server)
• config - folder contains the configuration files for the server and individual subsystems.
• excalibur.sh - script to start server.
• gorush.sh - script to start gorush server (push messaging).

/opt/excalibur/config/excalibur.json - main server configuraton.

• version - current installed version.
• hostname - hostname of excalibur server.
• port - port settings for individual system components.
• tls - certificate settings for pre https (dashboard).
• database - specific settings for database connector.
• mysql - host, user, password, database, port.
• oracle - host, password, connectString.

Changes in the main configuration will not take effect until the server is restarted!

/opt/excalibur/config/logger.json - logging configuration (e.g. levels).

/etc/logrotate.d/excalibur - configuration of rotation of logged records.

/etc/cron.d/excalibur - crontab for archivation folder with application logs.

The server is periodically restarted every 8 hours to prevent the freeing of allocated system resources. Night mode allows processing manual and zombie sessions.

Excalibur Client¶

Clients (currently) do not have any editable configuration and are delivered preconfigured for a specific company as part of the installation delivery.

Directory structure - C:\Program Files\Excalibur Enterprise

• cache - unsent, temporarily stored application (flow) actions logs.
• data - static data of the application.
• dumps - memory dumps in case of application crash.
• logs - logs from the running application.
• ExcaliburClient.exe - executable file (service) of the client.
• ExcaliburCredentialProvider.dll - library for Credential Provider.
• ExcaliburCredentialProviderUI.exe - executable file for Credential Provider.

Excalibur Client uses its entries in the system registry under the key HKEY_LOCAL_MACHINE \ SOFTWARE \ Excalibur Enterprise \ Excalibur, which must not be edited/deleted, as this would have a direct impact on the client's functionality.

Excalibur Facade¶

The facade (currently) does not have any editable configuration and is delivered pre-configured for a specific company as part of the installation delivery.

Directory structure - C:\Program Files\Excalibur Enterprise AD Facade

• data - static data of the application.
• dumps - memory dumps in case of application crash.
• logs - logs from the running application.
• ExcaliburADFacade.exe - executable file (service) of facade.

Excalibur Facade uses its entries in the system registry under the key HKEY_LOCAL_MACHINE \ SOFTWARE \ Excalibur Enterprise \ Excalibur AD Facade, which must not be edited/erased, as this would have a direct impact on the functionality of the entire system.

Start, stop of all application¶

In the case of the Excalibur Enterprise system, it is not possible to talk about starting/tracking the entire application, as several components are involved in its operation. However, shutting down the Excalibur Server component can be considered a proper system shutdown. The correct launch is the launch of the Excalibur Server and Excalibur Facade components.

Start, stop of individual modules¶

Excalibur Server¶

From the point of view of the operating system, Excalibur Server is a classic daemon running in the background, which is primarily controlled using the init.d script (/etc/init.d/excalibur) directly on the server where it is installed. It is started automatically at the boot of the operating system and stopped correctly when shutting down / restarting the operating system.

Start: $ sudo /etc/init.d/excalibur start

Stop: $ sudo /etc/init.d/excalibur stop

In the administration console (Dashboard) it is possible to restart the server by clicking on the Overview section and the Server tab.

Excalibur Facade¶

From the point of view of the operating system, Excalibur Facade is a standard system service, the start/stop of which can be performed either utilizing the system Task Manager or by entering a query on the Service Control Manager.

Start by SCM*: > sc start ExcaliburADFacade

Stop by SCM*: > sc stop ExcaliburADFacade

( execute with administrator privileges)*

Excalibur Client¶

From the point of view of the operating system, Excalibur Client is a standard system service, the start/stop of which can be performed either utilizing the system Task Manager or by entering a query on the Service Control Manager.

Start by SCM*: > sc start ExcaliburClient

Stop by SCM*: > sc stop ExcaliburClient

( execute with administrator privileges)*

Procedures for determining the status of the application¶

Excalibur Server¶

The current status of the Excalibur Server can be obtained in several ways. The most relevant way is to get the status directly on the server where it is installed. Status information is also propagated to other system components but may be distorted, e.g. due to a loss of connection to the server.

Server - with direct access to the server, the status of the application server is determined using the following command, which summarizes and prints status information:

$ sudo /etc/init.d/excalibur status

Excalibur is running 6 processes
Excalibur is listening on 4 sockets
Disk usage is 46 percentage
Excalibur cumulative CPU usage is 0 percentage
Excalibur cumulative memory usage is 11.6 percentage

Dashboard - information about the server status, current version, and utilization of associated processes (workers/threads) can be found in the Overview section in the Admin Console and in the Server tab.

Token a Client - the status of the application server and its functionality from the end user's point of view can be found both in the mobile application (in the settings section Companies ) and on the computer login screen based on the color of the connection indicator.

Excalibur Facade¶

The current status of the Excalibur Facade can be obtained in several ways. The most relevant way is to get the status directly to the Active Directory Domain Controller (ADDC) where it is installed. Status information is also propagated to other system components but may be distorted, e.g. due to a loss of connection to the server.

ADDC - the current status can be obtained either by using the system Task Manager or by entering a query on the Service Control Manager:

> sc query ExcaliburADFacade

SERVICE_NAME: ExcaliburADFacade
TYPE               : 10  WIN32_OWN_PROCESS
STATE              : 4  RUNNING
                        (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE    : 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT         : 0x0
WAIT_HINT          : 0x0

Dashboard - Information on the status of facades, their IP addresses, versions, occupancy can be found in the Overview section on the Admin Console and in the Server tab. We distinguish these states:

• connected (active) - the facade is connected and processes all requirements at a given moment.
• connected (passive) - the facade is connected, but the server does not communicate with it. In the event of an active failure, the entire communication will be automatically redirected to it.
• disconnected - the facade was connected, but is currently unavailable.

Excalibur Client¶

From the point of view of the operating system, Excalibur Client is a standard system service, the current status of which can be obtained either by using the system Task Manager or by entering a query on the Service Control Manager.:

> sc query ExcaliburClient

SERVICE_NAME: ExcaliburClient
TYPE               : 10  WIN32_OWN_PROCESS
STATE              : 4  RUNNING
                        (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE    : 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT         : 0x0
WAIT_HINT          : 0x0

The status of individual clients can also be monitored in the Dashboard administration console in the Computers section. However, these statuses are updated continuously, and in the event of a connection failure, the information may be temporarily out of date.

Logging¶

Application logs¶

Excalibur Server¶

Excalibur Server (and all of it`s internal components) by default writes all runtime log records to standard output and those logs are processed with Docker logging drivers. Based on deployment logging configuration, runtime logs can be redirected to the local Syslog server and by default stored into the following files for further processing (eg. SIEM agents):

• /var/log/excalibur.log - logs which origin are Excalibur's application services.
• /var/log/excalibur-system.log - logs which origin are Excalibur's system services.

In addition to the standard runtime logging, there is the possibility of detailed anonymized logging of specific actions (flows). These logs can be viewed on the Dashboard console in the Logger section. More information about Excalibur Logger and flow logs can be found in Excalibur Logger documentation.

Log format¶

Server runtime application log records, in general, has the following format:

SYSLOG-HEADER: SYSLOG-MSG

• SYSLOG-HEADER - header defined by the local Syslog server.

  TIMESTAMP HOSTNAME APP[PROCESS]

  • TIMESTAMP - local timestamp format (eg. 2020-04-30T20:49:01.768-02:00)
  • HOSTNAME - node host name
  • APP - application name
  • PROCESS - application process ID

!!! note Header format may vary, depending on the local Syslog server configuration.

• SYSLOG-MSG - each record contains the following (standardized) fields which are separated with separator ‘|’.

  EXC-LEVEL | EXC-SUBSYSTEM | EXC-ACTION | EXC-ENTITY | EXC-MESSAGE

  • EXC-LEVEL - text representation of Excalibur log level (see. Log levels)
  • EXC-SUBSYSTEM - text representation of Excalibur`s subsystem or module
  • EXC-ACTION - text representation of action within subsystem or module
  • EXC-ENTITY - action entity (user, client, component...) identification
  • EXC-MESSAGE - combined log varargs into the single-line message string

!!! note Depending on the available context during log record creation it is sometimes not possible to fill all fields therefore they are replaced with “?”.

Log levels¶

• emergency - system is unusable
• alert - action must be taken immediately
• critical - critical conditions
• error - error conditions
• warning - warning conditions
• notice - normal but significant condition
• info - informational messages
• debug - debug-level messages
• devel - development messages

A high logging level (5 and more) generates a large number of logs, which can cause disk space on the server to become full! We recommend configuring proper rotation of logs.

Log examples¶

Sep  9 11:40:02 localhost excalibur-pam[1544]: debug | Refresh | Tresk | ? | Refresh tresk data failed -- ENOENT: no such file or directory, open '/opt/excalibur/pam/treskvm.json'
Sep  9 11:41:49 localhost excalibur-pam[1544]: notice | MongodbConnector | Delete by expiration | ? | Delete by expiration 1631180510 of collection PAM_TEXT_RECORDINGS

Excalibur Facade¶

Logs from the Excalibur Facade run are continuously stored in the c:\Program Files\Excalibur Enterprise AD Facade\logs folder. If the facade is active and connected to the Excalibur Server, then it is possible to download these logs via a click in the Overview section in the Server tab.

Excalibur Client¶

Logs from the Excalibur client run are continuously stored in the c:\Program Files\Excalibur Enterprise\logs folder. If a specific client is active and connected to the Excalibur Server, then it is possible to download these logs via a click in the Computers section in detail for a specific client.

The client code also includes the Excalibur Logger client, which collects and then sends flow logs for individual performed actions during the application run.

Excalibur Token¶

Part of the token code is the Excalibur Logger client, which collects and then sends flow logs for individual performed actions during the running of the mobile application.

Audit logs¶

Audit logs are written directly to the database server and are available via the Dashboard administration interface in the Audit section for the Administrator and Auditor user roles.

Monitoring¶

Application monitoring¶

Health check¶

The Excalibur Enterprise system also includes its application monitoring, which is available within the Dashboard administration console in the Overview section [2]. Currently monitored parameters are:

• users - number
• sessions - type, number
• incidents - type, number
• actions - type, status, number
• clients - version, status, operating system, number
• tokens - version, status, operating system, number
• server - process load
• facades - status, occupancy
• PAM - disc space usage for records
• TRESK - status

Components status¶

System monitoring¶

Instructions on how to test the functionality of the application¶

The basic test for verifying the functionality of the entire Excalibur Enterprise system is to log in to the Excalibur Client online using the Excalibur Token (online login):

1. Scan the login QR mobile application Excalibur.
2. Enter authentication factors (PIN, fingerprint, or Face ID).
3. Your computer should automatically log you in.

For more information on using the mobile application, see the User Manual

Typical problems and their solutions¶

Errors and problems while using Excalibur Enterprise can occur at any stage of the application. From the user's point of view, they are first detected directly on the mobile phone screen in the form of an error message. The specific error is then propagated to the Dashboard administration console, where it can be traced based on the action, time, client in the User: Actions section on the detail screen. For more information, see the Administration Dashboard Manual.

A list of errors that occurred with instructions to resolve them¶

This chapter describes the most common errors. A list of all errors and their detailed description together with their solutions is described in the error condition documentation.

More frequent errors¶

err: request_timeout¶

err: company_not_initialized¶

err: invalid_credentials¶

err: policy_failed¶

err: invalid_qr¶

err: decrypt_failed¶

err: static_credentials¶

Less frequent errors¶

err: no_ldap_for_domain¶

err: bad_signature¶

err: invalid_data¶

err: ldap_error¶

err: unknown_account¶

err: no_such_user (Client)¶

err: no_such_user (Facade)¶

err: account_disabled¶

Less frequent errors¶

err: no_cp_response¶

err: bad_token_id¶

err: password_decrypt_error¶

err: no_such_domain¶

err: unknown_user¶

Further materials¶

Excalibur User Manual

Excalibur Administrattor Dashboard Manual

Excalibur Client Installation Manua

Excalibur AD Facade manual

Excalibur Whitepaper

Excalibur Errors Documentation