Hi @chelseycontier, thank-you for your detailed message.
On multisite, since user roles are stored in each subsite, we use a wp-cron job named wordfence_ls_role_sync_cron to periodically sync roles once per hour by default, or when a user role is changed. If DISABLE_WP_CRON is being used on the individual site(s), that might cause the issue you’re seeing if the alternative way of running cron jobs isn’t firing.
If that doesn’t seem to be the issue, it might also depend on how the role was created. Wordfence adds capabilities to roles using WordPress’ own functions, but some plugins create roles on the fly without them being stored in the database. You may need to look into how your plugin adds the custom roles.
Let us know what you find out!
Peter.
Hi Peter,
Thanks for coming back to me.
We do have wp-cron disabled, but only because we run cron from the CLI (via crontab and a shell script), so I don’t imagine there’s any issue on that front.
We register our roles via a roles.json file which is eventually converted into wp functions, so I don’t think that’s the reason why we’re encountering this issue either.
When I’m looking at the 2FA settings in the network admin (where WF is network activated), I can see that 2FA is required for all default WP roles. We’re going to be looking into getting our custom roles registered at the network level to see if that allows us to add 2FA to the additional roles we’ve created. Hopefully that will resolve the issue of not being able to add 2FA to our custom roles.
There does still seem to be buggy behaviour around default roles we’ve modified. At the moment, even though the editor role (which we modify in our roles.json file) has 2FA required, there’s no option to configure 2FA for editor users: the user list shows ‘not allowed’ as the 2FA status for this role. https://smile.d.pr/i/thd9sV
What this means in practice is that 2FA is being enforced for the editor role and is preventing users from logging in once the grace period has been exceeded. A newly added editor user can log in fine (still within the default grace period), but an editor who’s been a member of the site for longer than the 2FA grace period gets the message: “LOGIN BLOCKED: 2FA is required to be active on your account. Please contact the site administrator.” As the administrator, I have no way of extending the grace period for editor users because 2FA is ‘not allowed’ for that role (despite being required in the Wordfence settings).
Hopefully that clarifies the problem further so you can advise us what we could possibly do to enable 2FA on custom roles/default roles that have been modified.
Hi @chelseycontier,
Thanks for the comprehensive description into what you’ve tried and are seeing. I think it’s best at this stage to also send over a diagnostic from the main site so we have a little more technical background of the server and how Wordfence/WordPress is set up to result in the outcome shown in your screenshot.
You can send that to wftest @ wordfence . com by finding the link at the top of the Wordfence > Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.
NOTE: It should look as follows – Screenshot of Tools > Diagnostic > Send by Email
Many thanks,
Peter.
Hi Peter,
Thanks very much. I’ve sent that diagnostic report over now. Just to note, we had to switch 2FA for the editor role to ‘optional’ (and manually delete wf 2FA rows in the database) for the 3 users who were blocked in order to allow them to log in. This seems to have triggered something such that 2FA is now available on all editors (where it wasn’t allowed before).
Chelsey
Hi, we’re still experiencing issues with this: deleting 3 wfls grace period rows from the wp_usermeta table seemed to help things in December. 2FA was available on default user roles and users were able to log in once more. We therefore re-activated 2FA on all roles.
I’m not sure what’s changed, but about 2 weeks ago 2FA once again began showing as ‘not allowed’ for all roles beyond admin/superadmin and users with default WP roles (such as editor) are getting an error message at login saying they’re blocked because 2FA is required on their accounts.
This makes a certain amount of sense: 2FA is required on all default WP roles, but since 2FA is apparently ‘not allowed’ for any non-admin users, editors etc. can’t actually configure their 2FA settings (and admins can’t extend their grace period). Users with custom roles (added to sites via a json file using standard WP functions) are able to get around this because WF can’t currently see those roles in order to enforce 2FA. The crux of the matter seems to be the fact that 2FA is not allowed on standard roles: https://smile.d.pr/i/GDfmVz
Our current workaround is to extend the grace period to 99 days to allow users to login. This is obviously not ideal.
Is there any update on your side or any further ideas about what’s causing this behaviour?
Hi @chelseycontier,
I checked back to the diagnostic you sent before and I can see DISABLE_WP_CRON doesn’t appear to be enabled, there are no overdue jobs, and wordfence_ls_role_sync_cron appears to be scheduled and not overdue.
See if you can pick an affected user and verify they don’t currently have any multisite membership across the network where their role is “None / No role for this site”. In each subsite the user is a member of, confirm the role’s capabilities are consistent as multisite stores roles per-site. If the User Role Editor plugin is being used as suggested by the diagnostic, confirm it isn’t applying different capabilities on different subsites for the affected role.
Also see if the “Not allowed” state correlates with role updates (saving roles/changes), since you saw a temporary recovery after clearing wfls grace rows and toggling settings, which could be consistent with capabilities being overwritten later.
Thanks again,
Peter.
Hi Peter,
Thanks for coming back to me. Just to confirm: yes, we’re using User Role Editor, but more as a diagnostic/testing tool than to actively manage permissions for the different roles. Our roles defined with capabilities in a central json file that then builds roles through the usual WP functions. If we make updates to this file, we then run a /wp-admin/users.php?force_roles=true to bring all roles/permissions back into alignment.
Here are 2 example users experiencing this issue:
Mike only has access to the flagship site with the ‘editor’ role. There are no sites on which he has ‘no role’. As he’s only on this one site, there are no comparisons to be made between his permissions on different sites. The permissions he has are consistent with those defined for the role in our json file, except that gform_full_access is granted when it shouldn’t be (we’re looking. into this separately). 2FA is shown as “Not allowed” even when his role is changed to a custom role (‘executive’) and back to ‘editor’ again. Current workaround: give him the custom role ‘executive’ so he can log in, since 2FA isn’t available for that role and therefore doesn’t block him.
Chelseytest (my main test user) has access to all 5 subsites with the ‘contributor’ role. There are no sites on which I have ‘no role’. There are one or two differences in permissions on some sites (e.g. I have the ow_submit_to_workflow perm on one subsite, but not on any others – URE was used to add this one perm for testing). I often switch the role of this user. 2FA is shown as “Not allowed” across the board, even when perms are completely consistent across all subsites. Current workaround: manually update wfls grace period DB entry to 99 so that 2FA temporarily doesn’t apply.
We added another test user (chelseytest2) whose role has not changed, but who is blocked from logging in because of 2FA. This user is an editor and 2FA is “not allowed”. When looking at the user list on each subsite, only admins show expected 2FA values (active/inactive/locked out), all other users, including those with core WP roles like editor or contributor, show as 2FA not allowed, despite Wordfence being configured to require 2FA on all default roles.
I don’t know if that helps to clarify anything or points to anything else we can test to get to the bottom of the issue?
Thanks very much for your continuing help!
Hi @chelseycontier, thanks for the extra details.
Since Mike/Chelseytest aren’t showing “no role” anywhere and even core WordPress roles (Editor/Contributor) are showing 2FA “Not allowed” across subsites, it looks like capability assignment might be affected for another reason.
Given you’re rebuilding roles from a central JSON and periodically running /wp-admin/users.php?force_roles=true to realign them, it’s possible the process is overwriting capabilities set by Wordfence’s cron, or they’re not sticking afterwards.
Two quick tests that might confirm it are:
- Temporarily stop running the
force_roles=true manually or on a schedule (if set anywhere), then save/toggle the 2FA settings for Editor and see if “Not allowed” clears after the next Wordfence role sync goes ahead.
- Check the Editor role’s capabilities before and after
force_roles=true on the same subsite. Do any capabilities they had before disappear or get added to?
Let us know if that doesn’t give too much useful information and I will see if our QA team are able to replicate the situation with User Role Editor on a multisite that may offer explanation on how to solve it or whether there’s a conflict happening.
Thanks again,
Peter.
Hi Peter,
Thanks for getting back to me. I’ve been doing some further digging and was able to get 2FA allowed on all expected roles by toggling the ‘2FA management shortcode‘ option in the Wordfence settings. Though this seems to have done something positive (I saw the 2FA status as ‘inactive’ on core WP roles rather than ‘not allowed’), after running a force_roles=true again, it’s returned to the broken state. I was unable to replicate the temporary ‘fix’ on our staging site and toggling that setting has not worked again.
When temporarily fixed, I could see the capability wf2fa_activate_2fa_self applied to core WP roles (which wasn’t there before). Manually adding this cap via User Role Editor doesn’t restore the 2FA status for a user, however. I’m working on getting this capability deployed to all of our roles via our roles.json file and will let you know if that results in anything useful.
To answer the questions you raised in your last response:
- force_roles=true is only ever run manually (it’s not scheduled or run by cron etc.). I updated the 2FA requirement for the editor role and left it overnight – there was no change to the ‘not allowed’ status.
- Yes, I do see some changes after I run force_roles=true: wf2fa_activate_2fa_self disappears, though some caps added via URE rather than our roles.json file remain unchanged
Any additional help you can provide would be greatly appreciated!
Thanks, Chelsey
