Choose your language

Choose your login


Entra ID Multifactor Authentication Requirements

This page applies to:

Microsoft Entra ID (formerly known as Azure AD) can now be used when Multi-Factor Authentication (MFA) is enabled for PaperCut NG/MF with some trade offs. Please refer to Overview of synchronizing user and group details with Entra ID (Azure AD) to understand the considerations when using ‘standard’ Entra ID (Azure AD) with MFA.

Microsoft has a lot of documentation on Entra ID multi-factor authentication, which is worth a read. However, the method that you’ll need to use to bypass MFA for PaperCut if you chose to do so, will depend on your subscription level or ‘edition’ of your Microsoft AD tenancy. Any security policies you have set up for your tenancy will also factor in to your decision making.

There are a couple of different ways to bypass MFA when using PaperCut for Entra ID sync.

Trusted IP addresses

You might be able to make use of Trusted IPs if your Entra ID tenancy provision allows it. For more information on which tenancy editions have access to this configuration, click the Microsoft link above.

You will want to use the PaperCut App Server IP address for your trusted IP address (not the client IP addresses). From an Entra ID point of view, it’s the PaperCut Application Server hostname/IP address that is authenticating the users, and therefore it’s the PaperCut Application Server IP address that must be trusted (or excluded from MFA policies).

Conditional access policies

If you have the ability to use conditional access rules (as detailed in the Microsoft documentation), one option is to keep MFA enabled for all user logins from all devices and platforms - and then exclude the PaperCut app from the MFA policy.

You might already have multiple policies set up with different ‘signals’ (basically rules like IP address or location or device type etc.). Examples include:

  • not applying a certain policy for someone logging in from a secure lab, versus applying a policy for everyone using web access
  • policies based on user location or application.

It’s that last example that we’re interested in - applying policies (in our case excluding an application from the MFA policy) based on Application or IP address.

This article has a walk-through example of someone enabling a specific MFA policy for an app. So, depending on what policies you have in place already, you’d want to apply logic that excludes the PaperCut App (or the PaperCut Application Server IP address) from the MFA policy.

Setting that up effectively bypasses MFA for anyone using the PaperCut app (or App Server IP address) to authenticate. This is somewhat fuzzy, since you will know what policies you have in place already - you wouldn’t want to create a brand new policy if it’s going to conflict with another policy that you’ve already set up in your environment, but there may be a current policy that you can edit instead.

Errors relating to MFA/2FA authentication

See the known issues page for more information on errors AADSTS50076 and AADSTS50079, related to using 2FA/MFA scenario with Entra ID standard sync. If you’re receiving these errors, then it means that MFA has been applied to the PaperCut Application Server / PaperCut app, so authentication will fail.