soft match with proxyAddresses

[pischta]

Hi,

I would like to connect on-premise AD with Entra ID. Users exist in both. Some users' UPN are the same in the on-premise AD and in Entra, but some have different UPNs, and I want to connect them with proxyAddresses. I created test users. I filled proxyAddresses for them in the on-premise AD and in Entra ID like SMTP:email address removed for privacy reasons, but when I run test, I  the following error:

"No action required. User '....' is not a newly discovered entry to be provisioned in the target application, nor one with an update that should flow to a target entry with which it was previously matched."

Skipreason: JoinNotFound.

[#2]

SMTP matching only works if the ImmutableID of the user object is null, so check for that.

[#3]

@Vasil Michev 

Thank you.

[#4]

When I create an ou based filter, so not every user will be syncronized, what will happen with the cloud-managed users, who don't have matching on-premise pair?

[#5]

@pischta 

Azure AD-native accounts will remain unaffected.

Accounts that originated from on-premise or were subsequently joined (becoming on-premise mastered) are soft-deleted once they fall out of AAD Connect's scope of management.

Cheers,

Lain

[#6]

Thank you. Just to clarify: We have several Entra users, who were on-premise managed, but now they are independent (we had an old on-premise AD, connected to the Azure AD, and we removed all our users from it). Are they AD-native accounts now? I hope, but I would like to be 100% sure about it.

[#7]

@pischta 

It's unlikely that they're Azure-native accounts now. It's possible, but unlikely.

The only way I recall being able to "convert" a user from Active Directory-managed to Azure AD native - without turning off directory synchronisaiton - is to:

1. Ensure it's no longer being managed via Azure AD Connect (which will cause Azure AD Connect to soft-delete the user account from Azure AD);
2. Recover the soft-deleted user account from the Azure AD "recycle bin" (within 30 days, or else it's hard deleted and no longer recoverable), at which point it's restored as an Azure AD-native account.

If you are ready to turn off directory synchronisation, then doing so converts all synchronised accounts (i.e. from Active Directory) to Azure AD-native accounts, but this is not something you do frivolously.

To verify if the account is Azure AD or not, check the OnPremisesSyncEnabled attribute. If it's "true" (as shown in the following screenshot), then it's still mastered by Active Directory, not Azure AD.

You can probably check using the Azure Portal, too, though I can't tell you exactly what the attribute might be labelled as, as I don't use it.

Cheers,

Lain

[#8]

Ok, I see. We've done that too: when we converted an account from on premise managed, we moved it to an OU what was excluded from the sync. The account deleted in the cloud, and we recovered it. My question was about that accounts. So these are the "Azure AD native" accounts, and so I don't have to worry about that they are deleted if don't have on-premise pair now/soft-match doesn't work for them.

[#9]

@pischta 

I'd check the OnPremisesSyncEnabled to be sure, but from what you're describing - given that you've already restored them, they ought to be Azure AD-native accounts now.

Auditing OnPremisesSyncEnabled is simply prudent as a safety check.

For any account where OnPremisesSyncEnabled is not true, you can freely manage or even delete the Active Directory or Azure AD accounts independently. Changes and deletions will not magically replicate from Active Directory to Azure AD or vice versa. (The obvious caveat is that any desired changes must be made manually to both account representations, too.)

Cheers,

Lain