Linux Authentication
When defining a single static server or an auto-scaled pool, the administrator needs to provide a Connection Credential Type, Connection Username, and Connection Password to use to connect to the server(s). There are three options administrators have when considering the connection credentials.
Static Credentials
The administrator would select Static Credentials for the Connection Credential Type and put in a static username and password into the Connection Username and Connection Password of the Server or Auto-Scale configuration. All Kasm user's connections would use these credentials for authentication.
Advantages
- Simple
Disadvantage
- All Kasm users are the same user on the Linux system. This has security and auditing ramifications.
- Only a single concurrent session per server could be allowed.
When using Static Credentials authentication, both a download directory (for example, ~/Downloads) that does not exist or is not owned by the authenticated user and a missing Connection Username (which leaves the Kasm Desktop Service unable to resolve a session username, so it falls back to a default of username not found) cause uploaded and downloaded files to be stored in the default upload and download directories configured for the Kasm Desktop Service (by default /opt/kasm-desktop-service/Upload and /opt/kasm-desktop-service/Download) rather than in the user's home directory.
Prompt User
If the Connection Username and Connection Password fields are left blank in the Server or Auto-Scaling configuration and Static Credentials is selected for the Connection Credential Type, the user will be prompted to enter their Linux username and password.
Advantages
- Simple
- Allows for multiple concurrent user sessions per Linux server
- All users could have a different account in Linux
Disadvantage
- Users have to enter their credentials every time they connect to a Linux system.
- Features that rely on a resolved Kasm Desktop Service username (e.g., screenshots, storage mounts, scripts and user profile based file mappings) will not be available.
When using Prompt User authentication with Web Native RDP, uploaded and downloaded files are not placed into the user's home or profile directory (for example, /home/<username>/Downloads on Linux).
Instead, files are stored in the default upload and download directories configured for the Kasm Desktop Service.
Single Sign-On with Dynamic Local Accounts
With the Kasm Desktop Service installed, Kasm can automatically manage local Linux user accounts on the target server. Each time a user creates a Kasm session to a Linux server, a local user account is created on the Linux server if it does not already exist. A random password is assigned to the local Linux user account with each session. The username generated by Kasm is the first 9 characters of the Kasm Workspaces username in lower case, with special characters replaced with a -, followed by a - and 10 characters from the Kasm Workspaces User ID. For example, Jon.Doe@example.com with a Kasm User ID of bf262ada-0a7f-4f49-b435-e50537caa013 would result in a local Linux account of jon-doe-e-bf262ada0a.
To configure dynamic local accounts, the Kasm Desktop Service must be installed and registered. In the server or auto-scale configuration, select Dynamic User Accounts for the Connection Credential Type. and the Kasm Desktop Service Installed option must be enabled.
The Kasm Desktop Service comes with built-in bash scripts which are executed for various purposes. There is a bash script responsible for creating local users and setting the password for an incoming session. If you have special requirements, you may edit this script for your exact needs. See the Service scripts section for more details.
Advantages
- Allows for multiple concurrent user sessions per Linux server.
- All users have different accounts in Linux.
- Single Sign-on from Kasm to Linux, so users don't get prompted to enter credentials when connecting to Linux.
- Works with any authentication mechanism, OIDC, SAML, LDAP, local Kasm accounts.
- Simple configuration with no requirement for Active Directory or other external dependencies.
Disadvantages
- Currently only supported for use with RDP connections.
Single Sign-on with Active Directory
This option applies only if users authenticate to Kasm using Active Directory credentials with Kasm configured with LDAP Authentication. Additionally, the Linux servers being connected to must be a member of the same Active Directory domain that LDAP authentication is configured for. Auto-scaling configurations can join new VMs to the domain and remove them. When using auto-scaling to join VMs to Active Directory, review the Linux VM startup script README for the required configuration. Usernames used by users to authenticate to Kasm must match the username that users would use to authenticate to Linux systems.
In the server or auto-scale configuration, select SSO User Accounts for the Connection Credential Type. Leave the SSO Domain blank if the domain the user logs into Kasm with is the same as the domain name used for Linux login. You may specify a different SSO Domain to change the username's domain. For example, if a user logs into Kasm with jon.smith@public.domain.com, but Linux login expects jon.smith@private.domain.local, set the SSO Domain to private.domain.local.
After configuring LDAP based SSO and/or providing a user access to a Workspace that is configured for LDAP based SSO, users must sign out of Kasm and then back in, in order for SSO to work.
Advantages
- All users have different accounts in Linux.
- Single Sign-on from Kasm to Linux, so users don't get prompted to enter credentials when connecting to Linux.
Disadvantages
- More complexity in additional configuration and systems to manage.
- SAML and OIDC not supported as Kasm authentication methods.