@ammarhasayen

Main menu

Category Azure

Post navigation

We will go through how modern authentication works when a user is trying to use Outlook client with modern authentication to connect to his mailbox in Exchange Online.

Outlook user is trying to connect to a service which is Exchange Online [EXO].

EXO will tell me go and get credentials [401 redirect] to Azure AD

I put my UPN, and Azure AD says “Hey you are federated, go to Aramex STS [302: go to on premise STS]

Now, I go my ADFS server, authentication, and then I will get SAML token, then I will send that SAML token to Azure AD.

Azure AD then will give me:

Refresh Token [I will cache this token in credential manager]

Access Token (Bearer) [ will use this access token to send it to Exchange Online]

Exchange Online will take my access token and let me in.

User gets Access Token and Refresh Token from Azure AD

Full connectivity in modern authentication

If we use Fiddler to see what is happening, we can see that the Authorization is Bearer, and of course if you open Outlook Connection you will see that the Authn is now Bearer* instead of Clear*.

When I need to re-authenticate?

Since EXO is authenticating me using my access token (not refresh token) and that access token is short lived (an hour), then I may need to re-authenticate as soon as my access token is expired.

Now instead of doing all the previous authentication workflow, and since I already have a valid refresh token that is not expired yet, I will use that refresh token to authenticate to Azure AD and get a new access token without the need to get back to my ADFS [STS] and authenticate there.

Outlook will contact EXO and present the expired access token.

EXO will do 401 access token invalid and ask for new access token.

Outlook will check if the machine has valid refresh token.

If found, it will pick up that refresh token, talk to Azure AD, authenticate using that refresh token, and then get a new valid access token that can be sent to EXO.

Share this:

Like this:

It is simply OAuth Based Authentication for Office clients against Office 365. It enables:

Multi-Factor authentication

Support for third party STSes

Conditional Access

Supported across platform:

iOS, OS X

Android

Windows

Modern Authentication Client Support

Office Client Updates

Modern Authentication rely heavily on how much Office clients applications are patched. The first thing to troubleshoot is to make sure that the client is fully patched with the latest Public Updates [PU].

Nowadays, Public Updates [PU] are released every month and they include all previous updates. So If we are in October, if you installed October PU it will include all previous updates

PUs include two types of updates:

Security updates: Patch Tuesday

Non-security updates: 1st Tuesday of the month.

You can go here to see information about PU for each month. Normally you care about PU of the current month as it includes everything before.

Now, we are moving from MSI version of Office clients apps to Click-to-Run (C2R) which includes not only updates every month, but also new features every month to catch on Office 365 new monthly features.

Also Click-to-Run comes with new Change Release Management approach by introducing different channels [Branches] to release those updates.

Why Modern Authentication NOW?

We have now Outlook and one way to authentication, and we have other apps like Excel, word, and others, which are using different way to authenticate.

We need a common platform for authentication, so that when you log to PowerPoint, you need also to be able to access OneDrive for example. So Single Sign On is something we want to ensure.

So now we are moving from application authentication to common authentication which is [MSO.dll] and the new one which is ADAL.dll which is used by modern authentication.

Share this:

Like this:

If you are synchronizing your on premise Active Directory with Azure Active Directory, then you know for sure that maintaining a healthy synchronization is not an easy thing to do.

I want to give you my experience in synchronizing a single domain AD to Azure AD, using ObjectGuid as anchor attribute.

The Challenge

I am using Azure AD Connect to synchronize AD objects to Azure AD. The Azure AD Connect tool is nice, and it gives you the health of the synchronization process and a nice error messages if there is a problem synchronizing one of your on premise AD objects. I used the AD connect tool for a month, and everything was fine. No errors and everything looks clean.

I then noticed that couple of users are having problem with Office 365 and i discovered that they have never synched to Azure AD in the first place. I did Get-MSOLUser on them and no results are returned. I had to go to Azure AD Connect and force Full AD Import to sort out this issue.

I become so worried about this, and I started to compare the number of AD users and Azure AD users to at least ensure matching numbers. Count AD users and Azure AD users and compare them is not enough, as there is no guarantee that the same objects represent these numbers.

I then came with an idea. I wanted to take each AD user, collect his ObjectGuid, and then compute his ImmutableID, go to Azure AD, and search for that ImmutableID, and finally linked the AD user with his Azure AD copy. We will do that for all AD users. Finally, we can identify AD users that does not have Azure copies, and Azure AD users that are not mapped to AD users.

This will guarantee that each one of your AD users are mapped to Azure AD users. Along this journey, the script will generate couple of information:

AD users not in Azure

Azure users not in AD

Azure users with Synch Errors

Filtered AD users from Synchronization

Total number of AD users

Total number of Azure users

Last AD Sync time

Conditions to use the script

This script assumes you are using ObjectGuid as anchor attribute

If you have multiple domains, forests or you are doing filters to scope AD users by OU or attribute, then you must write your script block to populate the $ADusers_Raw variable, by searching inside the script for (Raw data collection from AD) region. You can find examples there to do that. By default the script will do Get-ADuser to retrieve all users.

Script Visuals

The script provides many visuals to help you see what is going on:

The script code is divided into regions that you can expand separately for better script browsing.

Progress bars will appear during running the script to give you a feel and sense of what is going on during the run time of the script.

Summary information is displayed on the PowerShell console window with summary statistics.

Results are written at the end of the script in two locations:

The PowerShell console window.

Couple of files that are generated on the script running directory.

Notes

The script connects to Active Directory and gets a list of users (Get-ADUser) , and then connects to Azure Active Directory AAD and gets all azure users (Get-MSOLUser). A comparison then is performed by mapping each AD user with his Azure user, and identify un-synchronized AD users that do not have a mapped/synched Azure copy.

This script assumes that ObjectGUID is used as the anchor attribute to link/map AD user and Azure AAD user. If you are using any other attribute, then this script is not for your case.

The script needs to get the list of AD users that you are synchronizing to Azure AD. Microsoft Sync tool gives you the ability to filter by OU or by attribute. Another tricky part of the script is when you are synchronizing multiple domains or perhaps multiple forests. For all those different cases, it is your job to populate the variable called ($ADusers_Raw) located under (Raw data collection from AD) region in this script.
By default, the script will do Get-ADUser to populate this variable. In your case, you may need to write your own script block to collect all AD user objects that you are synching to azure.

Script Parameters

.PARAMETER ScriptFilesPath
Path to store the script output files. For example C:\ , or ‘.\’ to represent the current directory.

.PARAMETER Proxy
As the script needs to connect to Azure, an internet connectivity is required. Use this option if you have an internet proxy that prompts for credentials.

.PARAMETER CreateGlobalObject
The switch when used, the script will generate an extra csv file that contains a unified view of each user with properties from the on premise AD and Azure AD.

Download the script

Share this:

Like this:

I was working heavily on AD Sync Tool with all its versions including the AAD Connect tool. And I came across an issue that will cause you trouble soon. So in this blog post I will share my experience with you.

Case:

My environment was consisting of one AD domain with Exchange 2010 on premise and a single sign on experience. The AD domain and SMTP domain is the same (contoso.com)

I have a manager called John Smith:

UPN : JohnS@contoso.com

SMTP address : John.Smith@contoso.com

This manager came to me asking me to add a secondary SMTP address for him John@contoso.com. Since that SMTP address is available, I agreed.

Life goes on. John is a big manager and he used his nice clean new SMTP John@contoso.com in all his communications. He printed the new email address to his business cards.

So far, we have all our mailboxes are on premise and we do not have any Office 365 implementation.

The Problem

After 10 years, the corporate decided to start using Azure services and they decided to start with AD Sync next month.

Meanwhile, a new employee is hired with name John William. The IT department assigned him the following:

UPN : John@Contoso.com

SamAccountName : Contoso\John

SMTP Address : John.William@Contoso.com

Everything is fine so far and there is no single conflict.

Now when we started to Sync users to Azure AAD, John Smith user is no longer synchronizing to Azure AD and the AD sync tool is giving an error for that user.

“Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services:[ProxyAddresses smtp: JohnS@contoso.com].Correct or remove the duplicate values in your local directory.”

After opening a case with Microsoft, we reviewed our AD Sync configuration and after opening the AAD Connect sync tool, we confirmed that we are using ObjectGUID as the anchor attribute and not email address.

Microsoft confirms that when an on premise mail enabled user is synched to Azure AD, he is assigned a secondary SMTP in the form of his UPN. So in this case, when John William is being synched to Azure AD, Azure will try to stamp him with a secondary SMTP in the form of John@Contoso.com which causes a conflict with John Smith user.

So although there is no conflict on premise, Azure introduces this type of conflict and throwing sync error. Microsoft answered us : “THIS IS BY DESIGN DEAL WITH IT”

How big this problem is

Now, we contacted John Smith and asked him to give away his lovely John@Contoso.com SMTP address. What do you think his reaction is ? He is using that email address since years and he cannot give it away. Further more, if he agreed to give it away, and if Azure assigned it to John William user, then people sending emails to John@contoso.com will be sending to John William and this is by itself a security and privacy issue.

So we went to John William and ask him to change his UPN and SamAccountName. This solves the problem for a while, until a new employee come again with the name John Robert, and the IT found that Contoso\John is not used in the enterprise and so they assigned it to John Robert.

Now suddenly the Sync Tool will throw a sync error and the same loop happens over and over.

Imagine you have many users who used to have clean SMTP addresses and you have to go through them one by one and do this 🙂

Share this:

Like this:

So you are using Azure AAD Connect to sync your directory to Azure Active Directory (a.k.a AAD), and everything works just fine.

Now a security audit is happening in your corporation, and they identified many inactive or disabled users in your on premise AD that are no longer in use.

Then you went to your on premise AD and deleted all those users. If you delete more than 500 users at once from your on premise AD, then your Azure AAD Connect will refuse to sync those deletion to Azure AAD.

You may receive an email that looks like this:

Hello admin@contoso.com, At Sunday, 18 October 2015 12:11:40 GMT the Identity synchronization service detected that the number of deletions exceeded the configured deletion threshold for Contoso Corporation [Contoso.onmicrosoft.com]. A total of 800 objects were sent for deletion in this Identity synchronization run. This met or exceeded the configured deletion threshold value of 500 objects. We need you to provide confirmation that these deletions should be processed before we will proceed.

Please see Preventing Accidental Deletions for more information about the error listed in this email message. Thank you,

The Azure Active Directory Team

Why ?

When you install the Azure AD Connect, by default a feature called accidental deletes is enabled with a threshold of 500 objects. This simply means that the sync tool will not export from metaverse to azure AAD more than 500 deletes at once.

This objective of such feature is to protect you from accidental configuration changes and changes to your on-premise directory which may affect large number of users.

The default value of 500 objects is configurable by running Enable-ADSyncExportDeletionThreshold with a value that fits your organization size and requirements.

What to do?

If all the deletes are legitimate deletions, then do the following:

To temporarily disable this feature and authorize those deletions, run the PowerShell cmdlet: Disable-ADSyncExportDeletionThreshold

With the Azure Active Directory Connector still selected in AAD Connect tool, select the action Run and select Export.

To re-enable the protection run the PowerShell cmdlet: Enable-ADSyncExportDeletionThreshold

Share this:

Like this:

So you are using Azure AAD Connect to sync your directory to Azure Active Directory (a.k.a AAD), and everything works just fine.

Now a security audit is happening in your corporation, and they identified many inactive or disabled users in your on premise AD that are no longer in use.

Then you went to your on premise AD and deleted all those users. If you delete more than 500 users at once from your on premise AD, then your Azure AAD Connect will refuse to sync those deletion to Azure AAD.

You may receive an email that looks like this:

Hello admin@contoso.com, At Sunday, 18 October 2015 12:11:40 GMT the Identity synchronization service detected that the number of deletions exceeded the configured deletion threshold for Contoso Corporation [Contoso.onmicrosoft.com]. A total of 800 objects were sent for deletion in this Identity synchronization run. This met or exceeded the configured deletion threshold value of 500 objects. We need you to provide confirmation that these deletions should be processed before we will proceed.

Please see Preventing Accidental Deletions for more information about the error listed in this email message. Thank you,

The Azure Active Directory Team

Why ?

When you install the Azure AD Connect, by default a feature called accidental deletes is enabled with a threshold of 500 objects. This simply means that the sync tool will not export from metaverse to azure AAD more than 500 deletes at once.

This objective of such feature is to protect you from accidental configuration changes and changes to your on-premise directory which may affect large number of users.

The default value of 500 objects is configurable by running Enable-ADSyncExportDeletionThreshold with a value that fits your organization size and requirements.

What to do?

If all the deletes are legitimate deletions, then do the following:

To temporarily disable this feature and authorize those deletions, run the PowerShell cmdlet: Disable-ADSyncExportDeletionThreshold

With the Azure Active Directory Connector still selected in AAD Connect tool, select the action Run and select Export.

To re-enable the protection run the PowerShell cmdlet: Enable-ADSyncExportDeletionThreshold

Like this:

I was working heavily on AD Sync Tool with all its versions including the AAD Connect tool. And I came across an issue that will cause you trouble soon. So in this blog post I will share my experience with you.

Case:

My environment was consisting of one AD domain with Exchange 2010 on premise and a single sign on experience. The AD domain and SMTP domain is the same (contoso.com)

I have a manager called John Smith:

UPN : JohnS@contoso.com

SMTP address : John.Smith@contoso.com

This manager came to me asking me to add a secondary SMTP address for him John@contoso.com. Since that SMTP address is available, I agreed.

Life goes on. John is a big manager and he used his nice clean new SMTP John@contoso.com in all his communications. He printed the new email address to his business cards.

So far, we have all our mailboxes are on premise and we do not have any Office 365 implementation.

The Problem

After 10 years, the corporate decided to start using Azure services and they decided to start with AD Sync next month.

Meanwhile, a new employee is hired with name John William. The IT department assigned him the following:

UPN : John@Contoso.com

SamAccountName : Contoso\John

SMTP Address : John.William@Contoso.com

Everything is fine so far and there is no single conflict.

Now when we started to Sync users to Azure AAD, John Smith user is no longer synchronizing to Azure AD and the AD sync tool is giving an error for that user.

“Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services:[ProxyAddresses smtp: JohnS@contoso.com].Correct or remove the duplicate values in your local directory.”

After opening a case with Microsoft, we reviewed our AD Sync configuration and after opening the AAD Connect sync tool, we confirmed that we are using ObjectGUID as the anchor attribute and not email address.

Microsoft confirms that when an on premise mail enabled user is synched to Azure AD, he is assigned a secondary SMTP in the form of his UPN. So in this case, when John William is being synched to Azure AD, Azure will try to stamp him with a secondary SMTP in the form of John@Contoso.com which causes a conflict with John Smith user.

So although there is no conflict on premise, Azure introduces this type of conflict and throwing sync error. Microsoft answered us : “THIS IS BY DESIGN DEAL WITH IT”

How big this problem is

Now, we contacted John Smith and asked him to give away his lovely John@Contoso.com SMTP address. What do you think his reaction is ? He is using that email address since years and he cannot give it away. Further more, if he agreed to give it away, and if Azure assigned it to John William user, then people sending emails to John@contoso.com will be sending to John William and this is by itself a security and privacy issue.

So we went to John William and ask him to change his UPN and SamAccountName. This solves the problem for a while, until a new employee come again with the name John Robert, and the IT found that Contoso\John is not used in the enterprise and so they assigned it to John Robert.

Now suddenly the Sync Tool will throw a sync error and the same loop happens over and over.

Imagine you have many users who used to have clean SMTP addresses and you have to go through them one by one and do this 🙂

If you are synchronizing your on premise Active Directory with Azure Active Directory, then you know for sure that maintaining a healthy synchronization is not an easy thing to do.

I want to give you my experience in synchronizing a single domain AD to Azure AD, using ObjectGuid as anchor attribute.

The Challenge

I am using Azure AD Connect to synchronize AD objects to Azure AD. The Azure AD Connect tool is nice, and it gives you the health of the synchronization process and a nice error messages if there is a problem synchronizing one of your on premise AD objects. I used the AD connect tool for a month, and everything was fine. No errors and everything looks clean.

I then noticed that couple of users are having problem with Office 365 and i discovered that they have never synched to Azure AD in the first place. I did Get-MSOLUser on them and no results are returned. I had to go to Azure AD Connect and force Full AD Import to sort out this issue.

I become so worried about this, and I started to compare the number of AD users and Azure AD users to at least ensure matching numbers. Count AD users and Azure AD users and compare them is not enough, as there is no guarantee that the same objects represent these numbers.

I then came with an idea. I wanted to take each AD user, collect his ObjectGuid, and then compute his ImmutableID, go to Azure AD, and search for that ImmutableID, and finally linked the AD user with his Azure AD copy. We will do that for all AD users. Finally, we can identify AD users that does not have Azure copies, and Azure AD users that are not mapped to AD users.

This will guarantee that each one of your AD users are mapped to Azure AD users. Along this journey, the script will generate couple of information:

AD users not in Azure

Azure users not in AD

Azure users with Synch Errors

Filtered AD users from Synchronization

Total number of AD users

Total number of Azure users

Last AD Sync time

Conditions to use the script

This script assumes you are using ObjectGuid as anchor attribute

If you have multiple domains, forests or you are doing filters to scope AD users by OU or attribute, then you must write your script block to populate the $ADusers_Raw variable, by searching inside the script for (Raw data collection from AD) region. You can find examples there to do that. By default the script will do Get-ADuser to retrieve all users.

Script Visuals

The script provides many visuals to help you see what is going on:

The script code is divided into regions that you can expand separately for better script browsing.

Progress bars will appear during running the script to give you a feel and sense of what is going on during the run time of the script.

Summary information is displayed on the PowerShell console window with summary statistics.

Results are written at the end of the script in two locations:

The PowerShell console window.

Couple of files that are generated on the script running directory.

Notes

The script connects to Active Directory and gets a list of users (Get-ADUser) , and then connects to Azure Active Directory AAD and gets all azure users (Get-MSOLUser). A comparison then is performed by mapping each AD user with his Azure user, and identify un-synchronized AD users that do not have a mapped/synched Azure copy.

This script assumes that ObjectGUID is used as the anchor attribute to link/map AD user and Azure AAD user. If you are using any other attribute, then this script is not for your case.

The script needs to get the list of AD users that you are synchronizing to Azure AD. Microsoft Sync tool gives you the ability to filter by OU or by attribute. Another tricky part of the script is when you are synchronizing multiple domains or perhaps multiple forests. For all those different cases, it is your job to populate the variable called ($ADusers_Raw) located under (Raw data collection from AD) region in this script.
By default, the script will do Get-ADUser to populate this variable. In your case, you may need to write your own script block to collect all AD user objects that you are synching to azure.

Script Parameters

.PARAMETER ScriptFilesPath
Path to store the script output files. For example C:\ , or ‘.\’ to represent the current directory.

.PARAMETER Proxy
As the script needs to connect to Azure, an internet connectivity is required. Use this option if you have an internet proxy that prompts for credentials.

.PARAMETER CreateGlobalObject
The switch when used, the script will generate an extra csv file that contains a unified view of each user with properties from the on premise AD and Azure AD.

When working with Azure AD, and you deploy one of the Azure AD Synchronization tools like AD Connect, by default objectGUID is used as your ImmutableID. When objects are synced to Azure AD, objects in the cloud will have a converted value of the objectGUID in a base-64 version called ImmutableID.

Let us say that a user called John exist in your AD, his objectGUID is something like this:

The user objectGUID is converted to base-64 and stored in AD Sync tool metaverse as (sourceAnchor) , and in Azure AD as ImmutableID:

So sometime you want a tool that converts from objectGUID to ImmutableID and the other way.

So I created a simple desktop application, that you click on , and use it to easily convert between Azure ImmutableID and AD objectGUID

Azure Identity Converter Desktop App

The application is so small (500k) as you can see below:

Just double click it and the app will open:

Now you can simply enter an AD GUID and it will compute the ImmutableID (Azure ID for that GUID)

Or you can enter an Azure ImmutableID and it will compute the object GUID in your AD:

Download the APP

You can download the APP from here. For those who are afraid to run untrusted application, be rest that the tool does not install anything, it only prompts for values and no admin rights are needed:)

We have verified that the user running the Hybrid wizard is Global Administrator on the tenant, and the strange thing is that the error specified that the Set–OnPremisesOrganization command does not have a parameter called HypridDomains. If you check TechNet, you can see this is not true. So how come?

Solution

After spending could of days with Microsoft support, it seems that we have to add at least one E3 Office 365 licenses to the tenant in order for the PowerShell commands to work properly.

Like this:

I want to share with you some of the tips and tricks when deploying the Azure MFA on premise. These tips are from my own personal experience of dealing with Azure MFA services.

Tip : SMS Notification – One Way or Two Way

If you are using SMS notification option, then you would notice that a one time password is sent to your phone as an SMS, and you have to reply with another message (this mode is called Two-Way SMS Notification). My comments here are :

Extra charges, because the person doing the multi-factor authentication needs to send a message back with the OTP.

It is better if you can type the OTP to the browser itself if possible, instead of replying to the SMS.

Although replying with another SMS is completely out of band and more secure option, some may argue that it would better if the OTP could be sent via SMS and then being typed to the application itself (this is called One-Way SMS Notification)

On the MFA on premise server console, the option to choose One-Way SMS notification is grayed out. You can only choose the Two-Way !

After searching alot on the web to find a way to activate the One-Way SMS notification, I realized that this is only possible via the Azure Multi-Factor Authentication SDK. The SDK exposes the option of One-Way SMS as seen below:

This means if you have developed a logon page, you can use the SDK and use the MODE_SMS_ONE_WAY_OTP option there. But what if you want to use the One-Way SMS notification option to secure a VPN connection. You simply cannot because the VPN endpoint will most probably may not support code to be injected to its logon functionality where you can use the SDK.

Update : On Microsoft Technet Forum, asking about Two-Way SMS, and getting this answer:“MFA Server v6.2.2 and older doesn’t have one-way SMS capability. It is being added to v6.3 which is expected to release in Jan 2015. The one-way SMS will work with the ADFS Adapter, RADIUS and the User Portal. In order to work successfully with RADIUS, the system sending the ACCESS request will need to be able to handle an ACCESS CHALLENGE response so that the user can be prompted for the OTP.”

Update: The new version of MFA v6.3 supports SMS_ONE_WAY_OTP as per https://social.msdn.microsoft.com/Forums/en-US/b20d9859-b27e-4918-a370-db79fa7612cc/one-way-sms-otp-in-azure-mfa-server?forum=windowsazureactiveauthentication

Tip: How to use the OTP that is generated from the Azure MFA mobile app

The Azure Multi-Factor mobile app servers two things:

Push notification: where you receive a push notification and you can click (Verify), (Cancel), or (Cancel and report fraud).

Offline OTP (one time password) that is changed every couple of seconds.

So the question is how to use the offline OTP? I have implemented a solution where I could use the offline OTP. To do this, the user should be configured with OATH Token as shown in the below figure.

I am using Citrix NetScaler as a VPN gateway and i have configured it as RAIUS client and I pointed it to the on premise MFA server as the RADIUS server.

Now when connecting to the Citrix VPN gateway, I am prompted with the user name and password:

After that, I am prompted to enter the OTP:

I then will open the Azure MFA mobile app, and I enter the OTP that is generated for me offline and keep changing with time:

Tip: using MFA with Microsoft RRAS as a VPN solution

I used Windows 2012 R2 as my RRAS server to configure a two factor authentication for VPN client. I will be using SSTP as my protocol.

The following configuration are made to NPS:

Configuring the Connection Request Policy to point to the MFA on premise server as the RADIUS server

Configuring the Network Policy with PAP as the authentication method. Do not be afraid because we are using SSTP (HTTPS) as the VPN tunnel method, so the credentials will be sent over HTTPS.

Now on RRAS console, configure the authentication method as PAP, and configure a certificate for SSTP:

Finally, to enforce SSTP as the only tunneling protocol, go to Ports node, right click and click Properties, and configure the number of ports as shown below [for all ports except SSTP and PPTP, configure zero ports, and one port for PPTP]

Now when a Windows client tries to connect to my RRAS, it should be configured with PAP as the authentication method:

When you connect, the PAP credentials will be secured via the SSL tunnel, and then the MFA server will encrypt the credentials before sending them to the one premise MFA server as shown in my trace:

The only thing you should worry about is that the Microsoft VPN client on Windows client will time out quickly before the two factor authentication finishes, a registry hack on the client may solve this issue to extend the time out:

The installation of the the on premise MFA server consists of the following:

The installation of the MFA Server and Management console

The installation of three web services:

User Portal

SDK

Mobile App service

The user portal is an IIS site that your users can log on to, and perform many tasks like:

Change their mobile number that MFA server will use to perform the second factor authentication. You can configure the MFA server to sync mobile numbers from AD and not allow users to change their mobile numbers via this portal.

Set couple of security questions. These questions can be used by an IT Operator to verify the identity of the user, if the user calls the help desk and ask him to change the second factor method ( Mobile App notifications instead of mobile call for example)

Activate their mobiles so that they can receive notifications in case of Mobile App options.

The SDK service is used for custom integration with the MFA server and it is a requirement to install if you want to use the mobile app notification feature, as the mobile app service will connect to the SDK IIS virtual directory in order to connect to the MFA server.

The Mobile App Service is the service that mobile apps connects to, in order to submit the verification. This service should be published externally and should resolve to external DNS name.

You can install the portals in different server than the MFA server itself. For simplicity, i will choose to install the MFA server and the three portals in the same Windows 2012 R2 machine.

Installing the MFA Server

I will be using Windows 2012 R2 server for my MFA and portals. Now that you have downloaded the Azure MFA server, run the installation wizard, and click next until it is installed. No conflagration needed at this time.

Now open the MFA console and activate the product using the activation keys you obtained from the Azure management portal where you downloaded the MFA server. Make sure the server can connect to internet using http/https for the activation to work. Also make sure the server always can connect to internet using these ports as the server needs to connect to Azure for every authentication request verification.

Installing Azure MFA User Portal

The User Portal is an IIS web site to allow users to enroll in Azure MFA and maintain their accounts. Mainly, users can log on there, and choose if they want the second factor to be a phone call, SMS, or push notification on the mobile app. Also you can give users the ability to change their phone number if you want.

You can install the User Portal in a different server than the MFA server, but for simplicity, I recommend to install all portals on the MFA server itself. Here is a link that can help you with the installation steps for more complex deployments.

You should have IIS installed including asp.net and IIS 6 meta base compatibility for IIS 7 or higher. I choose to install the user portal on the same MFA server. During the installation of the user portal, a security group is created in AD, so make sure the account that is used to install the user portal can create security group in AD.

To install the user portal, open the MFA Server management console, go to the User Portal node and check the settings available.

I usually remove the OATH token method because i will not be using it, and also i remove the security questions option, as this seemed a possible way to bypass the security and making it less secure.

Now, click Install User Portal. The wizard will tell you that it will create the following:

Security group in AD, placed under the built in Users container, called PhoneFactor Admins.

User account called named PFUP_MFAServerName , where MFAServerName is the name of the MFA server.

Adds the previously created account to the previously created security group.

Note: do not check the box (Skip automatic Active….). doing that means you have to create the group and user manually.

I also set the PhoneFactor Admins security group as member of the local administrators group in the

Now open the IIS, you can see the virtual directory called (Enroll). This is where end users will connect to manage their MFA profiles. For me, i also created a certificate and enforce HTTPS for the whole web site.

Install the MFA SDK

The SDK should be secured with SSL. Installing it is straight forward. Just open the MFA management console, go to Web Service SDK, and then run the installation. I will install it on the MFA Server itself as we did with the user portal.

You may need to install Basic Authentication feature before you move on.

If you open IIS, you can see the SDK virtual directory.

Install the MFA Mobile App Web Service

You should install the MFA SDK before proceeding with the MFA Mobile App Web Service. I will install the MFA mobile app web service on the same server also.

I usually change the virtual directory to something like PA (Phone App) instead of the long default one. Now go to your AD, and reset the account the is created by the wizard during the user portal deployment ( the account that is member of the PhoneFactor admins group).

Now browse to C:\inetpub\wwwroot\PA (or appropriate directory based on the virtual directory name) and edit the web.config file. Enter the user account that you have reset, and the password between the quotes in shown in the below section. It is recommended to use a qualified username (e.g. domain\username or machine\username).