Get Support

If you have further questions after reading the online documenation, the troubleshoot guide or the plugin is not working according to your expectations, you can always ask for help and you can expect a reply within 24 hours (or 48 during weekends).

User not found

If you are using the basic (free) version of the plugin, you might have missed the fact that you need to manually create WordPress users that correspond to Office 365 / Azure AD users (see video at 2.58s). The professional and premium version will automatically create WordPress users for you.

Enable debugging

If you want to better understand why the plugin is not working, it may be a good idea to enable (debug) logging.

Since version 7.11 that was released on 9th April 2019 you can enable debugging comfortably from the Debug tab of the plugin’s configuration wizard.

If you’d like to see more than the latest 1.000 debug entries, you can still enable debugging in WordPress and expect all log lines being written to the default WordPress debug log. You can do this by changing the following line in the wp-config file

define( 'WP_DEBUG', false );


define( 'WP_DEBUG', true );

and by adding the following lines:

define( 'WP_DEBUG_DISPLAY', false);
define( 'WP_DEBUG_LOG', true );

You should now find the WordPress debug.log in the wp-content directory. There is a possibility that your website hoster has diverted debug / error output to a standard PHP log file. In this case you may need to ask your hoster where you can find the latest debug / error logs. Once everything is working correctly you should turn this logging of because the file quickly grows and nobody wants a server running out of diskspace.

Missing prerequisites

If the plugin silently fail, there is an ever so slight chance that the key NONCE_SALT is missing in your wp-config.php file.


When your WordPress website runs in a hosting environment with enhanced caching capabilities, changes are that your run into all kind of unexpected problems. This may especially be the case, if you configured the plugin to authenticate all requests (see Intranet Scenario). In this case the caching service offered by a caching plugin e.g. WP Rocket or by your hosting provider may intercept page requests and serve static HTML as a response (instead of WordPress processing the requested page from scratch). It is easy to see that this basically neutralizes the functionality of the plugin. Most caching plugins and WordPress specialized hosting providers, however, ensure that caching is only intercepting requests to the WordPress front-end. So if you are using the WPO365 login plugin to offer content editors a simplified and standardized way to login to the WordPress backend you should still be able to do so, but make sure that you configure the redirect url so that it points to the WordPress backend e.g. “” (and yes, the trailing slash is important as you can read below). Please be aware that you must enter the redirect url twice:

  1. On the WPO365 Options page in WordPress Admin
  2. As Reply URL for the registered app in your Azure Active Directory

Your logon might be tampered with

When you try to logon and you’re redirected to the default WordPress logon screen and see the message Your logon might be tampered with you can try a couple of things to overcome this.

Customers have reported that signing out of Office 365 and then navigating back to the WordPress site (and subsequently sign in again with Microsoft) resolved the issue.

Alternatively, try and disable any caching plugin e.g. WP Rocket serving a cached response or purge the cache (when your hoster has enabled server side caching for your website).

Last but not least, verify that the setting Don’t try bypassing (server side) cache is checked.

After activation the browser is stuck in a loop

There are multiple reasons why this happens. But in general it means that plugin does not detect the answer sent by Microsoft after a user authenticated successfully. So please go back to our installation instructions and read the section on how to configure the signon-url.

Ps, You can also be stuck in a loop when you use a self-signed certificate and without noticing you may unwantedly be redirected from a secure https connection to an none-secure http connection.

Login immediately after logout

If you got everything working but when you click logout you’re sent immediately back to Microsoft’s signin page and you have the All In One WP Security plugin installed then please try and deactivate this plugin and try again. We’re currently looking into this issue, but currently it’s not solved.

Access Denied

In general you should not see this error anymore if you use the latest version. In previous versions of the plugin it would use the App registered in Azure Active Directory to sign in the user. This required an Azure Active Directory Global Administrator to grant permission on behalf of the user. Forgetting to do so or not being able to do so because you’re not a Global Administrator would result in an access denied error. However, in the current version, the plugin requests access to Azure Active Directory instead. Now, if the Global Administrator didn’t grant permission on behalf of all users, the user himself can consent to the App reading his user information.

Access Denied (premium version)

Our premium version of the WPO365 login plugin supports Access Control based on users being a member of either an Office 365 or an Azure AD Security group. However, the Registered Apps manifest needs to modified accordingly, for this information to be sent to your WordPress website. To do so, click “Manifest” as visible in the previous screenshot. Edit the manifest as shown below.
"groupMembershipClaims": "All",

Make sure you read the configuration guide and specifically the paragraphs Groups Whitelist and Role Mappings. Further reading on the Registered App’s manifest can be found online here.

User that is created has an incorrect email address

There are rougly three types of accounts that can log on to Azure Active Directory: Work, School and Personal. Depending on what account you use the user information that the plugin receives is slightly differently structured. For example, an MSA account (= Microsoft Account that for example ends with or has a separate field for email that is missing for a work account. Currently all account types are probably supported but if you still experience this error then please contact us directly for support.


  1. We are using the free version of the plugin and have followed the video to authenticate with Azure but when we publish the applcation in Azure portal it only takes us to the wordpress login screen and doesn’t authenticate through azure active directory. Do we have to have premium for this to work right?

    • mvan

      Hi Paul. I’m not sure what you mean with “Publish the application”. Do you intend to list your application in the Azure Active Directory application gallery? What could have happened is that you maybe have mixed up the application’s home and reply URL. The reply URL (redirect URI) is used by Azure AD to redirect the user to after he/she successfully authenticated with Azure AD. The home URL is most likely your website’s landing page. And depending on the configuration of the plugin and especially the selected Authentication Scenario the plugin will require a user to be logged in for either front- and backend or only for the backend and do so by integrating with Azure AD. What happens if you click Test Authentication (on the Single Sign-on tab of the wizard) and what happens if you navigate directly to your websites home page (or WP Admin area)?

    • mvan

      That is not good! Are you using a plugin for caching? Or is your hoster offering such services? If so, you would need to disable it. The error means that an old redirect is being “replayed” from the cache with values in it that are already “used”. The plugin recognizes this and blocks this.

Leave a Reply

Your email address will not be published. Required fields are marked *