Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
Level 1 Contributor

Partner Center / CSP with Conditional Acccess

Hi

 

We havily use and love conditional Access - especially to restrict access to critical apps.

However with we miss an Option to enforce MFA when User signs into Partner Center since (There is no dedicated app available when modelling Conditonal access policies).

Will this ever be supported? Meanwhile the only option we are left is to use dedicated identities for signing into partner center and enforce MFA to those identities....

60 REPLIES 60
Microsoft

@stan :

From contract/agreement perspective setting an exception is not allowed. The baseline policies are technically still a preview feature, so it might be that screenshots shown in the documentation and actual experience might differ a bit (And documentation then needs to be updated - so thank you for the feedback). The baseline policies are basically a simplied version of Conditional Access rules, for any additional customization needed you can technically also use Conditional access.

 

Reg. the 2nd question: Basically anything that is using the CSP tenant's AzureAD - Office 365, Dynamics 365, Intune, AIP, GraphAPI

 

 

Level 3 Contributor

So, example to explain please.

 

When baseline does not have exception for special accounts like meeting rooms and so which does not access Partner Center (does not have role assigned here) but they are configured to sign-in to tablet showing the meeting entry info. We do not enable baseline, but use Conditional Access there limit them to local IP, but not enforce MFA. Normal users are configured with MFA or using MDM compliant device (Intune with MDATP policies).

 

What happens, please?

 

  • Will Partner Center work normally?
  • Even when user does not do MFA because he is on compliant device?
  • Will only this user cannot access portal or all of them?
  • Will be company compliant with requirements?
Microsoft

@WolfKPCS : Generally you need to enable MFA for all access to all commercial cloud services in this tenant - regardless if the user account used has  a role in Partner Center or not.

So e.g. using CA rule to not trigger MFA on a compliant device will not be compliant to requirements in CSP Partner agreement  - so question is if does really matter if it still might work in some scenarios.

 

Level 3 Contributor

@JanoschUlmerThanks! Let me ask more explicit question as it is important for us. Does the policy will affect login to those services via automation tools like APIs, PowerShell, CLI?

Microsoft

@stan :

Yes, this is why it is also required to adopt the Secure application model for automation scenarios: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#aadsts50076

Visitor 1

@JanoschUlmer :
We would like to adopt the secure application model for all automation scenarios. However, Microsoft Dynamics 365 Business Central only supports username/password authentication. Furthermore, the on-premise Microsoft Dynamics CRM email router does not support anything other than username/password authentication to retrieve email from exchange online. How are we supposed to keep using these Microsoft products?

Level 3 Contributor

@JanoschUlmer  Let me give  a little more information. Today I have enabled the policies in Sandbox Azure AD. When I login with user account to Azure Portal (so it affects Azure portal) I am asked to enable MFA now or in 14 days at latest. So obviously this affects Azure Portal as well. When I tried to login with that account to Azure and Azure AD via PowerShell I have done it successfully without any issue but the problem is what will happen when those 14 days expire and I am force to enable MFA. Will I be able to login to Azure and Azure AD via PowerShell without having to enable MFA for that acount and using refresh tokens? Scope of these policies is something that I have not found documenation nor I haven't found information how they will affect APIs, PowerShell and CLI.

Microsoft

@stan:

To the 2nd question - yes, Azure Portal is of course also affected (since it used AzureAD or authentication). It will also affect access via Powershell, CLI, API if user credentials are used.

 

The login will only work if you use either MFA (interactive login - so not suitable for automation) or an access  token/Secure app model instead of user credentials. 

Level 3 Contributor

@JanoschUlmerIt has been more than 2 weeks since we have implemnted this and so far what has been described as what these policies affect is not quite true. I can still login to Azure and Azure AD with user credentials if I use PowerShell modules Az and AzureAD. Nothing forces me to enable MFA. It seems this somehow affects logins trough portals like Azure Portal. And even there the force is not so required as it gives you message to skip for 14 days. I haven't tried clicking on that button to see if after 14 days for sure it will force me to setup MFA but definately these policies are unknown how they work exactly. Is there actually anyone inside Microsoft who knows exactly how the policies work and what is the scope of the effect? Additionaly I have checked with another AAD and that AAD has the same policies but there there is exception configuration for user accounts. Seems that the default policies were intentionally modified to CSP parnter tenants to remove those exclusions. This is nowhere documented. It might sound that I am going on rant but it is important to understand that this was executed by Microsoft without any prepration or thought for partners.

Microsoft

@stan 

The end user protection baseline policy will currently enforce MFA only after 14 days - and also currently only when a specific risk was detected (see https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-baseline-protect-end-users). Specific for the CSP scenario expect that the baseline policy will evolve and for logins from users in a CSP tenant MFA will always be triggered.

 

So this is why you currently will not see immediate effects when you enable the end user baseline policy.

 

The option to set an exception was removed end of June. Existing tenants that already worked with the baseline policies might still see the option to exclude users, newer ones do not. This was a general change, this is not specific to CSP tenants.

 

Level 3 Contributor

All that information was not available when I asked about it the first time. In fact I have got different information which was not true thus put me in the wrong direction. Even the policy description does not answer all questions. About the exceptions options I have checked those on a tenant that hasn't enabled those policies so I am not sure how that existing tenant that didn't used them still had the option. If at least the documentation was correct to say: hey we are updating those policies to remove the exclusion so for some of you they might not be present. My main point again is that this was very badly executed by Microsoft and unfortunately is it not the only bad decision for partners lately.

Level 3 Contributor

@JanoschUlmer  This is not good at all. I would call this execution plan fiasco as there are a lot of things that were not considered when someone has decided to execute this, let alone allows us with enough time to prepare.

Visitor 1

Since the Partner Center is pulling in all the AD accounts, how can we limit which accounts are synced to Partner Center? For example, we have several service accounts that got synced to Partner Center and can't have MFA enabled.

Microsoft

@amattb:

 Partner Center is not "pulling" the AzureAD accounts, Partner Center is based on the AzureAD account information on the tenant, so you can not restrict any sync. 

 

Basically the recommendation would be to have one AzureAD tenant only for CSP business where all have MFA, and a separate tenant for all other use, like internal productionm. From a local AD you can deploy the sync tool (Azure AD Connect) two times on seperate machines and use filtering to decide which user accounts are synced to which AzureAD tenant, of course you can only use a custom domain in one AzureAD tenant at the same time. The recommendation is not only because & since the announced MFA security requirements, but generally a best practice for strict seperation of permissions (e.g. Global Admin of your own production environment should not get access to end customer environments).

Level 1 Contributor

@JanoschUlmerhaving two (or more) tenants may make sense for this requirement but from a practical level how would you do this since we did not build this from start? All current connections to Microsoft (MPN status, partner of record, sales and more) are with our current tenant. To seperate out our CSP business from this would be quite a task. We are a small partner organization and not direct CSP. (I think the term is indirect reseller or someting). 
So how do we do this? Separate out all CSP administrators is quite simple as you stated but the rest?  What will happen to Internal Use licenses? Our MPN membership satus? Competencies? How is all this connected? Is there any guidance published?

 

/Mats

Microsoft

@matgus My general recommendation would be to move the internal production use to a separate tenant, not move the CSP business. "Recommendation" is maybe the wrong word - since both options are not easy.

 

When you move the CSP business to a new tenant, this requires to establish reseller relationship again with every customer, I expect issues with incentives/consumption reporting etc. As indirect reseller at least you would not have to face the issue to provision the same licenses again to all customers (They stay linked to the indirect provider).

 

When you move the production business to a new tenant, the issue is that migrating data between tenants requires 3rd party solutions (and exact process depends on many factors - e.g. if you have local AD connected, what kind of services you use..) - the benefit is however that the impact on customer and any MPN processes is zero. Also you then have the option to obtain licenses via CSP channel for production (Which is blocked when tenant is tagged as CSP tenant - this tag can not be removed currently).

 

Reg. MPN - actually you have to differentiate between MPN in Partner Center and CSP in Partner Center - these do not have be on the same tenant/same Partner Center access. 

E.g. you can migrate production to a new tenant - and leave MPN management where it is - so a single Partner Center account is still used for both CSP and MPN management. 

Moving the MPN management to different tenant needs to be done by logging a support request in Partner Center support (and does take several weeks).

 

Unfortunately internal use licenses can not be moved to a new tenant. They can be activated in a different tenant, but if they are already acvtivated, they need to stay where they are.

 

Competencies rely on employee certifications & reported revenue/consumption - so if MPN is kept where it currently is there is no impact. If you move MPN to a different tenant, user need to link their MS learn accounts again.

However, it would be a better experience for employees if MPN management is done in the tenant they use for production - because then they do not need additional credentials to update their certification status. So the best design - for me - is TenantA (existing): Used only for CSP / TenantB (new): Production & Management.

 

Afaik there is no guidance available that explains all of these aspects end-to-end - would also appreciate if something like this exists. Unfortunately in my current role I do not have resources or freedom to invest the required time to create such guidance (yet Smiley Wink).

 

 

 

 

Visitor 2


@JanoschUlmer wrote:

Basically the recommendation would be to have one AzureAD tenant only for CSP business where all have MFA, and a separate tenant for all other use, like internal productionm. From a local AD you can deploy the sync tool (Azure AD Connect) two times on seperate machines and use filtering to decide which user accounts are synced to which AzureAD tenant, of course you can only use a custom domain in one AzureAD tenant at the same time. The recommendation is not only because & since the announced MFA security requirements, but generally a best practice for strict seperation of permissions (e.g. Global Admin of your own production environment should not get access to end customer environments).


We currently use 1 tenant for internal production and CSP. Is there a way to switch the CSP part to a new tenant? 

Microsoft

@khuizer @sdicecca :

If you want to split tenants, I would rather suggest to consider a move of the production workload to a new tenant.

 

There was, until now and to my my knowledge, not a clear recommendation to have seperate tenants. Only from overall security perspective it was always true that it is a best practice to have strict seperation of permissions. So I needed to split tenants if I wanted to avoid giving the global admin that is only managing my internal production environment permissions to manage also all of my customers -  this is one of the examples why Partners I have talked to wanted to have a seperate tenant for CSP. 

 

Moving the CSP part to a new tenant would require to register again as CSP, established the reseller relationship again with each end customer - and exchanging all licenses (cancel/suspend from current CSP tenant, provision new ones from new tenant). Would only do this if the number of customers is very low.

Also, I'm not sure that moving CSP to a new tenant will even resolve the technical issues with MFA enforcement - because the old tenant will still be flagged internally as CSP tenant (This flag can currently not be removed). Have asked internally for clarification on this aspect, depends a lot on how exactly the technical enforcement will work at a later date.

 

 

Level 2 Contributor

Just like @khuizer. We are also looking for an answer for this.

That would make everything a lot easier. I can't find anywhere that Microsoft ever said that to have one tenant for production and one for CSP is best practice.