Hi Matt!

As far as I understand you need to have both. You need to tell Azure that your IDP is able to do MFA (SupportsMFA flag) and also tell that user has authenticated with MFA (authnmethodsreferences claim). A month ago I had a discussion about that with Jose Luis here:  RE: Planning for mandatory multifactor authentication for Azure 

Kind regards,

Sebastijan

Thanks. I did a search and didn't find it.

Is there some way to verify that it actually is working?

I see you used a virtual attribute, are you sure those extra "bits" are required?

Matt

You can already configure Entra to require MFA, for example https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates

Regarding virtual attribute, I have created it because in early on one customer required to receive multiple values (there was a specific requirement and I have no idea anymore what was it). Then I just kept this approach because it is flexible.

So I tested this in my test/lab tenant.  I used the Graph API to set FederatedIdPMfaBehavior to "enforceMfaByFederatedIdP".  There are more options when you use the Graph API, it's not just true or false.

I also added just the one attribute as a constant like this:

<saml:Attribute xmlns:xs="">www.w3.org/.../XMLSchema"
xmlns:xsi="">www.w3.org/.../XMLSchema-instance"
Name="authnmethodsreferences"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>
<saml:AttributeValue xsi:type="xs:string">schemas.microsoft.com/.../saml:AttributeValue>
</saml:Attribute>

I didn't even add the name space just to see what would happen.

It all works, but how can I tell if it is satisfying Microsoft's requirements?

Matt

So this is not working for me.  I Enforced MFA on a test user.

What I see when I try and login is a request like this:

<samlp:AuthnRequest ID="_b94585e6-7ae6-4174-9bf2-94608ed2108d" Version="2.0" IssueInstant="2024-09-26T14:29:56.154Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > <Issuerxmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer> <samlp:NameIDPolicyFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" /> </samlp:AuthnRequest>

Then NAM generated the Response, including my constant:

<saml:Attribute xmlns:xs="">www.w3.org/.../XMLSchema" xmlns:xsi="">www.w3.org/.../XMLSchema-instance" Name="">schemas.microsoft.com/.../authnmethodsreferences"NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" > <saml:AttributeValuexsi:type="xs:string">schemas.microsoft.com/.../multipleauthn</saml:AttributeValue> </saml:Attribute>

I added the name space, but I don't know why it is not including it.

Then Microsoft sends this:

<samlp:AuthnRequest ID="_781d6d53-067d-4b29-9901-efc758309789" Version="2.0" IssueInstant="2024-09-26T14:30:13.567Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > <Issuerxmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer> <samlp:NameIDPolicyFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" /> <samlp:RequestedAuthnContext><samlp:AuthnContextClassRefxmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">schemas.microsoft.com/.../multipleauthn</samlp:AuthnContextClassRef></samlp:RequestedAuthnContext> </samlp:AuthnRequest>

And that is where I fail:

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext" /> </samlp:StatusCode>

I'll try your virtual attribute solution from the other post.

Matt

So here is my update, I'm still stuck.  I did try using your suggested solution with the virtual attribute, but that is not my issue it appears.  Microsoft is sending this request after the initial authentication:

<samlp:RequestedAuthnContext>
<samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">schemas.microsoft.com/.../samlp:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

And NAM won't responds with a NoAuthnContext error because it doesn't know what to do.

So I tried using the "SAML2 CUSTOM AUTHNCONTEXT CLASS REF LIST" setting to get NAM to reply, but that did not work.  So next I tried "SAML2 REQUEST IGNORE AUTHCONTEXT".  NAM replies now, but I get in an endless loop with Microsoft, back and forth, and eventually Microsoft indicates a login failure.

I'm a bit stumped on how to make this work.  Any other ideas?

Matt

Hi Matt!

Reading your last posts I think I spotted the difference between yours and mine setup.

I am using ws-fed/ws-trust to federate with Entra, but I think you are using SAML?

Oh yes, you are correct, I am using SAML, guess I should have pointed that out!

So here is another interesting thing..

I'm using the Graph cmdlets to set my federation settings, and I set my domain to enforceMfaByFederatedIdP.  But I decided to look at the settings via the MSOnline cmdlets and when I looked there, SupportsMfa was set to False.  So I changed it there to true.  At first I got some odd behavior but not it is back to the endless looping between the AuthN request and the SAML assertion until Microsoft final gives up and says "We couldn't sign you in".  

Microsoft says I'm not satisfying this request:

<samlp:RequestedAuthnContext>
<samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">schemas.microsoft.com/.../samlp:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

But I don't know how to.

Matt

Hi Matt,

sorry for late response, but have just spotted your post. I have configured SAML authentication with Microsoft and checked my SAML requests and responses vs. yours and would have couple of questions.

1st : How is your AuthnContextClassRef configured in your first SAML response, if it is even present?
mine is like this: <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>

2nd: What class are you using for authentication? Classes have the method getType() hardcoded into the source and some might not return exactly what you would like -  I did not check all of them, but most that I have, have it hardcoded - for me it works with Protected password class (maybe you could verify if it works with this class first?).

Kind regards,

Sebastian Novak

I would add to my previous reply, that we faced the issue with AuthnContextRef also here:

 How is SAML2 CUSTOM AUTHNCONTEXT CLASS REF LIST expected to work? 

Authentication context was only defined in Secure username/password class.

With kind regards,

Sebastian Novak