I second this feature request and ask for anonymous binding to be considered when implementing this. The workflow for this LDAP auth scenario should be something like:

1 - Connect to the LDAP server;
2 - Perform an anonymous LDAP bind;
3 - Issue an LDAP search entry for the given username;
4 - Perform and second LDAP bind, this time with the DN of the entry found on the previous search + the given password.

Hi,

For 'domain' did you try without ?
ldap_bind($ldapconn, $prefix . $username . $suffix, $password);
$prefix to "uid="
$sufix to ",ou=Users,dc=domainname"
Not sure it does the trick, but think yes.

We make a ldap bind with password given by user : why try to make an anonymous bind before ? To validate username ?

I have to some test, but think it's OK (i use slapd for my email)

Menno, i set you in monitoring, because you are our specialist. I think it's already ok in LDAP plugin. Just need confirmation :).

Thanks

Denis, glad to see such a quick reaction regarding this topic. I found this image that shows what I meant with the bind and subsequent search: http://wiki.alfresco.com/images/d/d7/Search_and_bind.png

Just to strengthen the example, lets say we have this kind of LDAP implementation in limesurvey.org and rolando_isidoro is a user, that the authentication workflow would be something in the likes of:

1 - Connect to the limesurvey.org LDAP server;
2 - Perform an LDAP bind using the connection established in step 1 (this can be done anonymously or using credentials for a user with permissions to perform an LDAP search);
3 - Issue an LDAP search using a filter "uid=rolando_isidoro" which should return a single result entry;
4 - Perform a second LDAP bind, this time with the DN of the entry found on the previous search, something like uniqueIdentifier=12345,ou=agents,dc=limesurvey,dc=org and which doesn't contain rolando_isidoro anywhere, plus the given password.

Possible breakpoints to check on this workflow that would result in authentication failure would be:

1 - Failed to connect to LDAP server;
2 - Failed to bind anonymously or with the fixed search user credentials;
3 - No results or more than one entry on the LDAP search;
4 - Failed to bind with the user DN and given password.

Yes, but : why do an anonymous connection ?

Why not , like now:

• LDAP connextion => if error : setAuthFailure(1, gT('Could not connect to LDAP server.'));
• LDAP bind user/pass => if error : setAuthFailure(100, ldap_error($ldapconn));
  etc ...

Why add an anonymous ldap connexion?

This report is asking for functionality already added in the current version of the plugin I think. I added a screenshot that shows the options currently available in 2.05+

Since we have a plugin system, you are free to take the code and create a personal plugin that fits your needs better. This plugin was made as an example and proof of concept. If you like to adopt the core plugin and enhance it and share that with the world, feel free to open a pull request on github. I am happy to assist with any difficulty you face talking to LimeSurvey.

Thanks to mdekker : confirmation :already in core plugin .

Thank you

Re-opened on user request.

mdekker: "This report is asking for functionality already added in the current version of the plugin I think."

I installed the latest LS version and can say without any doubt that this LDAP auth scenario is not possible.

Currently you can only authenticate in LS through LDAP if the user's DN contains the username provided it the login form. But that is not the case is a lot of LDAP setups.

Let me throw away 2 examples that hopefully will set apart the differences of the two methods. Lets assume I have a rolando_isidoro@limesurvey.org account on a LS LDAP setup and that my uid is rolando_isidoro.

Scenario 1 (possible by the current core plugin):

• dn: uid=rolando_isidoro,ou=people,dc=limesurvey,dc=org
• For this to work one would simply have to fill the "Username prefix" setting with "uid=" and the "Username suffix" with ",ou=people,dc=limesurvey,dc=org".

Scenario 2 (this feature request):

• dn: uid=12345,ou=people,dc=limesurvey,dc=org
• rolando_isidoro is not part of the dn, so there's no combination of prefix + suffix that would result in that dn.

DenisChenu: "Yes, but : why do an anonymous connection ?"

The first bind operation can be done anonymously as long as the LDAP setup allows for anonymous searches. This way there's no need for an entry of an user dedicated exclusively to perform searches.

DenisChenu: "This plugin was made as an example and proof of concept. If you like to adopt the core plugin and enhance it and share that with the world, feel free to open a pull request on github."

I really think that this enhancement as part of the core plugin would be a plus, since covering multiple LDAP authentication scenarios out-of-the-box could work as a boost to LS's user base.

I'm usually in #limesurvey as gerundio. Come by if you'd like to discuss this topic.

Ok to get things straight, current plugin is working fine for all logins when we know the uid. Is that right?

You would like to add functionality to lookup the uid by performing a search on the directory and using a result to do the authentication. If you would like to program that and add it to the core plugin you can always open a pull request. Please make sure the basic scenario should still be possible. If you feel that is too complicated, you can also create a separate plugin that only supports your scenario. We are working on setting up a directory for etensions on http://www.limesurvey.org/en/extensions to showcase what the community created.

We created a plugin system since we can not support setups we can not test. This way the people who need it can create their own extensions or modifiy existing ones and preserve the changes during upgrades. The current ldap authentication plugin is working for the basic scenario, and ofcourse it could be extended to support even more scenarios. We would like to leave that last step to the community so we can focus on improving the survey system.

Since the plugin functionality is new, we are here to help you when needed.If you need help in extending the plugin, or you miss hooks to get the things done that you want to do. Feel free to ask, we can support you with that. Just the actual coding of the functionality will not be done by the limesurvey team.

mdekker, thanks for the prompt reply. I don't have free time to develop it on my own for now, I'll try to talk to management so I can do it on working hours since we use LS here and that would only be fair to support the project.

Lets leave this feature request so that someone can read this and might pick up on the plugin enhancement.

I've implemented this in
https://github.com/LimeSurvey/LimeSurvey/pull/175

Hi Thibault, nice to see you back again!

Great work!

I had just created a fork on github to implement it, but no need for that now. Looking at the code it's very clear and checks for all the possible breakpoints.

Great job! How can we help so this can be pushed to master and hopefully get on the next release? :)

If you could test the code and report back here that would help. I can only do the merge tomorrow. I will certainly review and merge the pull. Thanks for the work done!

Hi Menno,

Just to let you know that I tested it on both simplebind and search-and-bind setup.

I agree that it would be great if rolando_isidoro could test it as well.

Thibault

PS: Hi Mazi, good to hear from you again.

@rolando_isidoro, I have not tested anonymous bind search, can you test it ?

TIA,
Thibault

Just tested it, anonymous bind search is working as expected. Nice work :)

It's not a feature request , but why don't use 2 seperate core plugin here ?
Then user can activate 'ldap by ..' on 'ldap by bind' ?

Less parameters and less test for each user.

But : maybe it's a bad idea (and i don't found 2 great name for each plugin then it's surely a bad idea ;))

Denis, I have thought about this possibility but the 2 plugins do the same things, just in different contexts...

It is just a pity that we have the best data-entry system in the world with relevance and so on, and that our settings system can't use it... otherwise I would have hidden the parameters for search-and-bind when simplebind is selected.

Unless you see how to do this easily ?

Thibault

Hi Thibault,

No it's more a reflexion than a clear asking. LDAP access need plugin activation, then MAYBE we can have 2 different plugin.
BUT a lot of code are the same : we need to fix 2 times some code .... bad idea :)

My 5 cents on this one is that the number of parameters won't be issue. The form for setting up LDAP auth after this new feature development is quite compact and understandable.

I guess it won't be a problem for any user assigned to set LDAP auth, since they'll have some knowledge of what fields should or not be filled. In my experience, when they don't a simple contact to the LDAP admin does the trick.

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=13990

I made the options appear / disappear depending on the ldapmode.

Great option.

I've used it to add the last missing option for a complete LDAP authentication plugin: the possibility to set start-tls.

Here is the Pull request:
https://github.com/LimeSurvey/LimeSurvey/pull/179

Is there a way to add "tips" to the settings so as to limit the size of the fields description and only add examples on tips ?

Another question: what is the bes Yii-friendly way to log messages.
Indeed, it would be convenient to have meaningful warning/error messages in a log file when the ldap server is unreachable or when the bindn can't connect, ...

I'm not sure if Yii:trace is the correct way, I've seen little reference to this on th 2.x branch.

@rolando_isidoro,

Can you test my last version ?

@lemeur, done testing and it's working fine. Great work on making it cleaner and more usable.

I second your opinion that "tips" would be much more UI friendly that such long field descriptions.

2 new LS versions have been released since the development and tests of this feature ended without it being included. Is there anything left to do before the code can be pushed to master?

@isidoro,
The feature has been included in the first release since the merging.
I just messed up the commit message, and thus it didn't appear in the changelog.

My mistake.