Grandmaster authentication - users and protocols

Here we’ll go over authentication with TimeKeeper, with a specific focus on capabilities and configurations when TimeKeeper is installed on a grandmaster. We’ll cover the system login details, RADIUS/TACACS+ authentication, ssh, and so on.

For details on TimeKeeper authentication abilities in the non-grandmaster case, please refer to the “Web interface authentication” section.

Web interface authentication

In this section, we’ll cover web authentication specific to grandmaster installations of TimeKeepers.

Admin web user

When the web interface is enabled, users can log in with an “admin” account, with the default password “timekeeper”. Note: In earlier versions of TimeKeeper the default password was “fsmlabs”. This is a local system account, also usable via ssh and on the console. The password can be set via the GUI and also on the command line via ssh or on the console.

Logging in as admin will allow you to manage all aspects of the system, including visualization, service management, configuration, and other supported options. On grandmasters, the primary interface for controlling the appliance is via the web interface, so the admin user will be used for nearly all system management. For a more limited login, refer to the next section on the readonly user.

Authentication of the web login is handled based on how the unit is configured. By default authentication and password control is local to the system admin account. If RADIUS or TACACS+ is enabled, authentication is handled by the configured servers. Should access to these services fail (such as during a network outage), the provided password will be tested against the local system account.

For admin to be authenticated via RADIUS or TACACS+, the authentication server must have an account named admin with matching credentials.

If a TimeKeeper Grandmaster upgrade detects the need for and adds a local system admin account for authentication, it will as a precaution disable ssh access. This prevents unauthorized logins with the default password, until the admin account password can be changed to something unique. SSH access can then be reenabled as before via the web GUI.

Readonly web user

A more limited user is also available with the readonly account that can be configured by the admin user via the web interface. The readonly user can log in and review TimeKeeper data, but cannot reconfigure or manage the system.

By default, the read-only user feature is present but not configured and cannot be used. To configure the readonly user, log in as admin. Select the Configuration tab, then select the Service & System Management subtab. The Set readonly password button will allow you to configure a password for the read-only user, which will be named readonly.

Logging in via ssh, console, RS232

By default the Grandmaster does permit RS232 console login, and keyboard/monitor access for enabled accounts but not ssh access.

To enable ssh access login to the web interface as admin click the Enable SSH button in the Configuration tab, Service & System Management subtab. Once this is enabled, logs can be retrieved via SCP, SFTP and similar tools with the loguser or admin user. It is also possible to SSH into the device and run system monitor tools like ‘top’, ‘ps’ and other Linux programs.

Users admin and readonly can also be used on the console or via ssh in addition to the loguser user. readonly and loguser accounts must be enabled via the web interface before they can be used. This can be done in the web interface under the Configuration tab, in the Service & System Management subtab. This will permit RS232 and keyboard/monitor access but not ssh unless ssh access is enabled.

All console and ssh logins will authenticate via RADIUS or TACACS+ if the Grandmaster is configured to use those protocols.

It is strongly recommended that you change the default password for loguser immediately. The default is: logaccess. This applies even if RADIUS or TACACS+ is in use, as TimeKeeper can still fall back to login against the local account when logging in.

The readonly and loguser accounts are intended for easy log collection via ssh, so that logs can be archived as needed for audit trails.

Root access

Standard shell access as root is not normally permitted or recommended. Please do not enable allow root access via the web GUI unless asked to by FSMLabs personnel.

HTTPS support

The web interface on TimeKeeper Grandmasters may be accessed via normal http on a configurable port (see WEB_MANAGEMENT_PORT) or via https on port 443. If web management is enabled on a TimeKeeper Grandmaster, https will be available. If the WEB_MANAGEMENT_IP setting is used to restrict which interfaces respond to web queries, https support will also be limited to that named address. Access over https is achieved with the following example URL:

Out of the box, the grandmaster will use a unique self-signed certificate. This means that browsers may, on initial connection, ask the user to confirm that the certificate is acceptable. This is normal and expected. This warning will only occur when using https, and with most browsers will only need to be viewed once.

Users can configure https support by logging into the appliance over https. Navigate to the Configuration tab, subtab Service & System Management. Options to Generate HTTPS CSR and Upload HTTPS Certificate will be present. (Note that if the system is not a Grandmaster, or if the login was not done over https, these options will not be available.)

The existing self-signed certificate can be used, or users can provide their own certificate for the appliance. A new signed certificate may be needed to comply with internal policies, or it may just simplify systems management. Whatever the reason, a Certificate Signing Request can be made by clicking on Generate HTTPS CSR. This will prompt the user for the information needed to create a new request for their certificate authority. Enter the information, and wait while the request is generated.

Once the request is generated, the dialog will be updated with the CSR data. This can be copied and delivered to the appropriate certificate authority for validation. As part of this process, a new certificate and key will be generated on the appliance. The next time TimeKeeper is restarted, the new key will be used - but this process does not require an immediate restart. (Note that since the appliance has a new certificate, client browsers may present that same initial certificate warning after the next appliance restart.)

Once a new certificate has been generated based on the CSR, it can be uploaded with the Upload HTTPS Certificate option on the same tab. This is a file upload dialog that can be used to upload the newly generated certificate. This step will cause TimeKeeper to restart immediately to apply the certificate.


TimeKeeper Grandmasters support the use of RADIUS and TACACS+ for login authentication in addition to local accounts. (Note that, although this document simply refers to “authentication,” these servers provide authentication, authorization, and accounting capabilities.) To enable the feature, log into the web interface, and select Configuration, then Service & System Management. The option to enable/disable RADIUS and TACACS+ and to configure both will be visible under Manage Communication if supported. If these controls are not available, an upgrade may be required. Please contact for details.

By default, RADIUS and TACACS+ support is disabled. To enable it, first use Configure RADIUS or Configure TACACS+ to configure for your authentication servers and pre-shared keys. A timeout value in seconds indicates how long to attempt to login via that server. If you have previously configured a pre-shared key for a server it will not be displayed if you reload the dialog, as a security precaution.

Once configured, logins on both the web interface, console, and SSH (if enabled) will attempt to authenticate via TACACS+ or RADIUS first, with each configured server in turn. If TimeKeeper is not able to access any of the RADIUS or TACACS+ servers, authentication will be attempted using the local account credentials.

This is very important - local account authentication will be used if TimeKeeper cannot access the RADIUS or TACACS+ servers. This means, at a minimum, local passwords must be changed from the default shipping settings. Accounts with local passwords include:

If TimeKeeper is configured to use TACACS+, and the configured server hosts are down or otherwise unreachable, it could take up to one minute to timeout per host. Therefore, if it seems like TimeKeeper is unresponsive when you attempt to log in (with either local or external credentials), you should wait a few minutes for a response before, for example, refreshing the web page or restarting the Grandmaster. To resolve this, make sure the configured hosts are reachable or, once you log in, disable TACACS+ and use local credentials and authentication until that happens.

If external authorization is required, either TACACS+ or RADIUS can be used, but the Grandmaster will not support both protocols simultaneously.

If the user logs into TimeKeeper with valid RADIUS/TACACS+ information, and there is no local account of that name, the user will be presented with ‘readonly’ or ‘admin’ views, detailed above.

WARNING - If you have been relying on credentials for an internal account, such as admin, while configured to use external authentication, you should create an external account with that same name and its own credentials and privilege attribute (see “Authorization” section below). If you don’t, you will be unable to log in with that account because, starting with version 8.0.17, TimeKeeper no longer falls back to local authentication if external authentication fails, e.g., unknown account or bad password. (It now only falls back if the authentication servers are inaccessible, e.g., offline.) Also, as of 8.0.17, the local admin white list has been replaced with support for an administrative-privilege-level attribute on your authentication servers (see below). To maintain administrative access, you must add such an attribute for each name in that list on your authentication servers.


Local authorization is tied to the account name. For example, the account with the admin username has administrative privilege level. The privilege level of an external account, created and maintained by users on their RADIUS and TACACS+ servers, is indicated by the priv-lvl attribute common to other network equipment. Allowed values are 0 through 15. Level 0 indicates read-only privilege level; level 15 indicates administrative privilege level. The read-only privilege level is also assigned if the level is any other value or the priv-lvl attribute is missing.

Accounts with administrative or read-only privilege level have the same capabilities as the local admin or readonly account, respectively. For ssh and console access, the external user starts in the home directory corresponding to the local account. While you can create an external account with the same name as a local account, i.e., admin, readonly, or loguser (but not root), it starts in the same home directory and has the same capabilities as the local account–you can’t override this by specifying a contradictory privilege level.


For the RADIUS privilege-level attribute, the FSMLabs vendor has an id of 42733. The AVPair string attribute has an id of 1. The attribute value is of the form, shell:priv-lvl=N, where N is the privilege level, e.g., 0 or 15.

Here is a read-only example for the FreeRADIUS RADIUS server:

jsmith Cleartext-Password := "$kZ90mhvSm41"
        FSMLabs-AVPair = "shell:priv-lvl=0"


The TACACS+ privilege-level attribute is of the form, priv-lvl=N, where N is the privilege level, e.g., 0 or 15.

Here is an administrative example for the tac_plus TACACS+ server:

user = jsmith {
        global = cleartext "$kZ90mhvSm41"
        service = exec {
                priv-lvl = 15