heiglandreas

Hey Sem.

Sorry for this inconvenience! This sounds rather drastic.

To avoid such issues I recommend to always have an administration account that is only available locally. I am usually setting up my WorPress installations with a dedicated – local only – wordpressadmin user that will never be handled otherwise than locally to not loose admin-access like in your case. This is just a fallback account that is not for regular admin use but for such cases as you experienced.

Secondly I would always test such settings in a staging environment to make sure that I am not breaking production

But now that you have the situation you have:

I would first decativate the plugin by manually renaming the folder authldap in the wp-contents/plugins directory. Adding a letter will suffice. That way the plugin is decativated and will for now not interfere with logins any more.

Then You will need to manually edit the database to at least allow your own user admin access again: Find your user-id and in the usermeta table for the meta_key wp-capabilites set the meta_value to a:1:{s:13:"administrator";b:1;} for your user-id. That should allow your user-id to have admin access again.

Then I’d create the aforementioned separate administration fallback user and test the settings in a staging environment before reenabling the plugin (renaming it back to authldap and activating it in the plugin list).

This looks like you have updated PHP to a newer version but didn’T install the ldap-extension (which is a requirement for AuthLDAP to work.

With Ubuntu that should be something like apt install php8.3-ldap

For more infos check out https://www.php.net/manual/de/book.ldap.php or ask favourite search engine for something like install php ldap

Hey there.

This looks like you have updated PHP to a newer version but didn’T install the ldap-extension (which is a requirement for AuthLDAP to work.

As the extension is not installed, the function ldap_connect is not available and therefore the scripts fail due to an undefined function.

Please check with your server-provider how to install or activate the ldap extension in PHP.

Cheers

Andreas

Thanks for the feedback! That is good to know that there might be issues with Googles recaptcha. I will keep that in mind and might add a hint to the documentation.

This seems to be resolved

Hey @juanarr

Thank you for your patience. Could you provide me with some (sanitized) screenshots of your configuration? Either here or via Mail to andreas AT heigl DOT org.

Also check the “Debug authLdap” checkbox and add the log-entries from AuthLdap as well to those informations.

That should provide me with the basic infos to see where the problem arrises.

Feel free to use my Public GPG-Key from https://andreas.heigl.org/publickey/ to encrypt the email.

Hey @d0m1: I’ve released a new version that should – at least partially – fix your problem. I’d really appreciate your feedback!

Hey @juanarr: Would you mind opening a new thread for this? It will make helping you easier for me and everyone else.

Thanks!

In the meantime: To help you I need some more information. Most importantly the configuration of the plugin and from that the LDAP-URI is the most important one.

Additionally if you could tell me (and everyone else checking) what your previous versions of the plugin, WordPress and all the things you updated were and to what you updated.

Hey there.

THanks for raising that. Indeed that was what unchecking LDAP groups override role of existing users was supposed to do. And also did in previous versions of WordPress.

When the plugin was created there was only one role assigned to a user and that would then not be overwritten by the plugin when the option was unchecked.

In a later version of WordPress though it became possible to assign multiple roles to a user. The plugin though still only assigns the first of those roles. And therefore breaks your current setup.

I’m sorry about that but I am actually right now preparing a new release that should fix that. If you want to, you can download the new version of the plugin and try to install that to see whether it fixes your issues.

Hi.

The plugin allows you to have LDAP/AD based accounts as well as WordPress installation based accounts in parallel.

Internally it checks whether it can authenticate a user based on the configuration against LDAP/AD and if that does not works, then the authentication process is delegated to the next authentication method which then falls back in the end to authenticating against the WordPress installation.

YOu can also set up the plugin in a way that the authentication is handled against LDAP/AD and the authorization (group memberships and therefore access rights) are handled via the WordPress roles.

Each user that authenticates via LDAP/AD is created in the WordPress installation and can then be managed within WordPress regarding access rights.

Regarding the account profiling though I’m not sure I 100% understand what you want to do. The plugin allows to add users to different WordPress groups based on the LDAP/AD groups they are member of. If you can create different sections for different users via groups in WordPress then the plugin should allow you to populate those WordPress groups with users based on information you find in the LDAP/AD.

Hope that helps and answers all questions. If not, please get back.

Regards

Andreas

You should not disable the certificate checks ??

But your issue gives me an idea to extend the app so that you can easier use self-signed certificates.

BUt to solve your issue: Is the problem existing on one server and not on a different one? COuld it be that the list of root-CAs is different on the two machines? Or is that literally on the same server?

If it’S on 2 different machines, check out https://serverfault.com/a/747884 and see whether there is perhaps a msimatch in the files on those two machines.

• This reply was modified 1 year, 2 months ago by heiglandreas.

Ah! OK! Sorry. I misinterpreted your comment! So you configured STARTTLS within the plugins config and there it is not working!

Is the LDAP-Server using a self-signed certificate? Or is that a cert from one of the well known CAs?

If it’s a TLS issue, then nginx is the one that needs configuration as it is doing the TLS termination and delegates requests to the PHP backend as a proxy.

when that is working propperly we can figure out issues with PHP.

I’d search my favourite websearch engine for something like “TLS nginx apache” to find how to configure nginx using the same certificates as apache. This might be the wrong forum for that ??

That usbstrange. In general the plugin doesn’t care whether php is used as apache module or via fpm. I myself have it running via FPM in some installations.

could it be that the FPM installation is using either a different PHP installation without the LDAP extension or that the LDAP extension is configured differently for FPM?

2.5.7 should have fixed your issue…

Can you send me the (sanitized, I don’t need passwords) error log to [email protected]? That’d be really helpfull.