Disable automatic User Import

[derSchweiger]

We've another strange issue with our ADFS MFA implementation. From time to time, users get imported from our Active Directory into the MFA user management console. Since the imported users are disabled, they cannot register through Self Service Registration and receive the following error message when they try to login:

I don't understand why this user import occurs at all. I haven't enabled any Active Directory import features for this MFA module. My current workaround to fix this issue is scanning every 20 minutes for disabled user and deleting them:

Get-MFAUsers -IncludeDisabled | where {$_.Enabled -eq $false} | Remove-MFAUsers -Confirm:$false

My current MFAConfig:

PS C:\Users\adm.kschweiger> Get-MFAConfig

AdminContact                      : notify@contoso.com
Issuer                            : Organization
DefaultCountryCode                : de
DefaultProviderMethod             : Code
LimitEnrollmentToDefaultProvider  : False
UserFeatures                      : AllowChangePassword, AllowManageOptions, AllowEnrollment
CustomUpdatePassword              : True
KeepMySelectedOptionOn            : True
ChangeNotificationsOn             : False
AllowPasswordsReset               : False
UseOfUserLanguages                : True
AllowPauseForDays                 : 7
AdvertisingDays                   : {FirstDay : 1; LastDay : 31; OnFire : True}
UiKind                            : Default
UseUIPaginated                    : False
PrimaryAuhenticationOptions       : None
AdapterPresentationImplementation :
ForcedLanguage                    :

Things I've already checked:

• There are no records regarding this import in the eventlog
• There are no logfiles in "C:\Program Files\MFA" like "adimport-*.txt"
• The import seems to start randomly. There is no fixed schedule
• Only the attribute "username" is filled out. E-Mail and phone attributes are still empty. If I start another manual AD import, these attributes get synced.

Do you have any idea why this synchronization is going on at all?

[redhook62]

@derSchweiger

Yes, after an import of users they are active by default, however the required properties must be present. If your import does not work, while interactive it does. Be sure to set the identity on the import job process. The account must have read rights on all attributes of each user

regards

[derSchweiger]

Hi @redhook62.

the problem is, that this import happens without our assistance. We don't want to have an automatic import schedule enabled in the background. Do we have any chance to disable this?

[redhook62]

Hi @derSchweiger

Importing users is not automatic. So you can launch it manually whenever you want. However as indicated, the account running the powershell snappin must have the appropriate reading rights on your ADDS (including trust relationships)

regards

[derSchweiger]

I don't know why but after some time users get imported into the MFA user management overview without our doing. Current view:

After some time:

It's very strange that not all AD users get imported. It seems a little bit random.

[derSchweiger]

OK, nervermind. I might have found the reason for this import. After disabling the password policy feature (304) this import hasn't been triggered again. This makes sense of course. Users get imported as disabled user objects, because their password is too old and needs to be changed in first place.

Thanks for your help!

[redhook62]

No, is not random.

If you enabled the TOTP by email in example, the import must find an email for the user, if not, the prerequisites are not met and the user is deactivated pending the intervention of an administrator. Additionally a valid UPN is required by default.

[derSchweiger]

But all imported users have a valid e-mail (mail attribute), UPN and phone number in Active Directory. But it seems like that these attributes are not imported to the MFA user management.

For example, imported user:

Corresponding AD user:

[redhook62]

Hi, @derSchweiger

• Check execution rights on ADDS,
• Check the logs that are generated in the C:\Program Files\MFA directory.

We have a multitude of customers who use this functionality with sometimes a multi-forest configuration. Refer to the examples: Import Users From ADDS

Regards

[derSchweiger]

The service user is Domain Administrator (just for testing purposes) and there is no multi-forst constellation in place. The weird thing is, that there are not logs regarding this imports. If is start an Active Directory import manually, a logfile "adimport-XXX.log" gets created.

In this case: no logfiles at all.

[redhook62]

what I can tell you is that with each import a log file is created in this directory unless you indicate that you do not want -Nologs logs.

So at least open your powershell session in admin mode. Have you met the prerequisites indicated in installation. The problem is with you. your lab is not stable or other, please search on your side.

When you have the logs, you will see that it surely works

[derSchweiger]

I've found the issue.

The Active Directory configuration for "WebAuthN Public Key" is referencing to the attribute "msDS-KeyCredentialLink". This attribute is used by Windows Hello for Business and is therefore populated by some users. I've changed this attribute to "otherMailBox" (which is unused) and all disabled users disappeared.

Thank you!