TOTPRadius - "Slave" appliance mode
TOTPRadius has high availability implemented by enabling "slave" appliance mode—you can deploy additional TOTPRadius appliances and configure the master to slave replication. The slave appliances only replicate the users(the other settings can be set manually or via the Configuration Export/Import feature) to provide redundancy in case the master fails. The goal is to serve as a secondary authentication source. No additional user licenses are required as this mode does not allow creating users.Slave mode can be enabled under "Advanced settings" :
"Strict SSL" mode is highly recommended and requires a valid SSL certificate installed on the master node.
Note: Enabling slave mode will disable local user account management features, as well as self-enrollment features and initial login allowance. The admin password of this appliance will also be copied
over from the master appliance. If you want to have a separate administrator for slave appliances, you can add them via LDAP integration only.
As mentioned above, replication only includes the user database.
But what about hardware tokens, then?
Because to provide the full authentication process, the slave appliance needs to "know" users' assigned secret keys. The hardware token database is not used in the authentication mechanism, it is used when creating or modifying a user record. The secret key of a user gets copied from the hardware token database to the user database when assigned.
So, replication includes secret key information too as a part of the user record.
"Slave" mode use case (example)
For example, let's try MFA-protected SSH access to Ubuntu server with LDAP based on Master/Slave mode. The full implementing guide is here: Configuration guideWe should add 2 RADIUS server configuration records to /etc/pam_radius_auth.conf:
# server[:port] shared_secret timeout (s)
192.168.0.245 hwxa30lqwcr 10
192.168.0.246 92k95wrcjdp8 10
where :
* 192.168.0.245 - IP of Master appliance
* 192.168.0.246 - IP of Slave appliance
Having tested the authentication, we can come to the following conclusion:
1)Disabling one of the nodes does not affect the authentication process. Users can still log in to the server via SSH if one of the appliances is online.
2)Users can be created only on the master appliance. When creating a new user on the slave appliance, you will get the message :
3) Although Slave has a trial license(up to 5 users), it contains a user count equal to Master. It means that no additional license is needed for the slave appliances.
About
Installation and configuration
- Installation and initial configuration
- Network configuration
- Migrating from older versions
- LDAP Configuration
- Azure AD Configuration
- Self-service enrollment portal
- Web and LDAPS Certificates
- Syslog configuration
- Single-factor authentication exceptions
- Slave appliance mode
- Dynamic RADIUS Attributes
Integration guides
Blog
27-02-2024
Enhancing Bitwarden Security and Convenience with Passkeys
Bitwarden's latest upgrade introduces passkeys, such as FIDO2 keys and platform authenticators, enhancing both security and user convenience for vault encryption and decryption tasks with PRF capabilities.
15-02-2024
Introducing Token2 PIN+ Release 2: Elevating Security with 300 Passkey Storage
We're excited to introduce Token2 PIN+ Release 2, our latest FIDO2 Key that boasts an unmatched advantage: the ability to store up to 300 passkeys (aka resident keys or discoverable credentials). This significant capacity provides unparalleled flexibility and convenience for managing your online accounts securely.
05-02-2024
FIDO2.1 Manager: Standalone Passkey Management Tool for Windows
In response to a glaring gap in the market, we are thrilled to introduce the first standalone FIDO2.1 Passkey Management Tool for Windows. Fueled by the necessity for a user-friendly solution, our tool addresses the discomfort users face with command line tools and Chromium-based methods.