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 just asked you – “have you heard about this MFA thing”? They talk about it on the social media and in the articles in CIO Mag! Let’s face the 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 deadly simple. It is nothing more than a service adding the magic part to the login process.
So here’s the thing. As a CTO in 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. Let’s see 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? Hurray!
“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. And this is how we roll since then – we are using 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 I can’t 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 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 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 has to be selected based on your organization structure.
In our case, we have first enrolled 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 have now 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 pull 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 meaning the change to the end user.
Here are some key rules you should follow:
- Make the user informed. He may want the change, and he will accept it. But he just doesn’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 words. 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 just know what to do. Tell them instead.
- Repeat your message, BUT do not trash their inbox with dozens of messages. The good timing required – set the early communication about the change, then recall 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 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 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 a chance.
#3 Applications – that’s where the shoe pinches. Test it!
It is not about standard services like Office 365 which handles it well. It is about a variety of applications people are using 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 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 will 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 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 – that’s the perfect time and place to do so.