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).
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."
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.”
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
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.
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?