Using a Virtual Mobile Phone for Shared Multi-Factor Authentication

As an IT support organisation, we pride ourselves on staying up to date as much as possible with current trends and changing technologies, particularly in the Microsoft space. As such we keep a keen eye on technical blogs, whitepapers, LinkedIn articles, Twitter, Microsoft Office 365 notifications and of course we are part of the Microsoft Yammer community.

Was wondering if someone might be able to assist or even shed any light on what I would like to achieve.

We are a Microsoft Partner who manage multiple O365 Tenants for multiple clients. We would like to implement MFA on the Admin accounts but would like to have a central location where the MFA codes can be sent.

We could setup a Smart Phone with the Microsoft MFA App and add each client to this, but the issue we have here is the user would need to be in the same office as this device in order to get the code, which is not practical.

When MFA first came out you could have the MFA code sent to an email address, I see now that this feature has been removed.

Is there anyway to still have the MFA code go to email, through powershell perhaps?

One of the responses was this:

We have chosen to deal with this via a combo or Twilio, Logic Apps and Teams.

We pick up a mobile number from Twilio ($1 a month) per customer, use webhooks to call a Logic App in Azure, and then have the Logic app drop the code into a specific channel in Teams.

Not very complicated but provides reasonable protection (for now).

Now, the way that comment was written it seemed so easy right, so I thought we thought we’d have a look at what was involved. At the same time we had heard of Twilio but never needed to use it in anger. Plus, whilst I have been an end-user of text alerting it would be interesting to peek behind the curtain and see how that is all put together. Maybe one day soon we may have need for sending SMS alerts ourselves as part of updates, marketing, chatbots and so on.

Back to the task at hand.

When it comes to Global Admin privileges we very much advocate and adhere the following:

Reseller relationship with our own individual admin accounts with MFA

Individual admin accounts with MFA

Shared admin account with MFA

We strongly urged the clients to have Cloud Only secondary administration accounts themselves. Best practice should be to always use a secondary administration account – even for On-Premises work. You should certainly NEVER use your own day to day account when administering servers and services. If your own machine, and by extension your own account was to become compromised then the hacker would gain administrative privileges and could very quickly cause carnage and mayhem within your organisation. Administrative accounts should be locked down for the purposes for only what they are intended. For example, we use dedicated Domain Admin accounts that can ONLY log on to Domain Controllers and nothing else.

Now, with Office 365 we likewise only have a dedicated Global Admin account that is unlicensed and only for the purpose of administering Office 365 and Azure. We also have non-Microsoft Accounts that also require MFA like Amazon, Apple, Google etc.

These accounts have a long complex password and that password in ONLY stored securely in LastPass) and additionally further secured by Multi-Factor Authentication.

We, like many other CSPs, support multiple clients therefore we have access across multiple tenants and for the reasons listed in Yammer not all administrative functions are available via Partner Centre:

Security & Compliance appears not accessible using the partner portal tenant entry. With increasingly more administrative tasks like mail flow insights and ATP moving to the Security & Compliance centre, a lack of access via the partner centre is quite frustrating

Quite often clients are deploying E5 licenses to make use of advanced security features, like conditional access, EMS, ATA etc. E5 licences are quite expensive. Additionally, having a Mailbox, Teams or SharePoint access attached to a Global Administration account may also be a requirement.

So having unlicensed administration accounts is not an option for them, but to the provide secondary licensedadministration accounts to Global Admins is an unpalatable cost. Thus, a shared Admin account whilst certainly not desirable, is the trade-off between cost and supportability.

So, how can you make a shared administration account work for multiple users, but only one endpoint for MFA codes?

How to:

Go to their sign-up page here: https://www.twilio.com/try-twilio and fill out the usual details. You can opt for a trial, but we knew we were moving ahead with this, so we went right ahead and purchased the product. At $1 a month and 0.0075 cents a text we knew it would be a worthy investment. Go ahead and Sign up and verify your identity.

After this you will be promoted to give your first project a name – this is just a label, so choose something meaningful.

Now that you are set-up, you will arrive at your Home Page, the Console. This is where you can upgrade, look to the top right-hand corner and select upgrade.

Getting Started

Choose the red button option – “Start Sending Messages” this creates a Messaging Service. Give it a friendly name and choose standard.

Buy a number

Now you need to buy a number

Programmable SMS configure Inbound Settings

You will now be returned to the SMS console for Messaging Service – Programmable SMS.

Start

Back to Azure, time to add a New step to our Logic App. This is where the Twilio integration happens. Select New Step and Add Action

Search for Twilio and then select Twilio – Get Message

Complete the following three fields: Connection Name, Twilio Name and Twilio Access Token. The Name you choose, the Name and Token you get from your Twilio profile

The Name is your ACCOUNT SID and your Access Token is your Auth Token. You get these by clicking on the Twilio logo in the top left-hand corner, then go to Settings. You will need to authenticate again to make changes.

In General Settings find the API Credentials

Add the relevant details and click create.

Add the JSON code

Now comes the tricky part 😊 JSON code. I have not included how we figured out the correct JSON code to use ’cause that’s where the clever part was, but suffice to say what you need is below.

You need to go back to the HTTP step and edit. Paste this into the “Request Body JSON Schema”

For the Message SID field, this is a dynamic value for every text message, so this needs to be pulled out the HTTP response, per the code above. But it is buried, so you need to use a function to get it out.

Conrad Murray has been working in IT for over 15 years specializing in the Messaging Arena and in particular IBM Domino and Microsoft Exchange and now of course Office 365. Working with like minded colleagues now specializing in very large scale complex migrations from Lotus Notes and On-Premise Microsoft Exchange to Office 365.

Nero Blanco IT Limited is a company initially formed by highly skilled and experienced independent contractors who saw a problem with how large technology migration and consolidation programs were undertaken.