---
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), 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](./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 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](./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, 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.