-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LDAP Authentication changed from cn to displayName in Greenlight #1566
Comments
The fix to this is probably to allow attribute mapping for LDAP instead since there's so many different possible fields and configurations |
Hi, |
On second thought, I agree with you. It was a change that snuck into the last release., We'll get it reverted in the next release |
Any movement on this? |
Going to revert this in 2.6.2 (which should be released sometime today) |
Greetings ! How can I return the "displayname" parameter? just like at the beginning of the topic) looks like a bug for us |
@farhatahmad is attribute mapping still on the table? |
+1 Is there an ETA for LDAP attribute mapping? Until this is resolved, we cannot really upgrade because locking ldap users to their login name is not ideal... |
Would be great if there will be a solution soon, we also have this issue #1759 It seems the change of bn-ldap-authentication from 0.1.2. to 0.1.3 changend this behaviour. For the local installation this works: For the dockered version you have to make these changes inside the container and then commit it to make the changes persistent. |
Presumably I encountered the same problem. As far I understand it, the changed behaviour is not caused bei Greenlight (correct me if I am wrong), but by send_ldap_request(). I logged the LDAP connections
Before the update I got something like: Now I get:
What I want is again the content of |
change the version of the bn-ldap-authentication Gem to 0.1.2 back, see my previous post. |
We upgraded Greenlight last night and now after user's login, Greenlight is using the LDAP attribute displayName rather than the LDAP cn atttribute. Can we get this reversed or, is there a way to pick which LDAP attribute controls how a user gets displayed.
The text was updated successfully, but these errors were encountered: