Error determining the current master Multi-Factor Authentication Server

This morning I have noticed an issue with a new Multi-Factor Authentication Server deployed yesterday.

When I try to open the MFA console I get the following error.

After spending a time trying to find the problem, I found what was going on.

1- An MFA server needs to connect to Azure MFA Cloud Service to query which server is the master of his replication group (whether itself or another server), the connection to Azure MFA Cloud Service is made over HTTPS protocol, on port 443, thus connectivity to from each MFA server is a requirement.

If an MFA Server can´t connect to the Azure MFA Cloud Service it can´t determine the master and fails with the mentioned error.

To solve the issue, ensure the following URLs are reachable from each server you have been deployed.

2- Once the Server get a response for that query, it knows if is the master or an slave. Slave servers initiate communications to the master database. If an Slave server can not comunicate to master server database when you open the Management Console it will prompt if you want to promote the slave to be the master.

When a Master Server is down or an Slave server can not comunicate to the master server database, the slave server can still perform authentications, because each slave server has a full READ copy of the data file locally to look up user’s authentication methods, phone numbers, and other settings but changes to the database needs to be made in a WRITE master database when be available.

Aditionally , If you need the communications from the slaves to the master to use a specific port, you can configure the master to use a static port. The static port needs to be set only on the master using the pfsvc_ncan_ip_tcp_port registry key, not on the slave.

You can do that by editing the registry on the master and creating a new DWORD registry key called “Pfsvc_ncan_ip_tcp_port” at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Positive Networks\PhoneFactor on 64-bit servers or HKEY_LOCAL_MACHINE\SOFTWARE\Positive Networks\PhoneFactor on 32-bit servers. Set the value of the registry key to the port (decimal) you want the MultiFactorAuth service to run on, ensuring first that the port is available.

Then, ensure all your MFA Servers are able to connect to the Azure MFA cloud service over port 443, and slaves communicate to the master over the port that the master service is running on.

3- It may be helpful to turn on verbose logging. You can enable verbose logging by editing the registry, going to HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor and creating a DWORD registry key called “pfisapi_verboseLog”. Set the value to decimal 100. Restart IIS. Clear the MultiFactorAuthIisNm.log located by default in the following path“C:\Program Files\Multi-Factor Authentication Server\Logs” and then sign-in only since a lot of data will be logged.

Note in a multi environment deployment, ensure your MFA server is member of the desired Replication Group. This point is really important because if your server is in a wrong replication group and cannot communicate with the master server for this Replication Group, you will be asking to promote the server every time you open the MFA Admin Console.

To check MFA Replication groups login with your account credentials (email address and password) that you used to activate the Multi-Factor Authentication Server to access the Management Portal on the website at

Select each MFA Servers group, select Server Status and check the members of each group. Each group should contain one Master Server and one or more Slave Servers. Only one Master server it´s allowed for each group. If this rule is not met may you experience strange server behaviors.