Wordpress plugin communicating but fails


I have a functional privacyIDEA server running on a LXD Ubuntu Server 20.04 container, installed using apt packages. Our LDAP Account Manager (LAM) works perfectly with the PI server.

On Wordpress I’ve installed the Strong Authentication plugin. Activating, configuring, and saving the settings of the plugin results in a “Saved settings” message within Wordpress.

For testing I can log in with password only, which fails as expected. But it also fails when logging in with ‘password+TOTP’ (without the +). I set the logs to debug and can see in /var/log/privacyidea/privacyidea.log that the password+TOTP is received, but there appears to be no effort to separate the two values for appropriate validation.

Is it possible that I should enter the two values differently? For example, if the password is ‘abcdef’ and the TOTP is ‘123456’, should I be entering in the Wordpress password challenge ‘abcdef123456’ (which currently fails, so something else would explain the problem)? Or perhaps ‘abcdef,123456’? Or something else?

Thanks for any help.

I think I understand the logs a little better, and it looks like the privacyIDEA server did try to split the password+TOTP, based on this:

[2021-11-02 16:39:18,904][26126][140591642093312][DEBUG][privacyidea.lib.tokenclass:1285] Splitting the an OTP value of length 6 from the password.
[2021-11-02 16:39:18,904][26126][140591642093312][DEBUG][privacyidea.lib.config:185] Entering get_from_config with arguments () and keywords {'key': 'PrependPin', 'default': False, 'return_bool': True}
[2021-11-02 16:39:18,904][26126][140591642093312][DEBUG][privacyidea.lib.config:198] Exiting get_from_config with result True
[2021-11-02 16:39:18,904][26126][140591642093312][DEBUG][privacyidea.lib.utils:1310] PIN prepended. PIN length is 14, OTP length is 14.
[2021-11-02 16:39:18,905][26126][140591642093312][DEBUG][privacyidea.lib.policy:185] Entering match_policies with arguments (<privacyidea.lib.policy.PolicyClass object at 0x7fde01a14310>,) and keywords {'audit_data': None, 'request_headers': EnvironHeaders([('Host', 'idea.chem.umass.edu'), ('User-Agent', 'Wordpress'), ('Accept', '*/*'), ('Content-Length', '351'), ('Content-Type', 'multipart/form-data; boundary=------------------------d5ded0eedbcdef78')]), 'pinode': 'localnode', 'name': None, 'scope': 'authentication', 'realm': None, 'active': True, 'resolver': None, 'user': None, 'user_object': User(login='maher', realm='bmbchem', resolver='BMBChemLDAPServer'), 'client': '[wordpressServerIP]', 'action': 'otppin', 'adminrealm': None, 'time': None, 'sort_by_priority': True, 'serial': None}

But then I get this, which I don’t quite understand:

[2021-11-02 16:39:18,907][26126][140591642093312][DEBUG][privacyidea.models:434] we got a hashed PIN!
[2021-11-02 16:39:18,908][26126][140591642093312][DEBUG][privacyidea.lib.config:185] Entering get_from_config with arguments () and keywords {'key': 'IncFailCountOnFalsePin', 'default': False, 'return_bool': True}
[2021-11-02 16:39:18,908][26126][140591642093312][DEBUG][privacyidea.lib.config:198] Exiting get_from_config with result True
[2021-11-02 16:39:18,925][26126][140591642093312][DEBUG][privacyidea.lib.token:198] Exiting check_token_list with result (False, {'message': 'wrong otp pin'})
[2021-11-02 16:39:18,926][26126][140591642093312][DEBUG][privacyidea.lib.token:198] Exiting check_user_pass with result (False, {'message': 'wrong otp pin'})

And I’m not using a PIN.

Any thoughts on the problem would be great.

I realized that I still had Wordpress authenticating directly to the LDAP server using a plugin, and based on this link,

The Wordpress plugin authenticates users only against privacyIDEA

So, I removed the LDAP auth plugin and relied entirely on the Strong Authentication plugin. Still no success. Lots of communication between Wordpress and the privacyIDEA server, but never successful authentication. I am baffled.

Through experimentation I now know that Wordpress is authenticating successfully with the TOTP code only. No password.

I’m pretty sure this is not how it’s supposed to work. Can anyone share any guidance?


The wordpress plugin sends the complete password entered to privacyIDEA. The wordpress login is completely replaced.
So you have to assure to verify both factors on privacyIDEA.

@cornelinux, thank you for this. That helps. I determined that I needed to set otppin=userstore with an authentication policy, and then password+TOTP in Wordpress works. However, now LDAP Account Manager (LAM), which separates password authentication (itself) from TOTP verification (privacyidea), does not work.

I’ve created the auth policy that sets otppin=userstore so that it has a condition of:

HTTP Request header : User-Agent : equals : Wordpress

which works, but LAM continues to not work. I don’t know why this conditional policy would continue to affect LAM’s authentication.

I tried to create a policy with the condition of:

HTTP Request header : User-Agent : !equals : Wordpress

which does not have otppin set, but it still prevents LAM from authenticating.

What am I missing? Thanks.

Of course if you have one application (LAM) which you only want to verify the 2nd factor and another application (wordpress) where you want to verify both factors on privacyIDEA, you need to have different policies for these two applications.
Now the challenge is, that you need to distinguish the two applications.
Easiest thing would be IP addresses. Going for the user-agents is a nice idea but a bit tricky.
If the user-agents are transferred correctly, then you should set otppin=None in the policy for LAM.

Thank you @cornelinux. This works.

I now have two authentication policies, both with conditions for respective client IPs. And, as you suggested, the LAM policy is set with otppin=NONE and the Wordpress policy is set with otppin=userstore. Success!

I still see a log record of:
There is no machine with IP=IPAddress('[ip_address_of_respective_client]')
Is this referring to the absence of a “Machine” record in the privacyIDEA server? Is it a problem?

Thanks again.

This has s.th. to do with machine resolvers, unfortunately.
You can ignore this.