Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
Level 1 Contributor

Requirements clarification please

Hi everyone,

This may have been answered elsewhere, but there is so much to trawl through.

 

Im seeking clarification on what the requirements actually mean. I say actually, as I have been following the docs articles fairly closely, and i'm sure i've seen quite a lot of change in the phrasing. 

 

From the Overview page
Enable Multi-Factor Authentication (MFA) for all user accounts in your partner tenant. All user accounts in your partner tenant(s) must be challenged by multi-factor authentication (MFA) when signing into Microsoft commercial cloud services or to transact in the Cloud Solution Provider through Partner Center or via APIs.

 

On all the pages it says

Appropriate roles

  • Global admin
  • User admin
  • Admin agent
  • Billing admin
  • MPN partner admin

 So, does this actually mean that only these above account types have the requirement for MFA? What does Appropriate roles mean?

 

On the Mandating MFA for your partner tenant page under technical exceptions

Issue 2 says

A partner has some users in their partner tenants who do not require access to Microsoft Online Services Portals to manage customer resources using Partner Delegated Administration Privileges. The partner is in the process of implementing MFA for these users and need more time to complete. Is this a valid reason for technical exception?

Answer: No. Since these user accounts are not using Partner Delegated Administration Privileges to manage customer resources, they will not be required to sign-in to customer tenant. They will not be affected by Azure AD requiring MFA verification during sign-in to customer tenant.

 

What is meant by "Partner Tenant"

When this wording was added to the requirements docs, i initially took it to mean Microsoft is now recommending that partners maintain a separate Azure AD etc for their Partner management.

However, Microsoft also has a specific definition of "Tenant"

Tenants

For SaaS cloud offerings, the tenant is the regional location that houses the servers providing cloud services. For example, the Contoso Corporation chose the European region to host its Office 365, EMS, and Dynamics 365 tenants for the 15,000 workers in their Paris headquarters.

Azure PaaS services and virtual machine-based workloads hosted in Azure IaaS can have tenancy in any Azure datacenter across the world. You specify the Azure datacenter, known as the location, when you create the Azure PaaS app or service or element of an IaaS workload.

An Azure AD tenant is a specific instance of Azure AD containing accounts and groups. Paid or trial subscriptions of Office 365, Dynamics 365, or Intune/EMS include a free Azure AD tenant. This Azure AD tenant does not include other Azure services and is not the same as an Azure trial or paid subscription.

 

So does "Partner Tenant" simply refer to the partner center instance for my organisation?

 

Appreciate any insights.

1 ACCEPTED SOLUTION
Microsoft

Yes, this approach (risk based for some) would also meet the requirements. However, risk based CA policies require AAD Premium Plan2, so this will add some costs. Also "keep me signed in" is OK, but this does not mean the user wojn't get MFA prompts, the token will still expire at some point - in the AAD sign In Logs you can see if "MFA required was satisfied by claim in the token" - so it is still an access with MFA.

 

And in conditional access there is already a predefined choice for "external users and guests", so there might be no need to create a dynamic group for them.

 

Reg. the D365 - I'm not a Dynamics expert - but have you tried adding those "external" users as guests to AAD also? Wonder if this would change the behavior...

 


Reg. the question on splitting the tenant (Create new CSP Tenant):

1. Create a new AAD tenant in AAD portal

2. Create a new location in Partner Center for the MPN org. You can use the same organisation name as before, but there should be at least one different character in the org name (e.g. an additional "." at the end or use an abbreviation) - otherwise step 3 fails.

3. Do the enrollment as CSP again with a user from this new tenant

4. One the enrollment is confirmed (via email, after a few days) link the new enrollment to the MPN location ID from step 2

5. Send every customer a new CSP reseller invitation and let them accept it

6. If you are Direct CSP: Assign the same number & type of licenses again using the new CSP tenant, and immediately after that cancel/suspend all licenses in the old tenant (Licenses will be reassigned automatically); For Azure use the Transfer process.

If you are indirect: Check with the indirect provider if & how they need to update the records on their side.

7. If you are Direct CSP: Remove reseller relationship with the customer in the old CSP Partner Center

8. If you have customer you serve at Advisor, not as CSP, update the Partner of Record to the MPN Location ID (new Partner Center Tenant).

9. Contact Support and ask them to offboard the old tenant from CSP

 

Final Result is that in the old tenant you will still have Partner Center, but only for MPN management, and a new tenant with partner Center only for CSP.

 

 

View solution in original post

5 REPLIES 5
Microsoft

"Appropriate roles" just refers to the group of people for which this article is intended for - other roles do not have the rights to implement the security measurements or no decisive power.

 

It applies to all users in the tenant, including guests, regardless if they are actually using Partner Center or not.

This is also confirmed by the wording in the Partner agreement (MPA) and on several places in the FAQ.

 

"Partner Tenant" means the AzureAD tenant that used for conducting CSP business in Partner Center. You can see the used AAD tenant in the AzureAD profile in Partner center.

There might be different Partner Center instances in different tenants for a Partner - e.g.:

- contoso.onmicrosoft.com - where Partner Center is used for managing MPN organization.

- contosocsp.onmicrosoft.com - where Partner Center is used only for CSP, linked via the MPN ID to the Partner Center "instance" in the first tenant.

 

There was never a definitive recommendation if Partner should use only one tenant or different tenants - only for managing the MPN organization Microsoft did recommend to use the same tenant as for internal production in order to make it easier for employees to link their certification status to their employee account. For global Partners with businesses in different regions it was always required to have multiple tenants for conducting CSP business in those different sales regions.

 

I personally recommend Partners to have a setup like mentioned above - with one tenant for production & MPN, and another solely for CSP. This makes it easier to handle the MFA requirements, beneath other benefits that come with this seperation, e.g. the ability to get licenses via CSP channel for the production tenant. However, I know that for the sake of simplicity some people may have recommended to use a single tenant for everything - and while this is indeed simpler from a user management perspective, it is much more complicated when it comes to having strong security boundaries & implementing security requirements for CSP Partners.

 

Level 1 Contributor

I knew this would happen. One more question

 

How difficult would it be to separate the CSP program into a new tenant. What steps would be required?

Level 1 Contributor

Thank you for replying Janosch.

I agree that for a new partner, it may be best to separate the two concerns into two tenants - It might be best to publish that as a recommendation. 

 

And just to be clear, i'm not against MFA for all users, I'm completely on board. The problem that I have been having is a particular subset of users that are affected when i enable the necessary settings, we have not been able to resolve this with support.

 

Let me explain:

We have a Dynamics 365 FinOps environment that some external users require access to.

Note: These are NOT guest users, they do not exist in Azure AD at all.

D365 handles their authentication with the users registered Identity Provider (which i believe is the respective users Azure AD)

When we enable the baseline policy (now sec defaults), those users are unable to access the D365 environment. They are bumped over to the MFA setup page with an error message like "Something went wrong" or "You are not a member of this organisation"

So for "All users in the partner tenant", as far as i can tell, these "users" do not count.

Therefore, does the following meet the requirements

  1. Require MFA for administrators by Conditional Access
  2. Create a dynamic group for all members and guests in my Azure AD.
  3. Apply risk based MFA by conditional access for this group. (Excluding Service accounts)
  4. Enforce MFA per user on service accounts and enable App Passwords
  5. Where possible, move service accounts to App registrations

 

Final question: Does Risk based MFA meet the recommendations (this is what the baseline end user policy did) or are users required to MFA every time (are they allowed to say keep me signed in?).

 

Thank you again

Microsoft

Yes, this approach (risk based for some) would also meet the requirements. However, risk based CA policies require AAD Premium Plan2, so this will add some costs. Also "keep me signed in" is OK, but this does not mean the user wojn't get MFA prompts, the token will still expire at some point - in the AAD sign In Logs you can see if "MFA required was satisfied by claim in the token" - so it is still an access with MFA.

 

And in conditional access there is already a predefined choice for "external users and guests", so there might be no need to create a dynamic group for them.

 

Reg. the D365 - I'm not a Dynamics expert - but have you tried adding those "external" users as guests to AAD also? Wonder if this would change the behavior...

 


Reg. the question on splitting the tenant (Create new CSP Tenant):

1. Create a new AAD tenant in AAD portal

2. Create a new location in Partner Center for the MPN org. You can use the same organisation name as before, but there should be at least one different character in the org name (e.g. an additional "." at the end or use an abbreviation) - otherwise step 3 fails.

3. Do the enrollment as CSP again with a user from this new tenant

4. One the enrollment is confirmed (via email, after a few days) link the new enrollment to the MPN location ID from step 2

5. Send every customer a new CSP reseller invitation and let them accept it

6. If you are Direct CSP: Assign the same number & type of licenses again using the new CSP tenant, and immediately after that cancel/suspend all licenses in the old tenant (Licenses will be reassigned automatically); For Azure use the Transfer process.

If you are indirect: Check with the indirect provider if & how they need to update the records on their side.

7. If you are Direct CSP: Remove reseller relationship with the customer in the old CSP Partner Center

8. If you have customer you serve at Advisor, not as CSP, update the Partner of Record to the MPN Location ID (new Partner Center Tenant).

9. Contact Support and ask them to offboard the old tenant from CSP

 

Final Result is that in the old tenant you will still have Partner Center, but only for MPN management, and a new tenant with partner Center only for CSP.

 

 

View solution in original post

Level 1 Contributor

Thanks Janosch,

I will pass that on and see how we go.

Thank you very much for you advice