Windows Authentication

When defining a single static server or an auto-scaled pool, you need to provide a 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 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 Windows system. This has security and auditing ramifications.

  • Only a single concurrent session per server could be allowed.

Prompt User

If the Connection Username and Connection Password fields are left blank in the Server or Auto-Scaling configuration, the user will be prompted to enter their Windows username and password.

Advantages

  • Simple

  • Allows for multiple concurrent user sessions per Windows server

  • All users could have a different account in Windows

Disadvantage

  • Users have to enter their credentials every time they connect to a Windows system.

Single Sign-On with Static Local Accounts

This option applies only if users authenticate to Kasm using users managed by Kasm, as opposed to using SAML, OIDC, or LDAP authentication. Administrators can configure Kasm to use a user’s Kasm credentials when connecting to remote servers. The remote servers will need local accounts that match the username and password of the Kasm users.

In the server or auto-scale configuration, the Connection Username can be set to {sso_username} and the Connection Password can be set to {sso_cred}.

Advantages

  • Allows for multiple concurrent user sessions per Windows server.

  • All users have different accounts in Windows.

  • Single Sign-on from Kasm to Windows, so users don’t get prompted to enter credentials when connecting to Windows.

Disadvantages

  • Complexity in managing separate accounts for each user across different systems.

Single Sign-On with Dynamic Local Accounts

With the Kasm Windows Service installed, Kasm can automatically manage local Windows user accounts on the target server. Each time a user creates a Kasm session to a Windows server, a local user account is created on the Windows server, if it does not already exist. A random password is assigned to the local Window 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 Windows account of jon-doe-e-bf262ada0a.

To configure dynamic local accounts, the Kasm Windows service must be installed and registered. In the server or auto-scale configuration, the Connection Username must be set to {sso_create_user} and the Agent Installed option must be enabled.

Note

The Kasm Windows service comes with built-in PowerShell scripts which are executed for various purposes. There is a PowerShell 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 Windows server.

  • All users have different accounts in Windows.

  • Single Sign-on from Kasm to Windows, so users don’t get prompted to enter credentials when connecting to Windows.

  • Works with any authentication mechanism, OIDC, SAML, LDAP, local Kasm accounts.

  • Simple configuration with no requirement for Active Directory or other external dependencies.

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 Windows 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. Usernames used by users to authenticate to Kasm must match the username that users would use to authenticate to Windows systems.

In the server or auto-scale configuration, the Connection Username can be set to {sso_username} and the Connection Password can be set to {sso_cred}.

Important

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

  • Allows for multiple concurrent user sessions per Windows server.

  • All users have different accounts in Windows.

  • Single Sign-on from Kasm to Windows, so users don’t get prompted to enter credentials when connecting to Windows.

Disadvantages

  • More complexity in additional configuration and systems to manage.

  • SAML and OIDC not supported as Kasm authentication methods.