heiglandreas

Hi Paolo.

So the LDAP-Server you are targeting and where the user can not log in is the same LDAP-Server a different application is targeting and where the user can log in?

Does the user have any special Characters in the password? Like f.e. a dollar-sign? or a single quote? or a backslash?

If that’s not the case, You’ll need to contact your webservers sysadmin and try to get the servers error-log. I can’t tell you where those are located as that’s specific to the server ??

Cheers

Andreas

Hi Paolo.

Do you have access to the web-servers error-logs? That’s where the debug-output is sent to.
And can you give me the users username? And perhaps some information about the LDAP-Setup? Is it an AD? do you have a single ldap-server or multiple replicated hosts? and what is the email-address of the user? does that exist more than once?

Sorry for bombing you with questions but I’d like to get a better picture to what’s happening ??

Cheers

Andreas

Hey gildror – Did you get that to work? I’ll mark this thread as resolved, but when you have more or other questions feel free to reopen this thread (if that’s possible) or open a new one!

Hi there.

Thanks for contacting ??

As far as I understand it you want to do SingleSignOn with ActiveDirectory. That’s not what the authLDAP plugin is for, as that only supports loggin into wordpress using credentioals stored in an LDAP-Server (might be an AD though).

But as authLDAP can be one of a number of authentication plugins you can also add a plugin that supports SSO and have the LDAP-Login as fallback.

I did a quick search for “wordpress sso AD” and found (amongst others) these sites that looked promising:

* https://www.ads-software.com/support/topic/single-sign-on-between-ad-and-wp?replies=10
* https://dzone.com/articles/wordpress-auto-sign-iis7-and

Especially the last one requires you to throw together some code, but it seems to be doable.

I’d love to hear whether it worked or not.

Cheers

Andreas

Hey Maiskolben.

It would really be interesting what exactly that Fatal Error-message was. Then I could see how to fix the issue. From what I can deduce by the sparse information that I have it looks like an issue with your PHP-Version. So there’s not really much I can do about.

You are using $dom->getAttributesByTagName() which returns a DOMNodeList which in turn returns instances of DOMNode. So the $item is an instance of DOMNode and therefore the getAttribute() isn’t available. Hence the workaround with attributes->getNamedItem('src')->textContent. Normally the items returned will be DOMElements that implement the getAttribute()-method, but you can’t be sure about that. And as PHP doesn’t support casting to an object I wouldn’t rely on it especially when there is a workaround.

The matter with relative image URLs is rather easy. We are using a plugin that converts all absolute image-links to relative ones as we need the possibility to transfer the data to a different domain. So the “=” doesn’t work for us. ??

Would there be a way to filter that query so that we could manipulate it (rewrite it) after it’s creation? That way the default still has the performance improvement that “=” brings and we could – without rewriting your code – alter the SQL-Statement to use the “LIKE”.

Thanks for your prompt response!

Cheers

Andreas

Gretat plugin. We’d like to use it for a project we are doing. But can you put “soon” into a time measurement? Are we talking about days, weeks or months ’til the pro-version? As we need to have nested comments that pro-verion is a show-stopper for us and we need to know whether we can use the plugin or not.

Cheers

Hi Litin.

Great work! Thanks for bringing that to my attention!

I only see one little catch. As each plugin-developer defines the priority for her or his plugin to be used within the authenticate-Filter you as an administrator are not capable of specifying a list of plugins to be checked one after the other.

So you can (currently) only say “I want to use HTTP and LDAP-Authentication and whichever authenticates a user first, wins”. But it would be much better to say something like “I want a user to authenticate via LDAP and if that fails I want to try HTTP and if that also fails ….” That way you can set a ranking of what to try after one another.

Also your attached code currently also fails if the first plugin fails. As an authentication-plugin has to return either a WP_User or a WP_Error. It can not return NULL as the authentication was either successfull or not.

Or am I missing something?

I’ve opened a corresponding issue in the issue-tracker on github and will report back here!

Thanks for the patch! Great work!

You can always fork the repo and then send a PullRequest in! I’d be very thankfull ??

As the plugin uses the WordPress-internal system to update the password that causes the trigger to sending the mail. But as you said, that’s not really optimal. I’ll check what is possible to either deactivate the password-mail on a new LDAP-Plugin (which I’d personally prefer as the user knows that the password changed due to her changing it outside of WordPress) or by first checking as you suggested.

I’ve opened a bug on the Issue-Tracker on github, but will post here when It’s resolved.

this has been moved to https://github.com/heiglandreas/authLdap/issues/77

Hi Peter. Sorry for getting back so late, but the forum does not relay new questions via mail and I’m not regularily wathing it.

How should the plugin support multisite? Handle ALL sites with one configuration? Or handle every site with it’s own configuration?

I’m not sure it works in the first case, but in the second it should work.

If you would ping me on github (https://github.com/heiglandreas/authLdap) to what exactly you need I could give it a thought and check what’s possible!

Sorry for the late response. As this forum doesn’t notify one of new posts I don’t catch traffic here.

That said, I can easiely answer the last two questions:

As this plugin only moves the way passwords are checked from the local password-database to an external LDAP-Server (authentication) it will not give you any logic to protect certain pages and show others. You will need a different plugin that handles the authorization logic. And it will add every user that logged in via LDAP to the local database.

I’m actually not really sure whether it will work only in one subsite of a multisite-installation but as you might install it only for that subsite it should only hook into that sites login mechanism. I’ll have to try that and might adapt so that it works, if you might need that. IF you’d need that feature, feel free to open an issue at https://github.com/heiglandreas/authldap/issues.

Hope that helps