CSP Compliance (MFA)

[SvenCelis90]

Hi,

I'm creating this post in regard to the CSP compliance requirements which are obligated and will be technically enforced by Microsoft in the near future. I can only applaud Microsoft for ensuring that their partners stay on top with latest security standards. However in this particular case, I feel that Microsoft has ignored the reality and issued a best practice as the rule for their partners.

When reading this forum, it seems that a lot of partners have a mixed CSP/Production tenant. This implies that the CSP requirement will impact the configuration of the production tenant. This forum post is in regard to the possibilities and the possible exceptions related to this setup.

A frequent solution in this forum for this specific setup is seperating the "CSP" and "production" tenant. We've validated this approach with our Microsoft contacts and this seems as a daunting task. I see the following options with their related impact:

• Creating new tenant for CSP: When reading the forum, this is not really an option since Microsoft can't change the 'CSP' flag of the current tenant. Even if this was possible, all customers would need to re-link with the new CSP tenant. This impacts our customers and operations with the customers.
• Creating new tenant for production: This implies that migration software needs to be used to move all production content to a new tenant. This is not a preferred scenario or a scenario we're currently considering.

Could you please comment why this is mentioned as a solution on this forum while our MS contacts are not recommending this approach? I feel that the answer on the forums is rather black and white and doesn't take into consideration the impact on the partners. 

Since splitting the tenant was advised against, we've started with a review of all tenant accounts and have seperated them in 2 groups:

• Service related accounts: Accounts used by applications, Meeting Rooms,..
• Office worker accounts: Personal accounts of employees

Securing the "Office worker accounts" of the partner is very straight forward and I feel that this implementation is already overdue. Securing the "Service related accounts" is something completely different. Excluding these accounts is even mentioned as a recommendation on the Conditional Access docs.

Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policy:
Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services and allow programmatic access to applications. Service accounts should be excluded since MFA can’t be completed programmatically.

We're still in the process of validating the accounts and linked applications, but I already wanted to share some findings and hurdles we're currently facing:

Meeting Room accounts (Microsoft Teams and S4B)

As mentioned numerous times in the forums: There is no solution currently for any SfB Room devices or Teams Room devices. Complying to CSP requirements is impossible in this mixed environment. More information on latest post here.

Microsoft Hubs

Same feedback as case above.

Ticketing system which uses IMAP to connect to mailboxes:

When reading through the forums, "blocking legacy authentication" is not a requirement of Microsoft to be CSP compliant. So technically, we could assign P1 license, enable account for MFA, create an app password and authenticate with this app password. Is this statement correct? And is Microsoft planning to block legacy authentication in the future for partners? If this is the case, this isn't really a valid scenario in my opinion.

These are the 3 biggest examples of service accounts in our tenant, but more examples will rise to the surface during our research. Besides these 3 statements, I still have the following open questions in regard to the uncertainty of CSP compliance:

• Currently, we can't make use of the "Security Defaults" since we rely on "Conditional Access" to make use of APP. The documentation states that "Security Defaults" can't be enabled when "Conditional Access" policies are in place. So basically this means that APP (eg: require approved client app) and conditional access to secure other applications (SaaS, App Proxy,..) which integrate with AAD can't be used anymore. Can you please confirm?
• Even if "Security Defaults" is an option, I still feel that we would be greatly dependant of the policies which Microsoft wants to enforce. When reading the forum, a comment was raised that Microsoft is going to prompt CSP partners for each login. This implies that the "risk based approach" in Security Defaults is no longer applicable for CSP partners. Can you please confirm?
• We're considering the AAD P2 license to make use of "Risk Based Policy". Could you please confirm if the statement in the previous bullet will also apply to this license?
• Will "Token Lifetime" in conditional access policies have an impact on the MFA prompts for service accounts? Let's say we keep the default of 90 days.. Will we only be prompted with MFA every 90 days or is this not applicable for CSP partners?
• Let's image the following scenario: A ticketting tool makes use of username + password to read the mailbox of a useraccount. Let's say that this application supports modern authentication and MFA. To become CSP compliant, we enable MFA on this user account to configure it in the application.
  • We'll need to register for MFA and thus store the 2nd factor (authenticator app, HW token, sms/phone call,..). How can we store this 2nd factor securely while ensuring that supporting employees have access to this token? This information can't be linked to 1 specific device. What's the best practice that Microsoft recommends?
  • How can we be notified when the application is prompting for MFA? This implies that the application can't communciate anymore and application services aren't working correctly anymore.
  • I hate to say it, but it seems that a move back to Exchange On-Prem is the most "easiest" option to comply with CSP requirements.
• Can the above scenarios be seen as a valid "technical exception"?
• Will "Security Defaults" also take these technical exceptions into consideration?

Besides these technical questions, there is also the impact on the licensing cost of the CSP partner. While implementing AAD P2 licenses to make use of "MFA Registation" and "Risk based MFA" would be preferred, this has a huge impact on the budget. To be compliant with the CSP policies, I was thinking about the following approach:

Office Workers: AAD P1 license since it's the minimal requirement (since Security Defaults isn't really an option). On corporate managed devices, we would like to limit the MFA prompts while making use of "Windows Hello For Business". For non corporate laptops, we'll just have to accept the constant MFA prompts (which will sadly enough teach our end-users to just click on "approve" in their authenticator app).

Service Accounts: AAD P2 license due to the risk based capabilities which won't prompt for MFA for low risk logins. Since these accounts will always be used from the same location, I assume that these authentication requests will always go through without prompting MFA. Could you please confirm?

At this moment, I personally can't see how the tenant can comply with the CSP requirements when we're in this mixed environment. We're too dependant of our ISVs to support modern authentication. Even if this was possible, storing the MFA registration information (authenticator app, HW token, SMS, phone call,..) to a central location so all supporting teams have access when required doesn't also seem to be the way to go.

Could Microsoft please provide technical guidance and use cases to comply with the CSP requirements in this mixed environment? I'm secretly hoping that Microsoft is working on a solution to gracefully split the tenant and move CSP activities to a new tenant without disruption operations for our customers.

I hope we can resolve and clarify these issues before Microsoft will enforce the CSP requirements.

Thanks in advance for the guidance and answers.

[JanoschUlmer]

Could you please comment why this is mentioned as a solution on this forum while our MS contacts are not recommending this approach? I feel that the answer on the forums is rather black and white and doesn't take into consideration the impact on the partners. 

When reading through the comments I gave on the topic, I think it is clear that it is not a "black & white answer",I always referred to the fact that a split is a complicated and lenghty task, so it is 100% clear that there is significant impact. However, it is the only option if you don't see any way to fulfill the security requirements - since there is no long-term exception from this policy.

Personally I think having a split tenant is, even before the MFA topic came up, a security best practice - because otherwise an admin responsible for the production system (e.g. an admin that can control user/group assignments) could get access to end customers. 

I know some people within Microsoft do see this aspect differently, but I'm happy to discuss this with them if you want to connect us (any Microsoft contact you are in contact with can look up my contact info).

Excluding these accounts is even mentioned as a recommendation on the Conditional Access docs.

Yes, because those docs handle conditional access generally - the Security Requirements for Partners are a specific additional requirement where some of those concepts do not apply anymore in its full extend. 

So technically, we could assign P1 license, enable account for MFA, create an app password and authenticate with this app password. Is this statement correct? 

Yes, as mentioned in the documentation: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#do-you-have-an-application-or-device-that-does-not-support-the-use-of-modern-authentication 

 And is Microsoft planning to block legacy authentication in the future for partners? If this is the case, this isn't really a valid scenario in my opinion.

Not specifically for CSP Partners, but e.g. Exchange team is working on something like that: https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/

Note that the baseline policies will be replaced in february 20ß20 with AAD security defaults, and security defaults will block legacy auth. So by then you will need to use per-user MFA or conditional access to still allow legacy protocols to work: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults 

Reg. Teams Room System/Surface Hub: 

As mentioned in those other threads there is afix in the works that will support Modern Auth. - no concrete ETA/public ETA available (rough plan was Q4 2019, but I guess this will take some more time).

Currently, we can't make use of the "Security Defaults" since we rely on "Conditional Access" to make use of APP. The documentation states that "Security Defaults" can't be enabled when "Conditional Access" policies are in place. So basically this means that APP (eg: require approved client app) and conditional access to secure other applications (SaaS, App Proxy,..) which integrate with AAD can't be used anymore. Can you please confirm?

Yes - if you use CA more defining scoped policies, you can't use the cost-free security defaults.

Even if "Security Defaults" is an option, I still feel that we would be greatly dependant of the policies which Microsoft wants to enforce. When reading the forum, a comment was raised that Microsoft is going to prompt CSP partners for each login. This implies that the "risk based approach" in Security Defaults is no longer applicable for CSP partners. Can you please confirm?

Yes, specifically the enforcement for doing MFA each time is currently rolling out for the scenario that a Partner access an end customer tenant with delegated permissions, see: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa

We're considering the AAD P2 license to make use of "Risk Based Policy". Could you please confirm if the statement in the previous bullet will also apply to this license?

Yes, the enforcement for MFA as described in https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa will also apply when using your own risk based policies.

Will "Token Lifetime" in conditional access policies have an impact on the MFA prompts for service accounts? Let's say we keep the default of 90 days.. Will we only be prompted with MFA every 90 days or is this not applicable for CSP partners?

Not sure which feature in CA policies specifically our are reffering to - Configureable token lifetimes are deprecated though.

"Remember MFA on this device" in MFA service settings will also have no effect on the scenario where MFA is enforced now (see link to the question before for the scenario I'm referring to).

When using the secure app model, during each authentication a new refresh token with 90 days lifetime will be issued, so for secure app model implementation now MFA prompt would ever reappear.

Let's image the following scenario: A ticketting tool makes use of username + password to read the mailbox of a useraccount. Let's say that this application supports modern authentication and MFA. To become CSP compliant, we enable MFA on this user account to configure it in the application.

(..) What's the best practice that Microsoft recommends?

If the app/service supports it, use https://docs.microsoft.com/en-us/partner-center/develop/enable-secure-app-model

If not, use app passwords.

Storing the 2nd factor is not possible, you can only store a token using secure app model. 

I hate to say it, but it seems that a move back to Exchange On-Prem is the most "easiest" option to comply with CSP requirements.

If you think so - I personally doubt such a project will have less impact than enabling App passwords for this account 🙂 However, for some edge cases it might be possible to have a hybrid config and configure such a mailbox onpremises.

Can the above scenarios be seen as a valid "technical exception"?

In my understanding, no - but you can try: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa#request-for-technical-exception

Service Accounts: AAD P2 license due to the risk based capabilities which won't prompt for MFA for low risk logins. Since these accounts will always be used from the same location, I assume that these authentication requests will always go through without prompting MFA. Could you please confirm?

Yes, however I do not think having a risk based policy on an automated/unmonitored Service account is a good idea, because it might suddenly fail.  And you should also note that AAD licenses need to be assigned to a user , and user means person in the licening terms. So any person using a feature of the service accounts needs a P2 license.

Could Microsoft please provide technical guidance and use cases to comply with the CSP requirements in this mixed environment? 

We have numerous, contntlly updated articles, and Microsoft Partners can alsways contact us to get 1:1 guidance (askpts[at]microsoft.com for englisch, depts[at]microsoft.com for German support.

I hope we can resolve and clarify these issues before Microsoft will enforce the CSP requirements.

Enforcement already started, but currently enforcement is only defined for a limited scope as described here: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa

So while the contractual requirements demand any account has MFA, technically exceptions are possible since enforcement will not kick in for each scenario. However - if you think that the requirements do cause to much problems in he production environment, we are back to start & the question if a tenant split could make sense.

Regards,

Janosch

[SvenCelis90]

Hi Janosch,

First of all, best wishes for 2020! I would also like to thank you for taking the time to respond to the numerous questions.

Really appreciate the quick and extended information you've provided at this short time.

I also appreciate the suggestion of connecting our Microsoft contacts with you to have an open discussion about a possible CSP tenant split. I've informed our Microsoft contacts and they informed me that they will contact you after your holiday.. I'm aware that this would be the preferred scenario from a security and CSP compliance perspective.

Based on your feedback, I've the following follow-up questions:

So technically, we could assign P1 license, enable account for MFA, create an app password and authenticate with this app password. Is this statement correct?

Yes, as mentioned in the documentation: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#do-you-have-an-application-or-device-that-does-not-support-the-use-of-modern-authentication

1. Looking at the documentation (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#app-passwords) App Passwords can't be used in combination with "Conditional Access". I assume we need to exclude these accounts from conditional access to ensure that app passwords can still be used after enabling it on a "per user" basis (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates). Is this correct?
2. Since allowing "App Passwords" is a general setting, all our end-users will unfortunately also be able to create "App Passwords". Is this statement correct?
3. When using App Passwords or accounts which use "secure application model framework", these service accounts still need to register for MFA. What's the recommended MFA registration of Microsoft for these specific accounts? These accounts are managed by engineers and need to be supported by our operations team. Thus linking it to 1 specific hardware token, authenticator app on personal or shared "master MFA device" doesn't really seem the best option. Is using a backup mail address of a shared mailbox with delegate permissions to all the required persons the recommended approach of Microsoft? How has Microsoft done this for their service accounts?
4. App Passwords can only be used for "legacy authentication" protocols. So "Secure Application Model framework" would be implemented for these services which support "modern authentication" (eg: powershellscripts,..). Correct?

Yes, specifically the enforcement for doing MFA each time is currently rolling out for the scenario that a Partner access an end customer tenant with delegated permissions, see: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa

Are other scenarios also defined which will force MFA to access Microsoft Online Services? This change is specifically to perform CSP activities which makes sense to me. But will this also ever be applicable for users which are accessing cloud services which aren't linked to CSP activities?

Not sure which feature in CA policies specifically our are reffering to - Configureable token lifetimes are deprecated though.

"Remember MFA on this device" in MFA service settings will also have no effect on the scenario where MFA is enforced now (see link to the question before for the scenario I'm referring to).

When using the secure app model, during each authentication a new refresh token with 90 days lifetime will be issued, so for secure app model implementation now MFA prompt would ever reappear.

I'm referring to the "sign-in frequency" described in the policy below. More specifically for services which aren't impacted by the MFA enforcement as described.

Service Accounts: AAD P2 license due to the risk based capabilities which won't prompt for MFA for low risk logins. Since these accounts will always be used from the same location, I assume that these authentication requests will always go through without prompting MFA. Could you please confirm?

Yes, however I do not think having a risk based policy on an automated/unmonitored Service account is a good idea, because it might suddenly fail.  And you should also note that AAD licenses need to be assigned to a user , and user means person in the licening terms. So any person using a feature of the service accounts needs a P2 license.

The AAD P2 license was a suggestion to avoid the MFA prompts all together. But if the application supports "App Passwords" or the "Secure Application Framework", it's indeed not really relevant to make use of this approach. For either implementation, MFA registration will need to be completed, so MFA can't really be avoided (even using the P2 license).

Additional questions:

 - As the requirement is MFA for all users, our external users (with access to Teams websites) will also be impacted. I've understand from this and this link, that we need to foresee AAD P1 licenses in a ratio of 1:5 for these users. Correct?

- These external users will always need to register for MFA in our tenant (regardless if they are already configured for MFA in their own tenant). So they might end up with multiple MFA registrations. Correct?

- The requirement page mentions that MFA is required for "Microsoft commercial cloud services". Can you provide a definitive list of applications which we need to target via "Conditional Access policies"? Would "Office 365 Exchange Online" & "Office 365 SharePoint Online" be sufficient? Or do we also need to add "Yammer, Microsoft 365 Dynamics, Flow, Planner, Teams,..."

Thanks in advance and happy a great holiday!

[JanoschUlmer]

Also a happy new year 🙂

Looking at the documentation (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#app-passwords) App Passwords can't be used in combination with "Conditional Access". I assume we need to exclude these accounts from conditional access to ensure that app passwords can still be used after enabling it on a "per user" basis (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates). Is this correct?

Not quite - the statement of the CA website refers to the fact that if you are only using conditional access, there will be no option to create app passwords. But if you target a user with a CA policy where MFA is required, and parallel you enable the user for per-user MFA, you can create app passwords and fulfill the CA controls when using an app password. Note this does not work this way when using AAD security defaults. Of course an exception in the CA policy would work the same way, but based on my testing this is not necessary.

Since allowing "App Passwords" is a general setting, all our end-users will unfortunately also be able to create "App Passwords". Is this statement correct?

All users where the admin has set the per-user MFA state to enabled or enforced. If this is disabled, user can not create app passwords. So the admin has control which users can do this, and when using conditional access you could also block legacy auth. specifically for users where the state is enabled (for whatever reason), so even the ability to create app passwords would not mean users can actually use them. 

When using App Passwords or accounts which use "secure application model framework", these service accounts still need to register for MFA. What's the recommended MFA registration of Microsoft for these specific accounts? These accounts are managed by engineers and need to be supported by our operations team. Thus linking it to 1 specific hardware token, authenticator app on personal or shared "master MFA device" doesn't really seem the best option. Is using a backup mail address of a shared mailbox with delegate permissions to all the required persons the recommended approach of Microsoft? How has Microsoft done this for their service accounts?

Several options - first you can register multiple token apps for each account, e.g. also an app running on a Windows PC or VM where those admin have access to. For secure app model the MFA will only happen one time when registering, not for subsequent access. Admin can always reset the MFA registration status of a user account in case MFA needs to be done again and app/device was lost. You can also use an office phone number as 2nd verification option where multiple admins have access to.

Email adresses can not be used for MFA (only for self-service password reset).

I don't know if & how Microsoft IT has done this.

App Passwords can only be used for "legacy authentication" protocols. So "Secure Application Model framework" would be implemented for these services which support "modern authentication" (eg: powershellscripts,..). Correct?

Yes

Are other scenarios also defined which will force MFA to access Microsoft Online Services? This change is specifically to perform CSP activities which makes sense to me. But will this also ever be applicable for users which are accessing cloud services which aren't linked to CSP activities?

Only as mentioned in the article - delegated access now, Partner Center portal & API access in H1 2020. I have no information on further plans. However, to be clear on that, even though it is not enforced, from contract perspective (MPA) it is still required to configure MFA for those users which are not using Partner Center.

 - As the requirement is MFA for all users, our external users (with access to Teams websites) will also be impacted. I've understand from this and this link, that we need to foresee AAD P1 licenses in a ratio of 1:5 for these users. Correct?

- These external users will always need to register for MFA in our tenant (regardless if they are already configured for MFA in their own tenant). So they might end up with multiple MFA registrations. Correct?

Both Yes

- The requirement page mentions that MFA is required for "Microsoft commercial cloud services". Can you provide a definitive list of applications which we need to target via "Conditional Access policies"? Would "Office 365 Exchange Online" & "Office 365 SharePoint Online" be sufficient? Or do we also need to add "Yammer, Microsoft 365 Dynamics, Flow, Planner, Teams,..."

Basically every app that is listed in the respective AzureAD tenant, equivalent to the CA rule for "all cloud apps".