Be in mind the following procedure in case you may need to do it.
A couple of days ago a customer decided to create a new Azure subscription and move the MFA service provider from one Azure subscription to the new one.
After hearing this request, the first thing that came to my mind was scary.
But after a few minutes of calm this is what I did.
1- I create a new MFA Provider in a new Azure subscription
2- In each one of MFA server, I delete all files in the following path “C:\Program Files\Multi-Factor Authentication Server\Data” except database named Phonefactor.pfdata
3- Note when you delete those files you will lose the MFA provider and subscription association, thus Activation credentials will be required next time you open MFA Manager Console.
4- Generate new Activation credentials from the new subscription.
5- Activate the license using the new Activation credentials.
6- Activation process will recreate the previous deleted files and will associate the MFA servers with the new Azure Subscription
7- Once the service has been activated you can delete the old MFA provider.
Note that users who are enrolled for phone call or text authentication will not be impacted by this change, but the mobile app push notifications may will stop working for some users that are using the app. If this happened users will need to reactivate the mobile app after the change to start using it again.
Under my scenario, using SMS (one-way) and OATH token , the experience was great and no re-enroll process was required.
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 https://phonefactor.net 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 https://pfweb.phonefactor.net/
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.