Partner Center / CSP with Conditional Acccess

[Pirmin]

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....

[rhussain]

Hello

We have enabled MFA for users, everything was working fine before that but after enabling MFA Partner Center Api does not work and giving me this error

'Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access'

Then i read and go through this link https://docs.microsoft.com/en-us/partner-center/develop/enable-secure-app-model right now i am having an issue with step 2 of 'Secure Application Model framework' which is 

'Get authorization code' 

i cannot get the authorization code as it is in the link 

instead i get this error after following all the steps in above link

[JanoschUlmer]

@rhussain : "localhost" is just an example in this script. You need to use the URL where your web app endpoint is available. If it is deployed on your local machine you might to check firewall configuration.

[sreedwilson]

Hi All (and @idwilliams) - can I get some clarity on Conditional Access?  I've seen references in the forums that it is supported and that it is not.  I know IP Whitelisting is not in compliance (and makes sense) and that MFA must be enabled on all users in the tenant.  But what conditional access?  Specifically, if the device is Hybrid Azure AD joined?  Would that be in compliance or not?

[idwilliams]

Hi @sreedwilson, 

We have recently updated our documentation, you can find an answer to this question here. Also, I would like to add the answer here for quick reference 

Yes, you can use conditional access to enforce MFA for each user, including service accounts, in your partner tenant. However, given the highly privileged nature of being a partner we need to ensure that each user has an MFA challenge for every single authentication. This means you will not be able to leverage a feature of conditional access that circumvent the requirement for MFA. 

[sreedwilson]

Thank you.  While I am 100% in agreement with the need to make sure that partners are taking appropriate steps to secure tenants, I also hope that over time the Partner Center user model will be engineered to support more granular security controls and this could, perhaps, be revisited.

Specifically, users in our tenant who don't have access to customer data, guest accounts, and similar should be allowed to bypass MFA using CA.

[Jinseng]

I agree with @sreedwilson.  These policies should be enforced for users with access to CSP features, rather than everyone in the tenant.  We're still very concerned about impacts to the Sales process by requiring MFA for guest accounts.  I think very important features would be to have granular control of which CSP customers an end user has access to and being able to limit the access to just what they need.  Requiring full admin access to create support cases is overreaching.

Also, I would think Hybrid Azure AD joined would meet MFA requirements.  It's both something you know (Username and Password), and something you have (a trusted computer).

[sreedwilson]

Previously it was posted that the TPM rmay meet the requirements. We haven't had a chance to test yet as we've been focused on updating code and scripts. I'm hopeful that will meet the requirements.

If you test it please let us know. I will do the same.

[JanoschUlmer]

@sreedwilson : See here for details on how devices with a TPM might already have the MFA claim: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim

To be clear - it is not sufficient to just have Windows 10 devices with TPM and above mentioned configuration, still MFA has to be enabled for the user. The only benefit is that user will not see a MFA prompt when using this device - and if he uses Edge or Chrome )With MS account add-in).

You can see in AzureAD sign-In logs if access attempts from such machines are exempted from MFA because they alreay contain the correct PRT.

[Bellax]

If we enable MFA with conditional access (eg MFA is asked only if you are using a non trusted device) this configuration will be compliant with this new requirements?

Is There a test portal/URL where we can test our current MFA configuration with conditional access, just to check if our current setup will meet the future requiremtns of CSP portal?

Best regards

Alessandro

[JanoschUlmer]

@Bellax 

An exception to not require MFA for trusted devices will not be compliant as per the requirements documented in program guide.

Currently there is no way to test if the current implementation will technically be compliant - if you use custom conditional access policies to enforce MFA for every user and every service you will in effect use the same methods as with the baseline policies - so I see no reason why it won't be compliant. We will try to share details on what is required on the technical side of things once this information is ready, right now the focus should be to fulfill the contractual requirements as stated in program guide.

[cstelzer]

@JanoschUlmer your comment around "An exception to not require MFA for trusted devices will not be compliant as per the requirements documented in program guide.".

How is a "Trusted Device" considered an "Exception"? During business hours Microsoft explained "What is MFA"

Require two or more authentication methods

 Something you know (Password)

 Something you have (Device)

 Something you are (Biometrics)

Seems to me based on your very definition of MFA should meet requirements with things like Windows Hello for Business (Device/Biometric), or Hybrid-Azure AD Joined (Device/Password).

When you technically look to validate / enforce these, I assume that the Azure AD Team is going to look at the "MFA Result" field in the Authentication Logs, and I can indeed tell you that using Windows Hello for Business / Azure AD Join, or even "Passwordless Sign On" (Device/Biometrics) from my mobile device does indeed report under the sign in logs in Azure AD under "MFA Info" as MFA requirement satisfied by claim in the token.

Seems to me like adding an additional layer of my phone, on top of my already present MFA  (Device / Biometrics) is going WAY overboard in satisfying the requirements. I think there's a disconnect between what you're asking for, and how your going to technically validate this. In reality I would of hoped that the technical validation piece would of been thought through FIRST with the Azure AD Team, so you can make customers aware of the diffrent ways to acomplish the objectives.

[JanoschUlmer]

You are correct that by definition a device can be one option for 2nd factor.

I was referring to making a general exception in the conditional access rule - e.g. requiring a device to be compliant/managed or within a certain network boundary and then not enforcing MFA for those devices. 

This is what is not allowed. 

You are also correct that Windows 10 Hybrid joined/AAD joined devices with a TPM and/or devices using Windows Hello already contain the MFA claim, and so the user might not see the MFA prompt for a 2nd factor when he uses such a device. However, here the CA rule still says "require MFA", only the user experience will be as if no MFA was enforced.

As an example - Consider you do not enforce MFA for hybrid Joined devices in your own CA rule. Hybrid Joined devices with a TPM might still have the MFA claim and technically this would work and fulfill the requirements - but CA does not check if the device has TPM and thus a MFA claim in the token. So this rule would not block devices that have no MFA claim from accessing/authenticating - e.g. devices without a working TPM. So enforcing MFA for all is the correct option - on those devices that have a TPM you will still not experience a prompt for a 2nd (3rd) factor (if you use Edge or Chrome with addin).  

[idwilliams]

Hi @Pirmin, 

Perviously the security requirements where scoped to just Partner Center. There has been a change to the requirements that will require each user in the partner tenant to have MFA enforced when accessing Microsoft commerical cloud services. You can find more information about these changes at https://docs.microsoft.com/en-us/partner-center/partner-security-requirements

Note the MCRA will be updated with these requirements on July 1, 2019 and they will be enforced starting on August 1, 2019. 

[jvoermanjr]

Hi @idwilliams ,

The statement is that MFA must be enabled for all users. Because of the limitation of the baseline rules and that they are still in preview, we created custom CA rules which do exactly the same thing. Also we use identity protection instead of the end user baseline. Also because of the preview part and lag of functionality. 

The other part that is we need to have an emergency account (https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-access). Because we depend on Azure MFA we need another method (CA rule with for example user/location exeption). Otherwise we are unable to manage our environment when MFA has an outage. 

Are we compliant?

[idwilliams]

Hi @jvoermanjr,

As long as you are requiring each user to sign-in using MFA when accessing any Microsoft commerical cloud service you should be good. With the introduction of the new requirements each user, regardless of what role they have assigned, will need to authenticate using MFA. 

[Pirmin]

Hi Isaiah

Thanks for clearing that. To comply with new requiremts we need to have enabled

- Require MFA for admins 

- End user protection (which forces every user/guest to register for MFA and requires MFA if risky sign-in is detected)

correct?

Pirmin

[idwilliams]

Hi @Pirmin, 

Yes, enabling those baseline policies will make you complaint with these new security requirements. The baseline policies will continue to evolve over time. So, I would like to encourage you to review the baseline policies documentation from time to time.

[stan]

@idwilliamsCan you clarify how this enforcment will be done exactly? Previously you would enforce using the Partner Center API and Portal to login with MFA but since now this scope is expanded will that enforcment be done on other APIs and portals? Do you also plan to enable automatically (without ability to disable them) those policies that are in your documentation for all tenants or on all CSPs? If the scope is expanded that means we now have to accomdate to a larger amount of changes that we have to do. I also would like to complain that this was very badly planned - changing dates and plans several times and out of the sudden with very short period notifying us.

[idwilliams]

Hi @stan,

Right now there is a contractual enforcement of August 1, 2019 that requires each user in a partner to have MFA enforced. This can be accomplished through a number of different ways, including enabling two Azure AD baseline protection policies.  You are correct the scope of these requirements has expaned to sign-in attempts to any Microsoft commerical cloud services for users in a partner tenant. Thank you for providing the feedback, I will be sure that the appropriate teams receive it.

[cstelzer]

@idwilliams 

Still a little confused at how the below policy is going to meet the CSP requirement of "Enforce MFA"?

End user protection

End user protection is a risk-based MFA baseline policy that protects all users in a directory. Enabling this policy requires all users to register for MFA using the Authenticator App. Users can ignore the MFA registration prompt for 14 days, after which they will be blocked from signing in until they register for MFA. Once registered for MFA, users will be prompted for MFA only during risky sign-in attempts. Compromised user accounts are blocked until their password is reset and risk events have been dismissed.

If my sign in is not "At Risk", i'm not going to be enforced to MFA, so how is CSP going to validate this? If you're looking at the submitted claim for MFA, this won't always have it if the sign in is not "At Risk".

Azure Admin roles baseline I get, but again if i'm not in an Azure Admin role, and my sign in isn't at risk when logging into CSP, I technically won't have MFA enforced.