MFA + Service Account Requirements
I've been desperate for somebody to provide me with correct information about the changes in CSP program.
* We have escalated from our senior management to our Microsoft Partner Account Manager
* I've followed the session wich should provide more information but nodody wants to answer my questions.
So this is kinda my last resort before giving up.
We are have a lot of concerns about the new CSP requirements with regards of the new compliancy requirements.
* First of all: the baseline policies are in preview. Can we get a legal statement that microsoft will meet ALL production SLA's and complaince regulations with this service
* The mail that was sent to us states that we need to adopt the Secure Application Model Framework not only for the partner center API’s (as stated in the article) but also for Graph and other API’s. There are a lot of applications working with service accounts using the GRAPH API or API’s to use ARM. This would essentially break our core applications.
* Can somebody refine what MFA for all 'administrators' mean. Do you refer to global admin accounts? Or also other roles like CRM Admin. Which roles are subject to this?
Few concerns here:
* We have a AAD Connect manual setup as this is the only way to have just enough permissions in AD to syncrhonize. Although enabling the MFA baseline policy would break AAD connect. What is the correct approach to allow exceptions here? A few answers we already got was: contact support when ik breaks (which is non acceptable) or enable app passwords (which is also unacceptable is this is a tenant wide settting and would make our environment less secure). Note that we already implemented CA + MFA voor all our users with exceptions for Trusted devices (DR/AADJ)
* What about CRM sync? There is no other option then using a service acount + legacy authentication (EWS) to get this working. How can we keep on using Microsoft CRM ?
* The sessions mentions break glass account need to use 3th party MFA. Is there no other way around this? We need this functionality to be able to exclude an account in case some of our admins makes a mistake in configuring CA or when the MFA service is down (which happened already 2 times last year). We use security monitoring in these accounts to govern the usage of it trough our SecOps teams.
Some general questions as well:
* Is there any legal statement on which technical requirements exactly need to be in place?
* We are strongly thinking about splitting our production tenant from CSP. As we believe this decision was made, without thinking this trough. Microsoft software itself is not compatible with the policy ATM - let alone all different other toolings we use (in the case of integrations with Graph also being impacted by the policy) => Can somebody elobarte A) if this is possible B) What would happen with existing customers? C) How can we also connect our MS Partnership with this seperate tenant?
Also i would like to share some feedback: It feels that partners are getting a lot of work because Microsoft built and unsecure product and made a faulty architecture with the RBAC model with the CSP program. One example is that to manage our MCE's our internal backoffice need GA permissions (which was confirmed by MS Support) meaning that they also get these rights in our customers tenants. This doesn't make any sense at all.
Hopefully somebody can answer some questions here - as it feels like we are pretty much left in the dark here. And Microsoft is still figuring out how to implement this policy as well - as not all documentation/contracts are ready.
Thank you for the feedback - sorry to hear that it take this much effort to get some answers.
I have answered (most of) the questions below - even though those answers will not resolve some problems you are facing I'm hoping that they at least provide some clarity on the current situation and options. Feedback like this also drives the internal discussions and will lead to better documentation, so again thank you.
- Reg.: Baseline policies in preview. Services which are in preview do not have a SLA and are provided "As is" (Online Services Terms document appicable terms for preview features - which is then the legal statement that no SLAs are provided)
- API access: Since all user accounts are subject to the MFA requirement there are essentially only tow options for any API access. App only - or App & User with secure app model.
- MFA for administrators - do you refer to the free MFA for admins? It is only free for users with global admin role in the CSP Partner tenant - see https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing
If you refer to the baseline policy for admins - this affects more admin roles as described here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-baseline-protect-administrators
- AzureAD Connect: As of now the statement is that AAD connect engineering is aware and will ensure the the sync account does not break. If there are issues support should be contacted (which is the official way to track any issues). This has also been confirmed in the updated FAQ.
App passwords will not work for this account afaik.
- CRM Sync: If this is using legacy auth. it seems that app passwords are the only solution.
- break glass account: There is no other way - since when technical enforcement starts an emergency account that did not go through any form of MFA would not be able to log on. Also confirmed in the updated FAQ
- legal statement: The requirements are documented in the CSP program guide. Program guide is part of the reseller agreement. However, as it is common for legal statements, this does not contain a lot of technical details. It basically just mentions that you need to enable MFA and mentions the baseline policies, Azure AD Premium and 3rd party MFA as options.
- Splitting tenants: There are two options:
1. move production to a different tenant and keep CSP where it is. Moving data to a new tenant would most likely required 3rd party software.
2. Register as CSP again using a new tenant. Then each customer will need to be invited again - if you are Direct CSP you will also need to exchange all subscriptions for each customer (Add the same subscriptions via the new CSP tenant, then cancel the old ones) - for indirect resellers this is not required since the subscription are provisioned by the provider and that does not change. The new CSP tenant will be linked to your MPN status by using the MPN ID (When registering as CSP you need to enter a MPN ID - this answers C.).
However - for the 2nd option there is one thing that need to be documented & clarified: Currently Microsoft does not have a support process to remove the CSP "flag" from the tenant. It is currently being discussed internally on how Partners can completely off-board a tenant - so as of today I can only recommend option 1.
- "MCE's" - Do you refer to Microsoft Certified Educators?
Thanks for answering my questions.
* In terms of the MFA for all users legal statement, does this mean all normal users should be enabled for MFA as well, so not only risk based MFA ?
* For the AAD connect - we are aware that it will break, as we don't use the auto-created service account but the manual one (using manual procedure) - should we in this case contact support in advance or how should we proceed here?
* In terms of splitting the tenant - this is pretty problamatic. Migrating our full tenant is really not an option. Additionally the FastTrack team (which have similar requirements) is recommending us to split out the tenants, but the CSP team is advising not to do this. Kind of confusing.
* Overall, I still don't see a good solution here:
You are advising using policies which are not covered by SLA's (as they are in preview). If want to avoid this we should go for P2 licenses which make it unprofitable for us to sell CSP licenses in comparison with EA licenses - our margin will need to go to the new P2 licenses. On top of that we have to enable app passwords (tenant wide) which will make our tenant less secure.
* MCE refers to Microsoft Certified Engineers.
Looking forward to your answers.
@RobinVermeirsch : Sorry for the late response, was in vacation for a few weeks.
All users need to be enabled/enforced for MFA. The CSP Program guide mentions multiple options - enable the two baseline policies and/or enable MFA by leveraging paid licenses (AAD Premium).
It is true that end user protection baeline policy will currently only trigger MFA when risk is detected, this behavior will change to trigger MFA when a user from a CSP tenant authenticates (very high level description on the planned change). So even though currently end user protection is only risk-based MFA you are compliant as per the contract right now if you enable this policy.
Reg. AAD Connect: Yes, please contact support. You can also rerun setup and use the integrated account if you want to .
Reg. Split - What I have heard a lot is that MPN suport team does recommend to split the tenant - this is because it is much easier for user to document the certification status for competencies in MPN if "MPN Partner Center" is enabled in the production tenant. For CSP I know some engineers recommend it for simplicity.
Reg. the preview state - if you do not want to use the preview baseline policies, you would need to have Office 365 Enterprise plans/AAD Premium Plan 1 to enable MFA per user, or AAD Premium Plan1 to enable conditional access. There is no need to have AAD P2 - this would only allow to create your own risk-based policies which are not required (unless you want to make use of them).
App-Passwords tenant wide: You can limit the ability of creating app passwords to only those users which have MFA enabled per user. So you could e.g. enable baseline policies + enable MFA for certain user accounts so they can create app passwords. user accounts which do not have MFA enabled per user will still not see any option for app passwords.
Sure, you can always also offer customer licenses from other channels, there is no need to resell CSP licenses. And if you can not implement the required security measurements for this model, other channels where you don't get delegated admin permissions on customers per se might be the better option.