Lessons Learned The Hard Way: 5 Must-Dos Before The MFA Deployment [Part II]

You’ve heard the world got a bit more dangerous for IT people, and bad guys are making progress. You know it’s time to do something, and that passwords are not enough. And your boss has just asked you – “have you heard about this MFA thing”? They talk about it on social media and in the articles in CIO Mag! Let’s face MFA deployment in a few critical steps.

Yes. It’s time to act, and you’re the person who makes the decision. If you want to deploy MFA for your users – in the end, it should be simple. It is nothing more than a service adding the magic part to the login process.

So here’s the thing. As a CTO at Predica, I had undergone a similar thinking process, and I took some actions on it. We have some valuable resources and licenses. Our people are always traveling and working remotely, so we need to protect them. Here’s what our protection plan is all about:

• We’ve deployed multi-factor authentication for our users to protect our Office 365 and other resources
• We’ve done it with Azure Privilege Identity Management to manage administrators’ privileges
• The same with Azure Identity Protection to protect our users on the go.

Sounds good? And simple? Hooray!

“WTF is this thing”?

Let’s start with the easiest step – enabling multi-factor authentication for our users.

BTW – this is the way we do the job. One day our CEO said: If we want to deploy it for our clients, we need to use it on our own. We have to know the pains. Ever since, this is how we roll – we use all the tools we are deploying for our customers.

And you know what? That wasn’t entirely successful. Let’s face it – some of our users thought it was a disaster. I mean, technically everything worked, but our users were still not happy.

First news I saw on our Yammer this day was a bit of “WTF is this thing which causes me to log on to Outlook and why can’t I do this! Can someone switch it off?”

Where did I go wrong with MFA deployment? What could we do better?

Over time, when helping our customers to execute security projects based on Microsoft technology for MFA deployments, I have observed a few similar problems which we could mitigate since we’ve had our first-hand experience.

Here are our lessons learned from MFA deployments we did, gathered from our environment and several customer engagements.

Note: I will not guide you here through the exact Azure MFA setup process and technical details – that will be subject of one of the upcoming posts – so stay tuned.

#1 Plan your pilot deployment and pull the feedback from pilot group

Step #1 is to plan your pilot. And execute it. Select your pilot group and put them first as trial users. The size of the group and scope have to be selected based on your organization structure.

In our case, we have first rolled out the MFA to the entire team working internally on identity and access (feel the customer pain). After checking it out, we have extended our reach to a pilot group of test users. We had nearly 25% of the company there.

Well, let’s see… You now have your pilot group. You have enrolled them in the service. No complaints from users. No negative feedback. The world is yours!

BUT… this is the moment when you should be proactive. You can’t rely only on feedback reported from your users. You need to actively engage with them and gain their feedback on the service and behaviors.

Additional login every day – no problem, I will handle it. Damn IT; they did it again, but well – we will survive.

No feedback during the pilot is a bad thing. Change it. Pull it from your users. Make a poll or organize a feedback session. Reach out to original users.

Tools for that don’t need to be sophisticated.

#2 Plan your communication. Make it clear and easy to wrap up

It is where most of IT projects fail or at least get into trouble. This applies not only to MFA projects but also to any other that introduce a change to the end user.

Here are some key rules you should follow:

• Make the user informed. They may want the change, and they will accept it. But they just don’t like to be surprised.
• Make sure you provide a rationale for the change. People like to know they are part of the action with some reason behind it.
• Be very specific in providing instructions and references. It can’t be hidden between the lines. It has to be clearly marked and easy to access.
• If you require users’ actions – call for it. Include an explicit call to action in your communication. Don’t assume they’ll just know what to do. Tell them instead.
• Repeat your message, BUT do not trash their inbox with dozens of messages. Good timing required – send early communication about the change, then repeat it. Just before the deployment be specific about what will happen and when. Add the critical message – how they should seek help in case of a problem.
• Make it fun and engaging. Mind the language and wording. Keep it simple, avoid jargon and IT lingo. Put it in plain language.

Your users will love you for that – I’m telling you. They are not used to be treated like this. Usually, they are people IN THE CHANGE, not being a SUBJECT OF THE CHANGE. Change it then!

Communication itself might not be enough. Some people will skip it. If you want to minimize the risk it will happen, just do some training sessions. Make it in-person or on-line. Propose a few time slots where your users can participate to learn what will happen and when. You might be surprised, but they will take part. Users want to be part of changes. Give them the chance.

#3 Applications – that’s where the shoe pinches. Test them!

It is not about standard services like Office 365 which handles it well. It is about a variety of applications people use every day.

Even with Office 365 – it is not a problem when you are using it on-line. The problem begins when people use it with Office clients (most often the older versions). Identify them all, upgrade or patch if needed before switching on MFA.

It’s way easier when you are up to the MFA deployment for remote access options like VPN. Usually, there are no apps that depend on this. And the authentication process happens in the backend. One way or another – make sure that all your users are on the client version you have tested and verified.

In case your application logging on to Office 365 does not support multi-factor authentication, you will have to revert to the application password. What is it?

One tip here – get your users’ set of applications and go through the process of configuration with MFA as a standard user. Some applications will have strange UI options or experience when you enable that (yes, Skype for Business and Outlook desktop client – I’m talking about you here!).

We’ve been through much of the pain, and I hope you are doing well… But still, there are two more to go to seamlessly go ahead with the MFA deployment in your company. So stay tuned for the second round in the next post, where I’ll be talking about passwords mystery and going live. Meanwhile, if you have any questions to ask – now’s the perfect time and place to do so!