Azure Mfa: Twice Mfa For Mac
Terminal Services Gateway is an SSL based service for accessing internal RDP servers behind a Firewall/Azure VNet. It uses a public certificate and IIS to tunnel RDP requests through a single front end server to one or more back end RDP servers.
This avoids the requirement to publish port 3389 to the web or use redirected port rules to access the RDP port directly and provides 128Bit encryption for traffic. Azure provides a built in Multifactor Authentication (MFA) service which can be used in conjunction with multiple Microsoft and 3rd Party Vendor services. MFA provides a secondary authentication challenge to users connecting to a service. This can take the form of a Text Message and PIN, a phone call, mobile app and several other options. Users initiate the connection to the required service using their username and password and Azure then requests secondary proof that user is genuine.
For example, a phone call is made to the users registered number and a key press is required to complete the authentication process. Once this is complete the user is passed through to the requested service as normal. In order for successful configuration of the services you should start with a working TSGateway set-up. This ensures you are not misdiagnosing issues with the MFA which might be the result of the TSGateway not working. This document does not cover steps to configure a TSGateway. An active Azure subscription is required to create the MFA service. Administrator rights to the Azure tenant is required to create the MFA service.
Administrator rights to the servers to be configured for use with the service. NOTE: The MFA software should be installed on a machine separate to the TSGateway server. This is due to the RADIUS ports being used overlapping. It may be possible to configure alternate ports for this communication but is outside of the scope of this document and not something tested by the author. KB 2919355 must be installed on the MFA target server. Log into your Azure Tenant using the Azure Classic portal.
![Azure mfa server Azure mfa server](https://docplayer.net/docs-images/41/6121456/images/page_3.jpg)
Navigate to the Active Directory node and choose the Multi-Factor Auth Providers tab. Click the NEW button in the bottom left to create a new MFA Provider. Choose the MULTI-FACTOR AUTH PROVIDER option and then click QUICK CREATE. Fill in the details as shown below. Name is purely a descriptive title for easy identification. Leave all settings as default. Choose the Subscription from the drop down.
Once these details are populated click CREATE in the bottom right. Creation is very rapid and the service ready to go in seconds. Once you see the service listed click on it to begin initial configuration. Click the MANAGE button at the bottom of the page.
![Mac Mac](https://kb.parallels.com/Attachments/kcs-169203/radius.png)
On the management page you need to generate Activation Credentials to connect with. Click the Generate Activation Credentials button. After a few seconds you will be provided with an email address and password similar to the following: b4522efa5676ab9061ed522849b5deb5555aeb02. Copy and paste these into somewhere to store them for now. This page will time out if not used for a period of time and the details removed. If this happens generate them again. Click the download link (easily missed above the Generate Activation Credentials button).
This will download the MFA server software. Run this from the server to be installed or locally and transfer it to the server. Run the MultiFactorAuthenticationServerSetup.exe on the server.
As above this prompts that KB2919355 be installed if not already before continuing. If you have this already click OK to continue. This requires two additional support apps to be installed which it prompts for. Once these are done the main installer launches (be patient this can take a while to appear). Leave all defaults and click through to completion. Once complete find the shortcut (depends on server OS) and launch the MFA application. When prompted tick the box to Skip using Authentication Configuration Wizard as shown below.
Click through to finish. The MFA console will now launch. Paste the credentials you generated above into the fields as shown below. Click Activate. The server is registered with the Azure MFA service.
When prompted leave the details as default and click OK. You are prompted to configure server replication. This enables the service settings to be shared amongst multiple registered servers which have the MFA software installed. It is outside of the scope of this document to cover this option.
Choose NO to continue. Once complete you will see the console repopulate with additional options on the left.
Under status you will see the server name listed of the newly registered server. Click the RADIUS Authentication icon on the left. Tick the box to Enable RADIUS Authentication On the Clients tab click the Add button to configure your gateway client. In the IP Address type the internal IP of your TSGateway server. Application name can be anything descriptive to identify this object.
![Azure mfa twice mfa for macs Azure mfa twice mfa for macs](https://docs.microsoft.com/en-us/azure/active-directory/authentication/media/howto-mfaserver-deploy/import2.png)
The shared key used here is the one to be used for all NPS and MFA communications. Keep a record of this for later use. Tick the box to Require Multi-Factor Authentication user match. Click OK to complete this. Click the Target tab.
Enter the same details you used in the above Client details. This may seem counter intuitive but this is correct. The MFA service is a form of Proxy authentication. The Gateway server will take the request, pass it to the MFA service which triggers secondary authentication and then BACK to the gateway NPS service to complete the handshake and grant access. Click OK to complete this.
The final step for this is to import/create a user(s) account(s) to the MFA service. Users can be imported from Active Directory or created as standalone objects in the Azure MFA service. For the purpose of this document the user object will be imports from Active Directory. Click the Users icon on the left. Click the Import from Active Directory button at the bottom of the console.
Click the search tab and type the partial name of a user to add. Click find now to get the nearest matches. Search results are displayed on the right. The tabs below this section have options to specify defaults for the imported users. These can be used to set things like the default contact method (TXT, Phone Call etc.). Choose the user(s) to add and click the Import button. Open a user from the list.
You will see the details similar to the below. If populated in Active Directory the phone number and certain details will be filled in here. Complete any missing details including the phone number to be contacted on and ensure the correct country code. The number does not need the initial 0 in front of it. Set the options for authentication whether it be a TXT or phone call. This document does not provide details on all options for this.
Click Apply to complete then close the user details. At this point the MFA configuration is complete. Open the RD Gateway Manager.
As stated previously this should be a working server config and tested for connectivity. Based on the normal configuration there should be a CAP and RAP policy configured. The only change here is to the CAP policy section. Currently the local NPS is authenticating connection requests using the CAP policy.
In the RDG manager right click the server name and choose properties. Click the RD CAP Store tab. As you will see the current selection is Local server running NPS. Change this radio button to the Central server running NPS option. In the server IP field enter the IP of the server where you installed the MFA application.
Enter the shared key you stored from earlier which you entered for the MFA Client and Target objects. Click OK to save and close. Now when you click on the Central Network Policy Servers entry you should see the MFA server IP listed instead of the CAP from before. The RD Gateway is now ready to send authentication requests to the MFA server. NPS is installed as part of the TSGateway feature. This part of the setup will configure the NPS to use the MFA service as an authentication method. As above the RD Gateway is no looking at the MFA server for authentication.
The following will configure the local NPS to pass these requests to and from the local machine and the MFA. Open the NPS console. Right click the RADIUS Clients entry. In the friendly name field enter MFA (you can use a different name but make sure the policy matches that name later). Enter the IP Address of the MFA server.
Enter the same shared key used so far. Click OK to complete. Click the Remote RADIUS Server entry. A group called TS GATEWAY SERVER GROUP will already exist. This is created by the RD Gateway setup. By default, it is empty.
Open this group. If not already listed, click the Add button and enter the MFA server IP and same shared key on the Authentication/Accounting tab. Whether you create it or it already exists, choose the Load Balancing tab. By default, the timeouts used by NPS are too short for the authentication requests to reach and return from the MFA service.
The changes made here extend these timeouts to allow the handshake to complete. Change the times to 60 for the second and fourth right hand entries. Your settings should match the below. Click OK to complete this. Click OK again to exit the group settings. Click the Connection Requests Policies entry.
Here you will see a policy called TS GATEWAY AUTHORIZATION POLICY. Again this was created by the RD Gateway config. Right click this policy and choose Duplicate Policy. This will create a copy of the policy. (for rollback you might create a second copy to fall back to if anything goes awry).
Take note these copies are disabled and must be enabled to work. What is being created here is a policy TO the MFA and a policy FROM the MFA.
To easily identify these rename and order them as follows: From MFA To MFA To move a policy up or down right click one and choose the move up or down option. To be 100% clear - From MFA must be top. Open the properties for the From MFA policy. Click the Conditions tab. Scroll down to find the Client Friendly Name entry. Double click this and enter MFA (if you used a different name above enter that name here). Click OK to complete.
Click the Settings tab. Choose Authentication on the left. This will currently be set to Forward all requests to the TS GATEWAY SERVER GROUP. Change this setting to Authenticate Requests on this server. Click OK to complete this.
What this is doing is creating a policy to allow ONLY the MFA server to send requests back to the NPS on request. The second policy is the reverse. Open the To MFA policy properties.
This policy should be in its original settings and does not require any changes. As an overview of the settings click on the Conditions tab. Here you will see only the NAS Port Type as Virtual (VPN). Click on the Settings tab. Choose Authentication on the left.
Here you see that requests are being forwarded to the MFA which is a member of the TS GATEWAY SERVER GROUP. Close these dialogues to continue. This completes the steps required to integrate the Azure MFA service into the TSGateway connection process. Test connection to the gateway via an RDP client. If the option specified in the MFA server is to text a code, you will get a text message with a code included. To complete the process, you must type the code followed by your PIN (no spaces) and send it back.
If the option was for a phone call you will get a phone call from an automated service which requires you to press the # key to complete the process. You do not have to wait for the entire message to press #. As soon as you press # it will complete and you will see the server login. If you have followed the above carefully you should gain access via this method. The only times this failed was due to the shared key being incorrect between the services. Which generates a log in Event Viewer like this: The user 'DOMAIN user', on client computer 'PUBLIC IP', did not meet connection authorization policy requirements and was therefore not authorized to access the RD Gateway server. The authentication method used was: 'NTLM' and connection protocol used: 'HTTP'.
The following error occurred: '23003'. Go through each shared key location and confirm the correct key is entered. These events are logged here: Microsoft-Windows-TerminalServices-Gateway/Operational Additionally, the server may connect without any Azure intervention. This was found to be the gateway server polices being incorrectly configured to forward authentication to the MFA or the MFA not having a return path. Check the policies and RADIUS client/groups to make sure they are as shown in the above steps.
First published on CloudBlogs on Aug, 06 2018 Howdy folks, Today, I am excited to share some really cool improvements to Multi-Factor Authentication (MFA) and self-service password reset (SSPR) that are now in public preview! We’ve heard from our customers that having two different registration experiences causes confusion and frustration. Now, users can register once and get the benefits of both MFA and SSPR—eliminating having to register their security info for these features twice. This allows administrators to create and maintain a single set of documentation for their users and greatly simplifies the helpdesk scenarios. We received a lot of positive feedback from customers who have been using the private preview of these improvements and now we're excited to share them with all of you.
Keep reading to learn more about these improvements! Register for MFA and SSPR in a single experience In the current Azure AD experience, users who are enabled for both MFA and SSPR must register their security info in separate experiences.
Azure Mfa Setup
We've heard from you that this causes confusion and frustration for users, especially if they have to register the same info, such as phone number, twice. Before: MFA registration experience. Before: SSPR registration experience. With the new combined experience users can register their security info for both MFA and SSPR in a single, combined flow. This means users get to register once and benefit from both features!
A single, updated security info registration experience. After registering, users can manage their security info from their profile or by going to. Profile page with Edit security info link to manage security info. Here users can add more security info, change or delete previously registered info, and choose their default methods for MFA. Security info management page. Users who previously registered for MFA or SSPR through the separate experiences can manage their registered info through this new experience. We have created for this experience that shows users how to register and manage their security info.
We recommend that you review this documentation and use it to prepare your users for the new experience. In particular, users who are familiar with the should follow the steps listed in our to register app passwords in the new experience. You can enable this experience for a group of users or all users in your organization today by following.
You can also let us know about your experience with this preview by filling out. Improved registration experience for the Microsoft Authenticator app Not only does this new experience give users the ability to register for two features at once, but we also made each step in the registration process more intuitive. In particular, we improved the registration experience for the Microsoft Authenticator app (or any other authenticator app). Clear instructions and illustrations walk users through each step of registering their authenticator app.
In addition, users who register from their mobile device can setup their account in the Microsoft Authenticator app with a single tap. First step in the Microsoft Authenticator app registration experience.
To learn more about registering the Microsoft Authenticator app, check out our. Reset passwords using Microsoft Authenticator Users who register the Microsoft Authenticator app (or another authenticator app) through the new experience or the current experience can use an authenticator app to prove who they are to reset their password. Mobile app options in Password reset settings.
You can quickly enable this feature from the Azure AD portal under Password reset settings—simply check the Mobile app notification and Mobile app code options. To learn more about how to enable your users to reset their password using the Microsoft Authenticator app, check out. Tell us what you think As always, we want to hear any feedback or suggestions you have. Please let us know what you think in the comments below or send us an email at. Best regards, Alex Simons (Twitter: ) Director of Program Management Microsoft Identity Division. Not working for me.
One user attempting to go to the page gets this: while my user account when attempting to go to gets stuck in some sort of page loop that goes on for quite a few loops then I get either the above error or sometimes I get the right page. The fact that I am stuck in a page loop for so long I am sure is not right even if I do land on the correct page. So something is wrong I am sure and I am not sure where to go to get help. I tried opening a ticket with Azure but that went nowhere. I hope you listen on the feedback regarding the default MFA options. When we activate a new user we don't want them to add phone number and activate MFA by text/phone, we want them to activate by Microsoft Authenticator.
At the moment there is no way to add authenticator app when you following the new user MFA setup, phone should be the secondary option and the end user should not be able to change the phone number provided from Azure AD. This is a major security concern in a lot of enterprise companies. My thoughts is about the possibility for administrators to configure the order presented to end user and to add a possibility to automatically provision and lockdown the attribute 'Authentication Phone' for end users. I agree with your suggestion to have this possibility to change authentication phone as a Self Service, but it should also be possible for to lock it down and use auto provisioning in those cases their it is needed, that's something missing today, and the current update of the user experience is forcing even more end user to get stuck in text/phone behavior instead of using Authenticator App.
So far we've found the following optimal experience: - Enable preview experience, and turn on a policy for SSPR that requires 2 methods for a reset. New users will be prompted to first register the Authenticator, and then a phone. This is optimal because a user who changes phones can use SMS on their new phone until the Authenticator is reconfigured. What I'd like to see: - An option to force the user to do certain methods (Email, Security Questions) every time during setup. For example, I'd like to let the user pick between Authenticator, Phone, etc. But have to do Security Questions all the time.