---
myst:
  html_meta:
    "description lang=en": "Kasm Workspaces Windows Authentication"
    "keywords": "Kasm, Windows, RDP, RDS, AD, LDAP, single sign-on"
    "property=og:locale": "en_US"
---
```{title} Windows Authentication
```

## Windows Authentication

When defining a [single static server](./static_servers.md) or an [auto-scaled pool](./auto_scaled_servers.md), 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](./windows_service.md) 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](./windows_service.md#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](../ldap.md). 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](./auto_scaled_servers.md#auto-join-active-directory) 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.