Hello folks,
I am using a Enterprise version 1.19.5. I see the LDAP auth in ROR misses out if usernames doesn’t match case.
Can we make users match without case (make it case insensitive) ?
for ex.
- username: John123
groups: [ “admins” ]
ldap_authentication:
name: ldap1
cache_ttl_in_sec: 600
And if user logs in as “john123” ROR fails.
Sounds like a Windows vs Unix philosophical issue 
We could create a flag in the configuration about this. But because the majority of the LDAP servers are actually Active Directory servers, it would make sense to make case insensitive the default?
WDYT @coutoPL
We could create a flag, but this is not a good idea to make it case insensitive by default.
It breaks the current contract and we could potentially change behaviour of existing configurations after upgrade - for me it could be a potential security hole.
Elastic engineers have a good point about this, they were basically willing to introduce string transformations for usernames BEFORE they’re sent to LDAP authentication. I.e. toUppercase/toLowercase/capitalized.
Which makes sense, because the case sensitivity in authentication phase is a trait of the LDAP server, rather than our connector. So the best we can do is normalize the casing of the username before serving to the server.
@praveenmak On the other hand, how about configuring the LDAP server to accept case insensitive user names? Should be possible.
@sscarduzio sorry I totally missed to read the question I posted. 
No, LDAP servers are handled by our company. I have no control on that.
@praveenmak we cannot make LDAP user names case insensitive (only the LDAP server can, but you have no control over it) So we could only introduce a flag to take the username, and apply a transformation to it: for example toUpper, toLower, capitalize.
Which one is your LDAP server accepting?
Actually LDAP server is accepting in any form (case , mixed case etc).
The issue is at the ROR level. If I have a config as John123 and user tries to login to Kibana as john123. ROR fails not the LDAP server.
Let me know if I am understanding it wrong.
OK now I understand this better! So because case sensitivity is at discretion of the authentication rule (auth_key_, or ldap_auth, etc) the local groups engine of ROR should let the usernames match in an equally liberal way, ignoring the case. This is something that ROR could accommodate, and it would remove some WTF moments while debugging ACLs involving local groups and case-insensitive external authentication systems.
@coutoPL WDYT?
for any auth rule which checks username at ROR’s level, we can introduce such settings (+ global one). But default will stay as it is now.
OK let’s put it in a Jira ticket, so we will detail the feature design and add it to backlog.
Hi Simone,
Should I create a JIRA ticket?
-Thanks
Hi @praveenmak, we added this to our internal Jira, but the priority is low because we are prioritising Enterprise customers support and roadmap before free users’ features.
Do you have an Enterprise subscription?
Yes, we use the enterprise ROR plugin. The email is itam@lexisnexis.com
OK you should have informed us about your subscription! Will move this to next sprint.
We’ve implemented a feature (readonlyrest-docs/elasticsearch.md at develop · beshu-tech/readonlyrest-docs · GitHub) which should solve your problem. It’s not released yet, but if you with and if you send me a ES version which you currently use, I’ll send you a pre-build to test.