Marco

Hello, I was planning on testing the Force Login plugin before replying, but if it allows for exceptions to be created, then adding exceptions for both the Start and Callback URLs may make login work.

Hello,

I did not close the original topic and I cannot find a way to reopen it. It was probably closed automatically after some inactivity.

I did attempt to implement a solution for this issue by adding the “Use POST callbacks” and “Require POST to Start URL” options. Enabling both of these may solve the issue.

Hello,

this plugin adds the ability to sign in to WordPress with an Azure AD login. Adding functionality to lock the entire website behind the AAD login is out of scope for this plugin.

After a search I was able to find some plugins that require the user to log in before being able to access the site (I won’t name any here because I haven’t tried them and therefore cannot vouch for them).

If the plugin redirects the user to the regular wp-login.php page the “Login with Azure AD” button will appear, allowing login with AAD. This plugin matches AAD users to WordPress users and logs them in with the latter, therefore any plugin that expects a visitor to be signed into WordPress will see the user as “signed in” if they have logged in with AAD through this plugin.

Hello, I installed the plugin on a new WordPress installation running on PHP 7.0 and did not notice issues with this plugin. If something does not work, could you please provide me with a precise error message?

This plugin does not generate any alerts or other notifications about PHP versions. Newer versions of WordPress will show alerts if running on PHP < 7.4, but that has nothing to do with this plugin.

I was referring to the regular WordPress login cookies.

This plugin does not use cookies itself, instead it uses WordPress’ nonce feature, which relies on an IP address for logged out users and a login cookie for logged in users.

If a user is already logged in when they start the SSO process (i.e. visiting the /sso_for_azure_ad/start/ or ?sso_for_azure_ad=start URLs shown in the plugin settings) then there may be issues if WordPress cookeis are set to SameSite=Strict, since the user would be issued a nonce tied to their login cookie, but their browser would not present that cookie to WordPress when getting redirected from the Microsoft login page back to the plugin callback page, which would then cause nonce validation to fail.

I’m sorry, unfortunately I can’t reproduce the problem. Out of your plugin list, only Allow Multiple Accounts and NinjaFirewall stand out to me as potentially being able to cause issues, although I do not know how that could happen.

The state parameter looks correct, however I am having trouble reproducing the issue.

The login process relies on WordPress nonces, which get invalidated after logging in or when changing IP address.
Therefore, I see three possible ways to cause this issue:

• The user’s IP address changes between when the plugin redirects them to Microsoft for login and when they return; or
• The user is already logged in and uses the “Homepage / Login URL” in the plugin settings to access the site (for example, form the Office.com homepage) and login cookies are set to SameSite=Strict, which means they won’t be presented by the browser to the website when returning from Microsoft.
• The user logs in in another tab or window during the portion of the login process that takes place on Microsoft’s website.

I realize these scenarios are very unlikely. I was unable to come up with other options to trigger this error.

A list of other plugins in use may be helpful to attempt to replicate the error.

Hello,

this error message appears when the “state” parameter in the callback URL is incorrect.

The parameter value is generated by the plugin and should be relayed as-is by Microsoft after login is complete, so it is either not being generated properly or it is getting mangled in transit somehow.

For troubleshooting, could you send the portion of the callback URL (the URL of the page where the error appears) between “state=” and the next “&” symbol?

• This reply was modified 1 year, 10 months ago by Marco.

If the URLs I previously mentioned are correctly being rewritten to be handled by WordPress I honestly do not have any ideas on why it does not work.

I might test my plugin again in the next few days on the latest WordPress to ensure that it did not break in a way that I missed.

Sorry, your comment made me realize that my examples were incorrect since I used - instead of _.

Please try https://<your site>/?sso_for_azure_ad=start and https://<your site>/sso_for_azure_ad/start. I have my doubts that this will make any difference though.

The correct callback URL should be https://<your site>/sso_for_azure_ad/callback?code=...&state=...

Do rewrites work on your host?

If https://<your site>/?sso-for-azure-ad=start redirects to the MS sign in page and https://<your site>/sso-for-azure-ad/start does not you probably do not have rewrites working.

The plugin does not support environments without rewrites when support for MSA is needed, as Microsoft requires callback URLs without query parameters when MSA users can sign into an app (not required when only AAD account support is needed).

Those query parameters look correct. They should be at the end of the URL for the “callback” page (/sso-for-azure-ad/callback or ?sso-for-azure-ad=callback). From that page you should end up getting redirected to the page you were trying to access before logging in.

Do you see an error message?

Have you set the Tenant ID option in the plugin settings? Try changing it to the literal common, if it is set to an actual ID it may override the app configuration in Azure AD (which I assume is set to allow all accounts, including personal/consumer MSA).