That’s it. No commitments. With less than 1.5 hours of your time, you will limit the risk for your project.
We like to deliver! After a call, you will get a summary report with all the information we covered.
Do not wait.
Register for your free scoping call right now.
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:
Sounds good? And simple? Hooray!
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?”
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.
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.
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:
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.
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!
Videoconferences and Teams chats are now an irreplaceable part of the working life for many of us. But Microsoft Teams a...
Ready to learn more about us?