Hi achinayoung_wau

Could you clarify your question?

It looks like you use AzureAD driver for AAD users management. Is it right?

You have at least 2 options for validation (in reality, many more options).

1. Store copy of AAD user attributes in eDirectory user object and query required for validation info in eDirectory.

2. Azure driver supports query operations for user class on Sub/Pub channels. That means you can query "common" AzureAD attributes.

Suppose the attributes you need for validation are not covered "by default" by AzureAD driver.

In that case, you can use a special technique for executing "external" specially crafted powershell scripts (that are going to pull info from AzureAD), "maintain" info in eDirectory, etc.

An option we have used in similar scenarios is to use the driver's publisher channel and synchronise a unique list of proxyAddresses for ALL objects from the app to an object in IDM. (assuming the IDM driver is capable of polling for changes to this attribute).

Storing this in for example, a mapping table makes it easy for IDM drivers to check if a proposed mail address is already in use or not.

Yes, we are using the AzureAD driver. Our goal is not to keep a list of "used" email addresses in eDirectory but, when a new account is created, to query AAD in readl time to determine if the new email address exists either as the UPN or a proxyAddress. We have stored the email attributes in the past but did not track aliases that get created when a surname or given name changes. So, rather than tracking these changes via attributes in eDirectory, we'd rather just query Azure to determine if that email address is taken.

So this requires a multi-valued attribute in eDirectory which mirrors the proxyAddresses attribute in Azure and then comparing the multi-valued attribute in eDirectory against the new email address to ensure it is not taken when a new user is created?

Your way (validate email address in AAD) can work, but I recommend having full control of email generation.

We use a special driver that generates a unique email address not used by any organization mail systems (we have several on-prem Exchange farms, 3 O365 tenants with EXO, 2 Lotus Notes, and several Unix/Linux mail systems). The mail infrastructure covered more than a hundred mail domains. Users can receive email for ANY mail domain owned by an organization.

Driver uses naming information from HR and generates email addresses with unique "left side". The right side (email domain) can be changed (email rebranded) at any time without user impact.

In your scenario, the driver generates a unique email address, and the AAD driver uses this generated email address for AAD user/EXO mailbox creation.