Skip to main content
Version: Developer

Windows authentication

When you define a static server or an AutoScaled pool, you set a Connection Credential Type, Connection Username, and Connection Password that Kasm uses to connect to the servers. The Connection Credential Type provides four values, which support the six authentication approaches described on this page. Each approach centralizes how users authenticate to Windows servers at the workspace layer, with different trade-offs for security, concurrency, and management overhead.

Static credentials​

Select Static Credentials for the Connection Credential Type, then enter a username and password in the Connection Username and Connection Password fields of the server or AutoScale configuration. Every Kasm user connection uses these credentials to authenticate.

Advantages

  • Simple configuration.

Disadvantages

  • All Kasm users map to the same Windows user, which has security and auditing consequences.
  • The server can allow only a single concurrent session.

Prompt user​

Select Static Credentials for the Connection Credential Type, then leave the Connection Username and Connection Password fields blank. Kasm then prompts each user to enter a Windows username and password.

Advantages

  • Simple configuration.
  • Supports multiple concurrent user sessions per Windows server.
  • Each user can have a separate Windows account.

Disadvantages

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

With Prompt User authentication over Web Native RDP, Kasm does not place uploaded and downloaded files in the user's Windows profile directory, for example C:\Users\<username>\Downloads. Instead, files are stored in the default upload and download directories configured for the Kasm Desktop Service on the Windows server.

Single sign-on with static local accounts​

This option applies only when users authenticate to Kasm with accounts managed by Kasm, rather than with SAML, OpenID Connect (OIDC), or LDAP. Kasm uses a user's Kasm credentials to connect to the remote server. Each remote server needs local accounts whose usernames and passwords match the Kasm users.

In the server or AutoScale configuration, select SSO User Accounts for the Connection Credential Type. In the SSO Domain field, enter localhost so that Kasm signs the user in as a local Windows account.

Advantages

  • Supports multiple concurrent user sessions per Windows server.
  • Each user has a separate Windows account.
  • Single sign-on from Kasm to Windows, so users are not prompted for credentials when connecting.

Disadvantages

  • Managing separate accounts for each user across systems adds complexity.

Single sign-on with dynamic local accounts​

With the Kasm Desktop Service installed, Kasm manages local Windows user accounts on the target server automatically. Each time a user creates a Kasm session to a Windows server, Kasm creates a local user account if one does not already exist. Kasm assigns a random password to that account for each session.

Kasm generates the username from the first 9 characters of the Kasm Workspaces username in lowercase, with special characters replaced by a hyphen, followed by a hyphen and 10 characters from the Kasm Workspaces User ID. For example, Jon.Doe@example.com with a User ID of bf262ada-0a7f-4f49-b435-e50537caa013 produces the local Windows account jon-doe-e-bf262ada0a.

To configure dynamic local accounts, install and register the Kasm Desktop Service. In the server or AutoScale configuration, select Dynamic User Accounts for the Connection Credential Type, then enable the Kasm Desktop Service Installed option. For full desktop sessions over RDP, Kasm allows only a single concurrent session per Kasm user on the server.

note

The Kasm Desktop Service includes built-in PowerShell scripts that run for various purposes. One script creates local users and sets the password for an incoming session. To meet special requirements, edit this script. For more details, see the Service scripts section.

Advantages

  • Supports multiple concurrent user sessions per Windows server.
  • Each user has a separate Windows account.
  • Single sign-on from Kasm to Windows, so users are not prompted for credentials when connecting.
  • Works with any Kasm authentication method, including OIDC, SAML, LDAP, and 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 when users authenticate to Kasm with Active Directory credentials and Kasm is configured for LDAP authentication. The Windows servers must be members of the same Active Directory domain that LDAP authentication uses. AutoScale configurations can join new VMs to the domain and remove them. The usernames that users authenticate to Kasm with must match the usernames they use to authenticate to Windows.

In the server or AutoScale configuration, select SSO User Accounts for the Connection Credential Type. Leave the SSO Domain field blank when the Kasm sign-in domain matches the Windows login domain. To change the username domain, enter a different SSO Domain. For example, when a user signs in to Kasm with jon.smith@public.domain.com but Windows login expects jon.smith@private.domain.local, set the SSO Domain to private.domain.local.

caution

After you enable LDAP-based SSO or grant access to an LDAP SSO workspace, users must sign out of Kasm and sign back in for SSO to work. When access is granted while the user is already signed in, the user may see "Unable to connect. Please contact an administrator." until they sign out and back in.

Advantages

  • Supports multiple concurrent user sessions per Windows server.
  • Each user has a separate Windows account.
  • Single sign-on from Kasm to Windows, so users are not prompted for credentials when connecting.

Disadvantages

  • Additional configuration and systems add management complexity.
  • SAML and OIDC are not supported as Kasm authentication methods.

Smartcard authentication​

This option applies only when the Windows servers are configured to authenticate with a smartcard, through Active Directory or LDAP Windows configuration. The Kasm user does not have to be an LDAP user in Kasm for this method to work.

In the server or AutoScale configuration, select Authenticate with SmartCard for the Connection Credential Type. The workspace must have RDP Client Options set to RDP local client for this feature to work.

Advantages

  • Supports multiple concurrent user sessions per Windows server.
  • Each user has a separate Windows account.
  • Windows uses smartcard authentication, so the user needs only a smartcard and PIN to sign in. No password is required.
  • Kasm can use any authentication method the administrator chooses, because it is not tied to how Windows authenticates.

Disadvantages

  • Managing separate accounts for each user across systems adds complexity.
  • Users present their smartcard every time they connect to a Windows system.