Windows 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 four 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 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 and Static Credentials is selected for the Connection Credential Type, 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, select SSO User Accounts for the Connection Credential Type. In the SSO Domain, type localhost to have Kasm log the user in as a local Windows account.

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 Desktop 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 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.

Note

The Kasm Desktop 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, 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 Windows 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 Windows login expects jon.smith@private.domain.local, set the SSO Domain to private.domain.local.

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.

SmartCard authentication

This option applies only if the Windows servers are configured to authenticate via SmartCard. This is accomplished 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 auto-scale configuration, select Authenticate with SmartCard for the Connection Credential Type. The workspace must be configured with RDP Client Options set to RDP local client for this feature to work.

Advantages

  • Allows for multiple concurrent user sessions per Windows server.

  • All users have different accounts in Windows.

  • Windows uses smart card authentication so the user only needs their smart card and pin to sign on, no password is needed.

  • Kasm can use any authentication method the administrator chooses as it is not tied to how Windows authenticates.

Disadvantages

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

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