Enforcing MFA from on-prem / ADFS
Having read the various other threads where this is mentioned, I've still not seen a clear answer from Microsoft.
If you have an on-premises user, with sync'd accounts (through AADConnect) , and all auth to cloud is performed via ADFS where the MFA is taking place - then you are *not* enforcing the baseline policies (else you would have MFA from the on-prem AD and then another layer of MFA from Azure!)
So how is this going to work / be enforced? are you expecting the claim from the ADFS to contain some identifier to show that it has satisfied an on-prem MFA policy? (as opposed to via Azure)
Hi, has there been an answer to this please? We are currently accessing the CSP portal using sync'd accounts and on-premise ADFS with MFA but it is reporting that we are not compliant. I have tested a login using Test-PartnerSecurityRequirement which was challenged by the on-premise MFA and it failed the test. The MFA challenge was completed using the Microsoft Authenticator app.
Is the on-premise MFA solution not supported for Partner Centre Security requirements or is there something we need to change?
Are you using Azure MFA with ADFS or a 3rd party solution?
See also https://docs.microsoft.com/en-us/partner-center/partner-security-compliance#are-you-using-3rd-party-mfa-solution & https://www.microsoftpartnercommunity.com/t5/Blog-Discussions/How-to-validate-your-solution/m-p/8315
If it is 3rd party and the vendor needs more time to implement this, you can ask for a technical exception: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa#request-for-technical-exception - though this is a bit late giving the enforcement for Partner Center access will happen on May 1st
Thanks for your response. It is not the cloud Azure MFA but the on-premise version of MFA Server. Would this still be referenced as "Azure MFA" (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfaserver-deploy)? Either way, I would not see this as a 3rd Party solution and I cannot seem to find any reference to this configuration? It looks to be setup correctly using the multi auth claim but just does not seem to be aligned to the partner requirements at the moment. Therefore, there is probably a setting I have missed somewhere.
Maybe reg. this note:
If you are using Active Directory Federation Service (ADFS), then you will need to ensure that the http://schemas.microsoft.com/claims/multipleauthn claim is being issued by the relying party trust.
For setting the claim rules see https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/walkthrough-guide--manage-risk-with-additional-multi-factor-authentication-for-sensitive-applications#BKMK_6 & https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-authentication-policies#configure-authentication-policies-via-windows-powershell
I have been through those articles and can see a difference between my configuration (which is working for granting user access to resources, including the Partner Site) and those articles. Could this be the difference that is causing our configuration to not work with the Partner site but work otherwise? (it is mainly missing the "c:" before type and not using the secure URL's).
for example, the article says to use...
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i) <group_SID>$"] => issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn")
My configuration uses...
AdditionalAuthenticationRules : exists([Type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value ==
&& NOT EXISTS([Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
=> issue(Type =
Value = "http://schemas.microsoft.com/claims/multipleauthn");
This looks like you are making an exception when the request comes from an internal network, which is not incompliance with the security requirements since MFA always has to be done, regardless of the location.
Have you tested with a user not in the internal network that mfa claim is issued?
OK, so when the testing feature for this external access attempt still shows a fail, I think it does not add value if you also decode the token to check its content, it is likely the claim is really not there.
I don't know what else to suggest, I'm not that deep in ADFS to offer additional advice.
You can of course raise a support ticket, or try to get additional advice on configuration by raising an advisory case via firstname.lastname@example.org - though I'm not sure if the Advisory team can solve this.
Appreciate the guidance you have given so far. I have logged a ticket with support and will see what their response is. I just wonder if anyone has this configuration working at the moment?
I use ADFS with MFA provided by Duo plugin for ADFS.
I also have it set up so inside corporate network, MFA is bypassed, but externallly it is required.
Using Test-PartnerSecurityRequirement internally fails (as i don't get prompted for MFA), externally it succeeds, even though I use On Prem MFA, and not Microsoft Authentication app.
Not sure if that helps
Not sure if it is going to help but had to follow the below steps provided by Microsoft Support last week. It seems the claim rules setup on my implementation was not correct and I was getting the same issue. I suspect this is because I did not let Azure AD Connect interact with my ADFS environment and was therefore unable to update the claim settings with "default" settings. I have been through a number of the article linked but I cannot see the below being set anywhere.
Go to ADFS management console --> RPT (Relaying Party) -->Microsoft office 365 identity platform " --> Edit claims rules or Edit issuance authorization rules.
Click on add rules and add the below 2 rules by selecting "Send a claim using custom rule"
1st rule to get the MFA claim:
@RuleName = "Pass through claim - authnmethodsreferences"
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"]
=> issue(claim = c);
2nd rule if they require MFA authentication timestamp should also be sent( this is optional 😞
@RuleName = "Pass through claim - multifactorauthenticationinstant"
c:[Type == "http://schemas.microsoft.com/ws/2017/04/identity/claims/multifactorauthenticationinstant"]
=> issue(claim = c);
With respect to the Partner Center Security Requirements please note that it is not compliant to set an exclusion from MFA when access happens from internal network.
Thanks for the feedback - Good to get verification that it works as expected with the 3rd party MFA service.
Note that MS Authenticator is never a requirement for any MFA solution - for all scenarios using Azure MFA you can also use any other token app instead of the MS Authenticator - using a 3rd party token app is not what is usually being referred to as "3rd party MFA". "3rd party MFA" in this discussion really means using a different service that trigger the MFA notification, like Duo in this case.
Understood on the internal usage with mfa.
It is only required for users with delegated admin permission right? or is it required for all users in the partner tennant?
@Wihan : It is required for all users in the tenant a Partner is using for transacting for CSP. So it is not limited to the users with delegated admin rights, it applies to all other users, service accounts, guest accounts - anything that is a user account in the respective Azure AD.
While MFA may only be technically enforced for certain scenarios, like Partner Center Access, the contract (MPA - Microsoft Partner Agreement) says in a generic way that all user account need to be enabled for MFA, the MPA does not differentiate between user roles.
So technically required only for some, contractually required for all.
The technical details on how the proper enablement of MFA will be technically validated and technically enforced are not published yet, for August 1 it will only be a contractual obligation to have this enabled.
Generally this article gives a good indication on how it might be technically enforced - similar to what you already assumed: https://docs.microsoft.com/en-us/partner-center/develop/partner-center-authentication?tabs=dotnet-app-only%2Cdotnet-app-user%2Cdotnet-csp%2Cdotnet-cpp#frequently-asked-questions :
How will the requirement for multi-factor authentication be enforced? This requirement will be enforced by ensuring that a claim of type http://schemas.microsoft.com/claims/authnmethodsreferences with a value of mfa is present. If it is not then authentication will be denied
I'm waiting for final confirmation internally if this is still true - since this guidance was created when the security requirements were initially announced and some things might have changed.
Thanks, though I think they meant "http://schemas.microsoft.com/claims/multipleauthn" as opposed to just "mfa" , I've raised a doc issue on the page