LDAP login issue

Hard to say much without a debug log. See http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/#HEnableLDAPdebuglog.

logSnippet.txt (16.5 KB)

This is a snippet from our log.
It seems that Xwiki didn’t find the already created user from the database.
If I search for the user I see 3 users, 2 with “_”

I see several started authentications in this log file but not the end. Missing “LDAP authentication succeed with principal…” for example.

Anyway the way the authenticator find an already existing user is by searching for an object with “XWiki.LDAPProfileClass” and a field uid equals to the passed login. Could you edit the user profile with object editor (?editor=object if you are not advanced user) and see if you can find this object.

Yes, I can edit them and find that object…I’m trying deleting those users and retrying to login, it still hangs…I think I understand where is the error (please check the second log file): those users are created because xwiki hangs on the first login and something goes wrong (and very slow) during the database saving, an user (or browser) makes a second call and Xwiki finds an already present user but not “complete” ,so tries to create another one.
How can we fix this situation (database)?
Thank you

logSnippet2.txt (35.3 KB)

If you have a lots or very big LDAP groups in your mapping configuration it might take a while to cache all of them. If that’s your issue, http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances#HDisableLDAPsubgroupssearch might help.

As for user created without the object and then modified it’s indeed not very nice and mostly caused by laziness. Needs to improve https://github.com/xwiki-contrib/ldap/blob/master/ldap-authenticator/src/main/java/org/xwiki/contrib/ldap/XWikiLDAPUtils.java#L1276. But the time between the two saves is supposed to be very small.

We don’t use LDAP groups, so do you think that the database exception depends on LDAP slowness?

No, the only officially slow thing I know during LDAP authentication is group sync (and it does not have anything to do with the database).

Are you sure that this could not be caused by an error in database (first I deleted those users)?
Now for example I can login with that user but in log file I see the “_1” user, so the ldap user is correct but has a wrong object linked (or something like that).

I never said that. I have absolutely no idea what your database would be slow, just saying that it should not have anything to do with the LDAP authenticator.

Did you look at the object ?

Yes, the situation is that the correct user has no LDAPProfileClass object, the user_1 has the LDAPProfileClass (and this one has correct data).
I think this is a database error (is there any way to safely clean users in database? In order to avoid exceptions like logSnippet2)
thank you

Did you try to delete the user ? You have data in that user profile you need to keep ?

I think that the LDAP extension that creates the user in XWiki should not create a user if this one is already present. If this one is created it means that we could intercept this code and avoid a creation of another user (this one can be a property if one will).
Now I try to delete the user, I will update you then.

And this is exactly what the authenticator is doing and to find existing user it use the object I described to you.

I deleted the user, now I’m trying to login again. I noticed two things:

  1. when I delete a user, using the users interface, it does not refresh and says no messages (I think it is a frontend issue but because of it I cannot know when a user is really deleted).
  2. Now that I waited for a longer time to login (after deletion) I can login with that user and it correctly creates it.

It seems to be a timing problem (synchronization), in production we cannot enstablish that time (and the number of retries that a user can do for the login).

I confirm that I can reproduce this bug and it is a timing problem. If I delete a user and I don’t wait an estimated time, Xwiki generates the problem (I waited about 5 min to solve the problem, why Xwiki takes so long to safely delete a user?). It is caused by the interface that does not confirm when a user is really deleted.
I think there should be a fix to avoid this issue, backend side with a synchronization between deletion and creation and frontend side with an interface update (a message that confirms the deletion).

Let’s sum up the issues that I can report:

  1. User interface has strange behaviour when deleting users (it does not refresh correctly or confirm the operation) and when creating new users (it’s very slow and sometimes it does not respond).

  2. Sometimes, I don’t know why, the LDAPProfileClass is not linked correctly to a user when a user tries the first login. Maybe it’s a latency time or another unknown reason, this problem generates the creation of a user that has not that ldap object associated. This is a issue because XWiki thinks that the user already exists and when the user tries to login, the code on XWikiLDAPUtils.java:1328 goes wrong and thinks to have to update a user that has no LDAP objects. This is the starting point for the “_1” - “_n” users that XWiki creates after the first login.

I think that we can use a workaround for the second point (manually associate the LDAP object to the right user) but this but has to be resolved soon.

Thank you
-M

Do you mean that you are creating users from the UI ? Don’t you have only LDAP users ?

I made an automated procedure that creates users on XWiki, it works in the same way that Xwiki creates them with the UI.
I found those UI-response bugs because I used the UI for my own tests.

The LDAP authenticator link a user profile to an LDAP id only if the user profile has been created by the authenticator. If the user already exist it assume it’s a regular XWiki user and don’t overwrite it.

So if you create the XWiki user before the first authentication then indeed the authenticator will never reuse it, if you want it to reuse the user you need to add an LDAP profile object when you create the users.

This error was very annoying because neither the admin either the user knew what really happened.
Thank you for this info (maybe it is better to put an alert on ldap autenticathor page in case someone migrates and has the same errors) but there should be a prior check that avoids the creation of those n-users.
I think simply adding an if statement into ldap plugin code to check if the user found in xwiki database has the LDAP object added (if I enabled the new ldap extension and I set try-local property to false but a user inside the database has no ldap class, we should avoid any other errors adding that object or alerting the user).
Second, for the next versions there should be an UI improvement with the cases I wrote you because now it is totally not responsive.