Unique email address value for Entra

Hi All,

We are trying to generate unique email address for Entra. On Create Account page, we used a generator for mail attribute :

I found the same solution in this post - Email uniqueness in AD - #9 by MVKR7T

Unfortunately, it is not creating unique email address for us and account creation fails with the below error-

We tried ‘Create Unique LDAP Attribute’ generator also but that fails with error in identity itself -

Is there anything that we are missing here?

Thanks,
Abhishek

Hi Abhishek,

This may be because that existing account which was not aggregated into SailPoint. Do you aggregate all the accounts into SailPoint?

Thanks,
Karthi

Hello @at2410

Did you try to create a generator rule? you can use the attrSearchCountAccounts funciton from the javadoc to validate if it already exists.

Regards,
Pablo

Hi @at2410 - Entra is actually clashing on proxyAddresses attribute rather than email address. The generator is working correctly, it is just that that there is an account in Entra that has the generated email address as an alias (rather than the primary email address). This will require manual fixing. Either manually generate a new email address for the new user (this will mean that the clash may occur again for a similar scenario) or remove the alias from the existing user in Entra (the user may not want this).

1 Like

If you are familiar with graph explorer (Graph Explorer | Try Microsoft Graph APIs - Microsoft Graph), I think this should help you find out the existing account.

GET 1.0 https://graph.microsoft.com/v1.0/users?$filter=proxyAddresses/any(c:c eq ‘SMTP:[email protected]’)

Hi @ccarlton agreed, but you can also type the alias into an outlook new message and then resolve address (ctrl k on windows), should show the user.

1 Like

Hi @at2410,

Can you try to use the below screenshot in Generator may you use the static one and try.
example:

Thank you!

I think that the $uniqueCounter has to be at the end of the string. So create a username prefix with that pattern, then concatenate it with the $domainName

" * The transform allows you to use “uniqueCounter” as a reserved variable for numerically trying the next iteration of the pattern. Once the generator is active on a pattern with the “uniqueCounter,” it will keep incrementing until it either has found a unique username candidate, or it exhausts the “cloudMaxUniqueChecks” value. This means that the generator does not process any patterns after one containing “uniqueCounter.” The “uniqueCounter” must always be last in the pattern list."

Username Generator | SailPoint Developer Community

Hi @phil_awlings - I’m not sure the statement about last in the list means what you think it means, IMHO. I think it’s referring to the pattern list, not the variables within a pattern. It’s trying to say that it won’t iterate to the next pattern if it exhausts its increments on a single pattern. it should read “The pattern containing “uniqueCounter” must always be last in the pattern list.”

@j_place and in their pattern, it was not the last in the list:

image

They only have one pattern, so it is last in the list.

@phil_awlings an example of pattern list from Username Generator | SailPoint Developer Community

      "patterns": [
        "CN=$fi.$ln,OU=Users,DC=YourDomain,DC=com",
        "CN=$fn.$ln,OU=Users,DC=YourDomain,DC=com",
        "CN=$fn.$mi.$ln${uniqueCounter},OU=Users,DC=YourDomain,DC=com"
      ],
1 Like

That is not how I used to read that. :face_with_hand_over_mouth:
A school day it is.
Thanks @j_place

Copying @christina_gagnon (who made last edit to page).
Hi Christina - is it possible to clarify that statement in the docs?

Thanks Pablo!

We were looking for something that can save that pain of writing code and is OOTB too. We will certainly have this as an alternate option if the patterns and generator don’t work.

Thanks Jeremy! I guess you rightly pointed that out there is no way to change ‘proxyAddress’ since it gets populated internally by Entra. And changing anything manually is not acceptable and won’t solve the issue.

Also, to put in context, this is our sandbox environment and currently we are just required to populate email address in Entra. But ‘proxyAddress’ won’t let us do that and Entra admins not too keen on making any changes to it.

I guess, the pattern/generator that I posted in my initial post, will work fine for AD but not for Entra because in Entra SMTP, UPN and mailNickName all get propagated to proxyAddress field by default (don’t think they will change that and ideally it shouldn’t be). Now when ISC tries to generate a unique email, ISC checks for the uniqueness with proxyAddress too (not sure if it should be that way and I have limited knowledge/understanding of the technicals or working of Entra). Found this while browsing through Entra docs. This tells how proxyAddress is populated in Entra- How the proxyAddresses attribute is populated in Microsoft Entra ID - Azure | Microsoft Learn .

Also, as mentioned above, the uniqueCounter in our pattern may work for AD but not for Entra. Same pattern/generator has worked for others too. Reference - Email uniqueness in AD - #9 by MVKR7T

The only possible solution that I can see now (for our case) is, writing an AttributeGenerator rule for Entra’s mail attribute. - How to Search Non-Indexed Account Attributes in IDN Rules for Uniqueness - Compass

Our requirement is to generate a unique email address using the pattern (identity attributes) shared in my initial post. Setting static value is not what we are looking for.

Hi @at2410 have you checked that the email address that was attempted is not already an alias for another user?

It is there for an existing user. The attempted value is already there on email and proxyAddress for a user in Entra.

image

What I am not able to understand is, why would ISC go and check against proxyAddress and not just email address in Entra? And even if it has to check against both, then how do we handle checks on proxyAddress from ISC?

It’s not ISC checking, it’s attempting and Entra responding to say it cannot be allocated because the address is already being used as an alias