Ian-Kasmweb
commented
3 years ago Original comment by Matt Mcclaskey (Bitbucket: [Matt Mcclaskey](https://bitbucket.org/Matt Mcclaskey), ).
We have confirmed that the auto addition of parentheses to the search filter is in our code and will update it to only add them if the user’s configuration is missing them. While this allows for users to create invalid search filters, we don’t want to break people’s configurations when they update versions.
I’ve put in a ticket to update the Group Membership Filter hint to show {0}. Both of these should be addressed for the next release.
We already have internal tickets in for allowing the admin to set a default LDAP domain, and thus usernames without the domain would be supported, but only for the a single LDAP domain. I put in an internal ticket to auto populate Kasm User attributes from LDAP attributes when creating the user.
j-travis
Original report by Lev Elupirl (Bitbucket: [Lev Elupirl](https://bitbucket.org/Lev Elupirl), ).
LDAP login domain
There’s no way to customize the login domain when LDAP authentication is enabled. This is especially important when using cloud LDAP services. For example, my Search Base when using JumpCloud is:
This forces the user to use an email login like so:
kuser@jumpcloud.com. Preferably there should be some way to use a custom domain, or read from the user’smailLDAP attribute for login.LDAP auto-populated fields
When an LDAP user logs in for the first time, and their user is created within Kasm from Auto Create App User, there should be an option to additionally auto-populate certain attributes into the user profile. At the very least, this should the first name and last name fields.
LDAP user interface
When creating a new LDAP configuration, typing the Service Account Password should use a password form field instead of a regular text form field.
Additionally, in the same creation interface, the Group Membership Filter example provided in grey when there’s no text, shows the example as:
Note that the example incorrectly gives the
{}placeholder, when it should be{0}. Also, mentioned in Valid LDAP query filters fail as "malformed" the filter confusingly omits the outer parenthesis. I ran into this same issue, and the errors I got made it initially difficult to troubleshoot. The current way the filter needs to be inputted technically doesn’t conform to the proper notation, i.e. the user should be required to input the outer parenthesis.