LDAP Authentication

Create an LDAP Configuration

The first step in configuring Kasm to use LDAP for authentication is to set up an LDAP configuration.

• Log into the Kasm Web UI as an administrator

• Click Access Management -> Authentication -> LDAP

• Click Add Configuration

LDAP Config

Property	Description
Name	A name given to the configuration
URL	The LDAP connection URL to the LDAP server
Search Base	The Base OU used for searching for objects. Kasm will use the search base DCs to identify users to the applicable LDAP Configuration. i.e DC=kasm,DC=core will map to <user>@kasm.core
Search Filter	The search filter used to identify user account names
Group Membership Filter	This query is used to identify if the user is a member of a particular group. Used for Kasm group to LDAP group mapping
Email Attribute	The user attribute used to denote the users email address
Alternate Username Domains	Comma separated list of additional domain names that usernames should match on. Use an asterisks to match usernames without a domain name. See section below on domain name matching.
Service Account DN	The service or ‘bot’ account used to issue queries to the LDAP server
Service Account Password	The service or ‘bot’ account password
Search Subtree	If enabled, objects beneath the Search Base will be discovered
Auto Create App User	If enabled, Kasm will create an associated user account inside the application when the user first logs in.
Enabled	Enable or disable this configuration

Note

In order for password resets to work with LDAP accounts, the service account must be provided the authority to reset user passwords in Active Directory and the connection must be made over a secure LDAPS connection.

User Domain Name Matching

Users are expected to login with usernames in the format of username@domain.name. The domain-name portion of the username is used to find the appropriate LDAP configuration based on the domain name specified in the Search Base field. There are situations where it is desirable for the usernames to have a different domain name that what is Active Directory. In that case administrators can use the Alternate Username Domains field to specify a list of alternate domain names in the username that should be used to match to this LDAP configuration. For example ‘greenearth.com,acquired_company.com’ would be used with users logging in with username@greenearth.com and username@acquired_company.com in addition to the domain in the Search Base field.

An asterisks in the Alternate Username Domains is supported. An asterisks signifies that usernames that do not have a domain name at all should be matched to this LDAP configuration. Administrators can configure multiple LDAP configurations with an asterisks in the Alternate Username Domains, as long as they all point to the same domain. This can be done for redundancy, for example. However, you should not have multiple LDAP configurations that specify an asterisks in the Alternate Username Domains field, when they are pointed to different domains. This would result in nondeterministic behavior in matching users to the appropriate LDAP configuration.

Test Authentication

After creating an LDAP configuration, you can test the settings by clicking the Test LDAP Connection icon on the LDAP Configurations Page.

Test LDAP Config

Enter known valid user credentials

Common Errors

Error	Notes
Authentication Error : socket connection error while opening: timed out	The Kasm API server cannot make a connection to the specified LDAP URL. Verify the URL is correct, and network connectivity between the two end points.
Authentication Error : automatic bind not successful - invalid Credentials	The password for the LDAP service account is invalid. Verify the password is correct and that the account is not locked out. Verify the Service Account DN is correct
Authentication Error : socket ssl wrapping error : [Errno 104] Connection reset by peer	LDAPS was specified in the LDAP URL but the LDAP server is not communicating over SSL
Authentication Error : error recieving data : [Errno 104] Connection reset by peer	The LDAP server rejected the connection. Verify that the port specified in the URL is correct. Verify that protocol LDAP or LDAPS is correct in the URL
Unable to locate user (test@kasm.local)	The user could not be located. Verify the Search Base and Search Filter parameters are correct
LDAP Login failed for user (test@kam.local) : ({‘message’:’80090308: LdapErr:DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839x00’,’saslCreds’: None, ‘result’:49,’dn’:”, ‘description’: ‘InvalidCredentials’,’type’: ‘bindResponse’,’refferals’:None})	The provided credentials are invalid or the account is locked out.
LDAP password reset failed:({‘result’: 53, ‘description’: ‘unwillingToPerform’, ‘dn’: ‘’, ‘message’: ‘0000001F: SvcErr: DSID-031A124C, problem 5003 (WILL_NOT_PERFORM), data 0nx00’, ‘referrals’: None, ‘type’: ‘modifyResponse’}) .	LDAP without SSL was used in the connection, and password reset for a user was attempted. Windows servers only support changing passwords over secure LDAPS connections.

Create LDAP linked Group

Kasm Workspaces can be configured to automatically map LDAP users to specific Kasm application groups via their LDAP group membership. The mapping is updated for each user when the user logs into the Kasm Web Application. The mapping functionality can be accessed by using the arrow menu and selecting edit for the group you want to add a mapping to. Then selecting the SSO Group Mappings tab and click Add SSO Mapping. The Add SSO Mapping Screen is presented the following fields are available to be filled in:

Edit Group

SSO Group Mappings

Add SSO Group Mapping

Property	Description
SSO Provider	A dropdown of the available SSO identity providers (LDAP, SAML, OpenID) configured in the system.
Assign All Users	A checkbox that indicates any user that authenticates with the defined SSO provider will be added to the Kasm group
Group Attributes	The LDAP DN to the desired group

LDAP Attribute Mapping

Additional LDAP user attributes are returned by the authentication request to the LDAP server. These LDAP user attributes can be mapped to Kasm User fields. Every time the user logs in, the Kasm user fields will be updated with the values returned by the LDAP server. See the documentation for your LDAP provider for a listing of user attributes.

These can be configured by editing an existing LDAP Authentication configuration, if creating a new configuration you will need to submit and edit to add them.

The following Kasm User fields can be populated with values from LDAP user attributes.

• First Name

• Last Name

• Phone

• Organization

• Notes

• City

• State

• Country

• Email

• Custom Attribute 1

• Custom Attribute 2

• Custom Attribute 3

LDAP Attribute Mapping

Note

Kasm can log all LDAP user attributes present in the login event, this is helpful for determining the attribute names. Add a LDAP Attribute Mapping with an attribute name of ‘debug’ and target any user field. The next time a user logs in, all LDAP user attributes and values will be logged by Kasm.

AD Sync

Kasm can manage user accounts in Microsoft Active Directory by automatically creating user accounts in AD and resetting the user’s password in AD to a randomly generated password on each login. This is primarily used in scenarios where the user is authenticated from a SAML or OIDC identity provider and you want Kasm to then create an associated user in AD. This is useful for deployments where Active Directory is required for various purposes, but where AD is not the primary source of identity and access management for the organization. Because Kasm sets a random password for the user in AD each time they login to Kasm, Kasm is able to provide single sign-on to Windows servers that are part of the same AD.

The first step in configuring AD Sync is to create an LDAP configuration under Access Management->LDAP, in the administrator panel. See the LDAP configuration sections for details on configuring LDAP. LDAP configurations are normally used in Kasm for authenticating users, but in this case we don’t want users to be able to use their AD credentials to log into Kasm. Therefore, the recommendation is to disable the LDAP configuration in Kasm, which will keep this LDAP configuration from being used for authentication to Kasm. The service account used in the LDAP configuration must have the authority to reset user accounts in AD. If you have enabled user account creation or managing group membership, the service account will need proper authority to create users and/or add and remove users from groups. The LDAP Configuration needs to specify Alternative User Domains, which is a comma separated list of domain names within a username that will get mapped to the domain configured by the LDAP configuration. For example, you may have a SAML identity provider where usernames are in the format username@company.com, but your Active Directory domain is company.local. Specifying an Alternative User Domain value of company.com will cause Kasm to search for the user in AD as username@company.local.

After the LDAP Configuration is created, Edit the configuration and switch to the AD Sync tab. Click the Add button to create an AD Sync configuration. AD Sync configurations have the following properties.

Property	Description
Type	The source of identities for Kasm to synchronize. Valid options are local, saml, or oidc.
Enable Random Password on Login	Kasm will reset the password on the associated AD user account, each time the user logs into Kasm.
Enable Create User	Kasm will automatically create the user in AD if it does not already exist.
Enable AD Group Management	Kasm will automatically add/remove users from groups in AD, based on group mappings in Kasm.
Password Length	Kasm will use a randomly generated password of this length for AD users managed by Kasm.
User Container DN	The DN of the container in AD to create new users within. Existing users do not need to be in this container. Example: OU=MyOrg,DC=kasmweb,DC=local

AD Sync Configuration

Warning

Turning off Random Password on Login will break single sign-on to servers in Kasm that are joined to the same Active Directory domain and is not a recommended configuration.

Synchronize AD Groups

If enabled, Kasm will add and remove users to/from groups in AD, based on group mappings defined in Kasm. In order for a group in Kasm to be eligible for synchronization, it must have two SSO group mappings, one pointing to the LDAP configuration with the target AD Sync and one pointing to the source SAML or OIDC configuration. In addition to the Kasm group having the two SSO Group Mappings, the user must also be a member of that group in Kasm, in order for them to get added to the associated group in AD. Users will be removed from the associated group in AD if they are not a member of the associated Kasm group.

LDAP AD Sync Group Mappings

AD User Attributes

By default, Kasm creates users with the following AD attributes and values.

• displayName - The displayName is set to the username as seen in Kasm, unmodified.

• sAMAccountName - Set to the same value as the name attribute.

• name - By default Kasm creates an AD name using the first 9 alpha numeric characters of the Kasm username, domain name excluded, followed by a hyphen and the first 10 characters of the Kasm user ID. For example, a user that logs into Kasm as john.smith@company.com would have a Windows sAMAccountName of john-smit-abc1234567. Use an attribute mapping to name to override both the name and sAMAccountName LDAP Attributes with a username defined by the IdP. See details below for defining attribute mappings.

• userPrincipalName - The sAMAccountName with the domain name appended, see the above definition for sAMAccountName for how that value is derived. Example, john.smith@company.com where the LDAP Configuration Search Base field is OU=MyOrg,DC=company,DC=local would result in a value of john-smit-abc1234567@company.local.

• givenName - The First Name field on the Kasm User is used if present.

• sn - The Last Name field on the Kasm User is used if present.

LDAP attribute mappings can be used to map additional Kasm User fields to AD User attributes and/or overwrite the above defaults. If the source users come from a SAML or OIDC identity provider, administrators can configure attribute mappings, so that the Kasm users will have fields such as First Name and Last Name populated by the SAML/OIDC IdP.

This is a screenshot of SAML Attribute Mappings that cause the Kasm user attributes First Name, Last Name, and Custom Attribute 1 fields to get populated by data provided by the SAML Identity Provider.

SAML Attribute Mappings

This screenshot shows a LDAP Attribute Mapping defined for taking the value in the Kasm User Custom Attribute 1 field and populating the displayName in the AD user created by Kasm. In the previous screenshot, you can see that the SAML Identity Provider provides that value through its configured attribute mapping.

LDAP Attribute Mappings

Changes to AD user attributes are synchronized on each login.

Configuration Examples

• Active Directory / OpenLDAP
• JumpCloud