Question about 2FA

[Velvis]

I do alot of after hours support for my clients for small stuff. It is convenient for them to not interrupt their work flow and works for me when I can bang something out anytime after 5 rather than deal with setting up a specific time and coordinating schedules.

Anyways I got an email from a user who needed to be added to a M365 group and have access to the files in File Explorer. She isn't a very computer savvy user, so I wanted to just put a short cut on her desktop.

When I went to log her into portal.office.com to open SharePoint to get the link it required 2FA.

In general is there a way for an admin to be able to by pass a users 2FA for doing remote work when the end user isn't around?

 

[HCHTech]

TAP (temporary access pass) if you have admin access to the tenant.

 

[YeOldeStonecat]

I put a TOTP code for each user at each of our clients in our password documention system.....HUDU.
As well as their password of course.

So we can always log in and do stuff for our clients. We do this while setting up the user for the first time...but of course it can be added later.

For a quick way to pop into an account where you don't have TOTP set up, go to Azure(Entra/ID) admin portal, users, the user, authentication methods...and switch their cell phone number to yours or a special MFA phone you keep at the office....log in...get the SMS...continue to log in...now add TOTP....once done, edit the auth phone for the user back to theirs.

We keep a phone at our office just for MFA's to roll in..and it sends them to Teams....so any tech who is "out of office," can still get the SMS codes 24x7.

 

[HCHTech]

I put a TOTP code for each user at each of our clients in our password documention system.....HUDU.
As well as their password of course.

When you use this, does the MFA prompt go to BOTH you and the original user?

..log in...get the SMS...continue to log in...now add TOTP....once done, edit the auth phone for the user back to theirs.

Just from a workflow perspective, where do you "keep" the user's cell phone #, so it is available to you when you want to make it the target again?

We keep a phone at our office just for MFA's to roll in..and it sends them to Teams....so any tech who is "out of office," can still get the SMS codes 24x7.

This might be the most on-point use for teams that I've heard. Very clever and useful way to solve this problem. I suspect you could use a google voice number to do this as well, eliminating the need for an actual phone. I'm not 100% sure about the lesser security of SMS 2FA, though, compared to push number prompts...

 

[britechguy]

I'm not 100% sure about the lesser security of SMS 2FA, though, compared to push number prompts...

Again, this is for one-off, very intermittent purposes. The probability of any issue of any kind for any single SMS 2FA is exceedingly low when the account is for some "average office worker."

No one's running around cloning mobile phones at random "hoping to catch something good." That kind of activity is a form of very targeted attack.

I certainly wouldn't make it "first choice" method on a day to day basis, but for a rare one-off need, sure, even if I were to configure it for that use and then unconfigure it immediately afterward (which is what was proposed - although it sounds like SMS 2FA is being used otherwise, too).

 

[YeOldeStonecat]

When you use this, does the MFA prompt go to BOTH you and the original user?

Depends on what is set for default....most of the time....yes it will ping the end user. Usually they know I'm working on their computer, what I do is tell them I'm working on their rig, that they can ignore the MS Auth nudges for the next...30 minutes..or hour....<or whatever I think I'll be taking>

Just from a workflow perspective, where do you "keep" the user's cell phone #, so it is available to you when you want to make it the target again?

I copy and paste into notepad....from it's listing in "authentication methods" from the Entra admin portal. When done, I paste it back.

This might be the most on-point use for teams that I've heard. Very clever and useful way to solve this problem. I suspect you could use a google voice number to do this as well, eliminating the need for an actual phone. I'm not 100% sure about the lesser security of SMS 2FA, though, compared to push number prompts...

I look at the logistics...the reality...of the security of MFA via SMS. I'm not being phished...I'm going in when I want to. Bad guys listening in unsecured unencrypted SMS channels for the codes...how will they know who I'm going into? I'm going into who I need to..when I need to, I'm not falling for phishing where they know whos account and when to listen. I'm going into random user account...not mine, and not...someones ...at the bad guys beck and call. But more often we're going in via TOTP. Also as yet a 3rd option, we can use one of our inner "distribution email groups"..to add as an email to send a code to...that all of us at our office get.

 

[Sky-Knight]

Please just use a TAP. Subverting MFA by controlling the authenticators is going to get you sued. You're utterly destroying the non-repudiation component of authentication. And for what? Saving you the 10 seconds it takes to punch into the tenant and add the TAP?

 

[YeOldeStonecat]

TAP is the same end game, just a longer route. It also bypassed the "non-repudiation component"...so...at the end of the day, same goal, just...more steps for us. I run on 4 sometimes 5 monitors...not many people multi task and run the mouse as fast as I do, going through the offramp of doing the TAP approach is longer than 10 seconds.

Our clients know we go into our systems, we have a very whiteglove service thus relationship with our clients. Our due diligence of storing the additional TOTP in our HUDU system is good...99% of our logins are from that.

 

[nlinecomputers]

TAP doesn’t require knowing the end users M365 password. Adding a new TOTP phone is going to require you to know the end users password. TAP is more secure and just as easy to setup as any rouge phone.

 

[YeOldeStonecat]

Which is fine, whatever works for each IT companies workflow. We're very.."white glove"... I make my clients passwords from the get go, and they get them via HUDU. (secure transmission of staff passwords...the boss at each client we work with has access to their tenant in our HUDU). We set up computers from the beginning before they leave our office. Be they...joined to a local on prem domain, or AzureAD. We set up the users profile, Much of our work is done in early hours or late hours, when client employees are not there. Our clients know this, and prefer this. Every place has different workflows...use what works for you.

 

[Sky-Knight]

Which means you know all the logins for all things, and your customer has ZERO LEGAL ABILITY determine if any action their employees take was actually the employee in question because all the employee has to do is say that your team did it. And you can't prove you didn't, because you own the logins.

That is bad, really REALLY bad. It's just a situation that hasn't gotten you sued yet, and you've been lucky so far... lucky is good too.

Just do me a favor and make sure your council knows this and your agreements are updated to reflect it. I understand why you're doing it, and it does make sense. But legally, there's risk there that needs managed. Perhaps it's already managed? I certainly do not know, but anyone that attempts to use that workflow needs to be aware of that reality.

 

[YeOldeStonecat]

Clients rogue employee can try to redirect blame all they want, our RMM (and most RMMs) have logs.
A risk? Yup. But we do our due diligence in protecting it. Heck I've seen some MSPs talk about keeping client creds on spreadsheets. Ours is pretty darned locked up in HUDU.

Now, when it comes to their LOB software, and especially their accounting software, I will never...know those creds, don't want to, refuse to know them. Or healthcare software. I don't ever want to get inside clients primary software outside of 365.