I am writing in previous version setting in User DN needed "uid=". In latest version this can be omitted.

Meaning when upgrading authentication starts to fail.

old as it needed set in the plugin to work properly and will be inherited after upgrading:

new:

Since this is not explained in the inline help, this needs changed.

I guess you are using direct bind, otherwise changing the User's DN should not make a difference.
If that's the case, you had before in fact a bad configuration. You most probably don't have LDAP accounts with DN "uid=<the_name_you_use_to_login>". That worked only due to a bug that has been fixed in 4.3

In earlier 4 versions, User's DN was not taken into account. Doing direct bind was always done with the login, whatever you put in User's DN. Changing the User's DN to [username] (or leaving it empty) results in the same behavior.

No that isn't the case.
In the earlier 4 version, the plugin would not function when this field was left empty. Just [username] was not sufficient. "uid=" as explained in the inline help was required to make it work..
Case is is that after an upgrade, existing settings no longer apply and need adjustment. "uid=" to be removed.
This is not clear in from the newer versions inline help as this is the same string as in the older versions.

Can you tell me more in detail what is the case then? Please provide the full config and some logging (without the password).
Removing "uid=" is not the solution for every setup and will certainly break other configurations than yours. So to understand what and how to clarify things, I need to understand your case.
Do your LDAP entries have an attribute uid with the login as value? I guessed you use AD and the email address as login, no?

I think you miss the point.

It is about having to change the settings after upgrading. Old settings no longer apply.
First uid= is required, after upgrade it isn't. Nothing in our AD setup or the way it should be addressed changed.
After upgrading j! and plugin, the new setting is required.
So something in the plugin changed and admins are not warned about that change.

If you change the way User's DN is handled you need to document that so admins are made aware.. That is the only thing I am asking.

@pieter-groeneweg I understand you ask to add 'remove "uid="' to the help, right?
I tell you this would certainly break other user's configurations, so it can't be done.

Moreover, it should not even be necessary to remove "uid=" or change anything to "User's DN", although I understand it was in your case. That is why I'm interested to know your case.
Please try to understand you may be onto something. This may be more than just a documentation issue and be a plain bug.

Ok,

For both the logs when it goes wrong will not go as far as:

2023-10-16T10:20:38+00:00	INFO xxx.xxx.xxx.xxx	ldapfailure	Username and password do not match or you do not have an account yet.
2023-10-16T10:20:38+00:00	WARNING xxx.xxx.xxx.xxx	jerror	Username and password do not match or you do not have an account yet.

When it goes ok, the old plugin doesn't log any at all even with debug enabled.
Nothing there.

The new plugin logs good login attempts. It does log the bad ones if at least the user exists in AD but password is wrong. But that is expected behaviour.

Would you know the variable string for the old and new plugin? then I can add a DEBUG log line in the code to see what value it contains.

Thanks. Can you also share the DEBUG log lines from good login attempts using the new plugin?

A failed login (using the non-working configuration) in the new version should log a more detailed error.

I'm not sure what you mean by the variable string? If you are using the "Bind and Search" method, in the old version, the plugin logs in using $credentials['username'], in the new version using a created $dn
So you can try to use one of these.

Ok thanks, will take some time, I will plan this for second half of the week.