Force Provider on the User without the option for the User to change it or use another Provider

[TerrierX]

Hi guys,

First of all, thank you very much, what you have put together here is really top-notch.

Our scenario:
We want to use your solution to equip an external collaboration platform with MFA/2fa on ADFS.
Our wish is to have 3 "security levels" - depending on how sensitive the data is that the user will have access to:

• Level 1 - The user does not need an MFA/2fa provider.
• Level 2 - The user only gets the option for the email provider.
• Level 3 - The user only gets the possibility for the TOTP provider.

Why the distinction between e-mail provider and TOTP?
From our point of view, the e-mail provider is not as secure as TOTP, as the password can also be reset to the same e-mail address, but it is more secure than no second factor.
Why not TOTP then? The hurdle for a second device (phone etc.) can be too high in some cases.

Unfortunately, we have not been able to implement this scenario in our test environment (for example: Security Policy: Administrative / Mail & TOTP active - nothing else ticked) with all possible settings that we tried.

Is it possible to define the provider of a user with any combination of settings without the user being able to use/set a fallback option?

Our wish would be to create the users who need a second factor via PowerShell, define the provider and the user has no possibility to change or skip the setting of the Provider afterwards.
Preferably with the possibility that he can use the EnrollWizard with TOTP - although this is not mandatory and a direct sending of the QR code via mail would be sufficient as well.

Thanks for the time and effort you put into the project!

Regards,
Dominik

[redhook62]

as you can imagine, we will not do any user management in this component,
we believe that this is only a matter of the "Access Control Policies" of ADFS.

However, we eventually add a (global) option forcing the user to take the default method that will be assigned to him (totp, Bio, mail), without being able to change it at runtime.

Then, sending the QRCode by email does not guarantee that the user has an email, on the other hand this email is an emergency method, it is above all not secure.
If you use PowerShell to provision your users, then specify the -SendKey flag

[TerrierX]

Hi redhook,

Thank you for the super quick answer!

wow - that sounds very good and exactly what we had in mind.
That would be a global setting, as you mentioned above, right?
Timing sounds good, implementation by the end of June would be great for us.

regards
Dominik

[redhook62]

Hi,

There are several options, either it is a global parameter, or more surely at the level of each provider,
however certain other options will have to be disabled (like choosing your provider), of course access to the options will be restricted as well as the wizards. everything will be deactivated by default, I prefer that users have the choice...
In the same vein, it is possible to authorize registration (TOTP, Bio for example) during the first connection, although it is not secure.
We're still thinking about it

regards

[TerrierX]

Hello redhook,

How is it going? Can you provide a quick update on the topic?
Thank you :)

Regards,
Dominik

[redhook62]

Hi Dominik

We have been working on this since the beginning of the week.
We will have a first build to send you at the end of this week.

Regards

[TerrierX]

Thank you so much, can't wait to try it :)

[redhook62]

Dominik

Here is a preview that is scheduled for early July based on your feedback.
There are still some things to see, the registration phases (maybe you don't use them), the addition of parameters in the administration console.

It is preferable to install it on a test server before putting it in production.

To lock a user to their default method of MFA, you must modify a new property at each relevant provider. in your case :

Export-MFASystemConfiguration -ExportFilePath "c:\temp\config.xml"  # optional

$c = get-mfaprovider -ProviderType Code
$c.LockUserOnDefaultProvider = $true
set-mfaprovider -ProviderType Code $c

$c = get-mfaprovider -ProviderType Email
$c.LockUserOnDefaultProvider = $true
set-mfaprovider -ProviderType Email $c

If this is not the case, you can prohibit the choice by the user as well as set the general default provider.
Of course, you must set the correct login method for each user.

Please send us all your comments.

redhook
adfsmfa.zip

[redhook62]

Hi Dominik

A) You can do without self-registration entirely. To do this, activate the "Administrative Template" mode in the general settings.

B) you can register your users in powershell.
However your idea is interesting, to limit the registration process to the provider defined by default for everyone. this option could even be used in other contexts in order to offer quick registration, and to be able to keep all the options accessible afterwards.

C) You can select "Wizard disabled at enrollment" for the EMAIL provider.

We will add option B for the release

Once registered, there is no more enrollment process, however if users can access their options and you have authorized the Wizard on a Provider, they will then be able to re-register for TOTP, change their email or register a new Biometric device

regards
redhook

[TerrierX]

Hi redhook,

as always thank you for your fast reply.

A) But that would mean no registration wizard and I would need to send the TOTP Key via Mail am I right? (I am thinking about setting it up like this)

B) I think that would be perfect for us, then I could let the ones with code register themselves (with the Wizard) and the ones with email I would enroll via PowerShell

C) I tried to select "Wizard disabled at enrollment" for EMAIL provider in mmc but every time when I saved, the option was unticked again afterwards. I checked with PowerShell "Get-MFAProvider -ProviderType email" and "EnrollWizardDisabled" is True. But the Registration Wizard still shows/asks for the email address, it's now optional and I am able to ignore it but I would like to have it not shown at all.

Regards,
Dominik

[redhook62]

Hi Dominik

Regarding option C,
Currently for this to be taken into account the email provider must be marked as not required.
If there is an obligation to inform it, it will be proposed.
This is one of the things we need to test to ensure consistency across all configurations.

regards
redhook

[redhook62]

Hi Dominik

I enclose the latest implementation which will certainly be the July version.
The console has been updated, as well as all Nuget packages.
We have only to do some tests on the different platforms (2022, 2016 and 2012r2).
If you find a problem by the weekend, please let us know.

regards

adfsmfa 3.1.2207.0.zip

[redhook62]

Hi Dominik

New version available 3.1.2207.0

regards