MFA for IT Managed Service
We are in the process of implementing MFA for majority of our clients for their end users. The problem we have is that we have 10+ IT Engineers that when on call may all require access to customers Office 365 tenancy via an admin account.
It is not feasible to setup the mobile authenticator app for every engineer and then add the admin account every single tenancy account to their app!
We have tried setting up a number of our client admin accounts to use a text to email service, but for some reason the text from Microsoft doesn’t come through via email every time. Yet when we text the number manually the email comes through fine. Do Microsoft have a restriction on how many 365 accounts can use the same mobile number for MFA?
Can we have a single account that covers/has delegated access over all our customers 365 tenancies?
What are other MSP's using to get around this issue?
You could consider a solution like MyKi which enables for 2FA to be stored within the password management app.
Engineers are able to then obtain the code when they are signing in each time.
I have been looking into this as having everyone as Admin Agents is no longer feasible. MS are working on Lighthouse for Azure and 365 but they both still have limitations. By removing the partner permissions, and using B2B access (and tenant specific portal URLs), we can use our own accounts (with MFA) and move away from having generic credentials to manage client tenants. The main caveat is that you cannot use the 365 admin portal with this method, so helpdesk staff use the Azure AD portal and Exchange portals separately to perform basic tasks (user / group creation, setting delegate access to a mailbox etc). More info here:
@simbur666 : Thanks for adding this info. While this works for some admin scenarios, note that opening support tickets as Partner on behalf of the customer does not work this way. Specifically, for O365 support tickets can not be opened using the Partner support contract, and for Azure it does not work at all using B2B accounts when this is a CSP Azure subscription.
Luckily testing of granular delegated admin is already piloting with a lot of Partners, it should not be that long until a better solution using Partner Center is available.
We were in the same boat in terms of lack of functionality via delegated access. We setup a authentication extension number on our phone system, and have our clients admin accounts that we manage phone that extension for MFA, which rings the engineers in my team. We know to confirm that someone is authing before approving. Not the most elegant solution but has worked up until the last week or so.
We are noticing we are getting "too many authentication requests now" so not sure if Microsoft are now monitoring number of authorizations to a particular endpoint.
Microsoft definitely needs to come up with a better way or extend the functionality of the partner center.
@CraigTurnbull : When those 10+ IT engineers are employees of your Partner company, the recommended option would be to use the delegated administration feature CSP provides (you don't need to actually sell the licenses via CSP to use this). See also here for a more detailed description on how this works.
This way you don't need to create user account in each customer tenant for admin purposes, your employees can just use their own accounts from your Partner tenant and each will use their own 2nd factor methods for MFA.
Also you can set up multiple TOTP apps for each account, but it is not easy to differentiate them during login, so I would generally avoid this option. I have heard that some Partners are using a Desktop TOTP app like Authy on a VM running in a central location each engineer has access to - but this somehow defeats the purpose of MFA - so primary recommendation is to use delegated adminitration feature the CSP model provides anyway.
What about all the functionality that is lacking when doing things via Delegated admin?
No Legal hold.
No content search
resetting a users MFA if they lose a phone etc is all unavailable via Delegated admin.
this is just a few of the things that is missing.
@Wihan : It is correct that 0365 Security & Compliance Center is not available, there is a uservoice feedback item on this: https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/34423372-allow-partners-to-access-the-security-and-complian also with a workaround that may work for some scenarios - like accessing S&C using the direct URL: https://protection.office.com/contoso.onmicrosoft.com
Resetting MFA status for the user is not a problem, tested it just a moment ago.
However, you are correct that there are some limitations to delegated admin, at least for some portals where those limitations are enforced via the UI (Powershell/API might work better). This needs to be addressed with each product team though, e.g. via provising specific feedback on uservoice.
It seems that the cart is before the horse in this case though as the requirements for us to enforce MFA have arrived before the means for us to manage a client efficiently with MFA enforced.
Also the workaround by appending the client domain to protection.office.com has never worked for me, not sure why. I just get my internal security and compliance page no matter what domain i append.
Yes, not requiring to create specific user accounts would be even better for security and most all manageability, but the decision to enforce MFA for delegated admin first is in my opinion the "horse before the cart" because this has much more impact than just enforcing MFA for all admin roles in an end customer tenant given delegated admin enables access to a lot of customers at the same time. So I don't agree 🙂
Also having MFA or not has exactly zero impact on the delegated admin capabilities, those are totally different problem areas..
What do you refer to? There is no plan to make MFA mandatory for all (Customer) tenants, at least none that I heard of . E.g. Azure AD Security Defaults will enable MFA by default for new tenants, but it is not mandatory to have those enabled.
Well here's the problem: when clients want MFA on our global accounts mandated... without paying for a cell-phone there is no way to fix that.
Partner portal is very restrictive when compared to logging in as an admin and most of our clients are using us as full 365 support...
How is Microsoft planning to address this?
Again WE are MFA'd but our clients are wanting the individual accounts MFA'd too but Microsoft
a. doesn't make Partner Access usable outside of very basic features
b. doesn't allow for something other than a phone number for MFA....
This needs to be resolved so that this solution can be a more scalable sell for MSPs while also securing the Global Admin accounts a lot of us need to do advanced configurations in Office 365.
So the customer wants to enable MFA for the account that are set up in the customer tenant?
So this means MFA needs to be enabled in the customer tenant
The default option, available to every customer with either AzureAD security defaults or other MFA enablement options, is that you use a token app for the 2nd factor. So you can use the same app your are currently using for the 2nd factor for those additional accounts, or use apps that you can install on non-mobile device like Authy.com. There is no need to have a unique cell-phone number or buy any phones, actually using phone is premium feature where either need a license unless the user account is a global admin.
Maybe the customer has just disabled all other authenticators than phone in his setup?
No, the customer wants to MFA OUR global admin role account which our service desk has to use to do things like convert shared mailboxes of dead accounts (which is NOT doable in the partner tenant like many other things).
The problem with one device is that we have over 30 technicians that need to go in and out of client accounts with 120+ tenants and some of them we need to be able to access more than others and in a fast way with ticket load being a concern.
There needs to be a better secure option for MSPs who want to MFA their global admin accounts for advanced configurations on clients (Or Microsoft can simply give the access needed in the partner center...)
It seems there are a bunch of different potential needs you have mentioned:
Goal #1: The customer - and you, obviously 🙂 - would prefer that for some tasks, like creating shared mailboxes, it would not be required to create an admin in their tenant, but the delegated admin functionality would be sufficient.
- --> This is a feedback that needs to directed to the Exchange team (e.g. uservoice), since it is true that delegated admin has some limitations, but the solution is owned by the team that builds the target service. Unfortunately it is not "simply" because this requires some rework in some services by those teams and not every product team has CSP as highest priority - I wish it would though.
Goal#2: When you create an admin account in the customer tenant because of above mentioned limitations, the customer wants to ensure this protected by MFA
- This is possible if MFA is enabled in the customer tenant for this account. Some of the options, all not requiring a cell phone, are even for free - or customer needs conditional access/AAD Premium plan1, which he probably has anyway when is asking for high security
- Then you would need that your IT team is using a shared device for doing MFA, e.g. Authy.com installed on a VM/Browser where the IT team has access to. Not nice, but can be done.
Goal #3: the customer wants to have control over the MFA process ("wants to MFA our global admin role") for either options on how you access their tenant
- In case of when you use delegated admin, this can even work to some degree when the Customer is setting up Conditional Access accordingly. Can not remember currently if setting the CA policy for directory role "Global Admin" is sufficient for delegated access, or if the policy needs to be targeted against Guest & External users to make this work, but I have tested this successfully once.
- The customer can enforce that MFA has to be done for the global admin account that is created in his tenant - or any new created global admin account via conditional access or AAD sec defaults.
- When you create an admin account in the customer tenant, it is possible that customer sets this up first, registers this for MFA himself and then every time you need access, the customer needs to confirm the access. Know some partners which have used this process for very special customers.
See numerous other threads in this community alone demeaning the failings of Delegated Admin rights with Partner Portal.
However, the quick answer to this is we set up a cloud mobile number and used flow to take the text and output it to a channel in Teams that everyone can see. This way, whatever the technicians or engineers are doing and wherever they are they can get the code to pass MFA. We use this system anywhere we need to share admin credentials among us, Mimecast and AppleID for example.
Hope this helps
Alex C Brewer
Sorry for the delay, been a busy couple of days but managed to squeeze this out of my colleague that set it up in our environment.
Hope it helps
Alex C Brewer