Duplicate upn and emails are created after creation for AD

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

8.4P3

Please share any images or screenshots, if relevant.

[Please insert images here, otherwise delete this section]

Please share any other relevant files that may be required (for example, logs).

[Please insert files here, otherwise delete this section]

Share all details about your problem, including any error messages you may have received.

Hi,

We are facing issue while creation of Accounts in AD via sailpoint if users is having same name the it’s creating same email and upn. We have mention to check for unique but that’s not working. Can you please help on how it can be fixed. Below is the code snippet to check for unique email

public boolean isUnique(String userPrincipalName){
Filter myFilter = (Filter.eq(“emailAzure”, userPrincipalName));
QueryOptions qo = new QueryOptions();
qo.addFilter(myFilter);
Iterator identities = context.search(Identity.class, qo);
if(identities.hasNext()== false)
return true;
else
return false;
}

Thanks

AMit

2

Hi @ayadav_12 ,

Let me know which error are you getting.

Did you configure emailAzure is an identity extended attribute or not?

Thankyou

Harikrishna

3

@ayadav_12 Here is a simplified version of your code:

public boolean isUnique(String userPrincipalName){
Filter myFilter = Filter.eq(“emailAzure”, userPrincipalName);
QueryOptions qo = new QueryOptions();
qo.addFilter(myFilter);
int i = context.countObjects(Identity.class, qo);
return i==0;
}

Make sure “emailAzure” is a searchable identity attribute other wise filter search will fail.

If it is still failing, please share the error.

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(:heart:,:+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

4

Is SailPoint processing these identities with same name at the same time (in same batch for identity refresh)? If yes then you will need to have a different approach to handle it as the identity refresh may be triggering workflow which call isUnique method at the same time for all users and will be getting true for the same userPrincipalName.

5

Hi @neel193 ,

It’s not reading the IIQ data and directly pushing the provisioning form in AD to create the email and upn duplicate. I need that it should validate the iiq data first and then it should proceed with creation in ad and could increase the count also. for ex: if it’s amit.yadav@gmail.com already exist then it should create with amit.yadav1@gmail.com Please let me know how can this be solved?

Best Regards

Amit

6

Hi @SanjeevIAM ,

the workflow is not reading the iiq data and directly proceeding it with creation. if it’s a large gap before creation still it create with same email and upn. Please let me know how can we fix this?

THanks

Amit

7

@ayadav_12 Have you tried adding that code in your field value rule for email attribute? It should check if already exists or not and then accordingly increase the counter.

8

Hi @neel193 ,

Yes it’s added in the field value but we are directly pushing the data in AD and the pre check is unable to happen in IIQ is there any other way to do it without changing the original config.

Thanks

Amit

9

@ayadav_12 Do you mean we are adding users outside IIQ? In that case you need to define some script or policy in AD itself to generate the email.

10

Hi @ayadav_12 In which rule or workflow are you performing this uniqueness check?

11

Hi @r_pragati ,

We have mentioned this in a rule and added that rule in identity mapping for hr system in email attribute. still we are not able to get the unique value. is there a way to achieve this?

Regards

Amit

12

Hi @neel193 ,

It’s not able to check unique email in the system. do you have a process or a rule which can help in this case?

Thanks

Amit

13

Hey @ayadav_12 Apologies, but i am not able to follow your requirement. You might want to share the artefacts or the design which you are trying. Basically, want to know few things:

  • Are you creating users in AD directly? Not via IIQ, outside the IIQ process.
  • Are you assigning email over there while creating account.
  • If yes, are you expecting to validate the email against the emails available in IIQ?
14

Hey @ayadav_12,

I ran into something very similar before — the issue is likely where the check is running, not the check itself.

When the uniqueness logic lives in the Identity Mapping rule (HR system attribute), it fires during identity refresh — way before AD provisioning actually happens. So by the time the AD Field Value rule runs, it just picks up the already-set emailAzure value and sends it straight to AD without re-validating. If two same-name identities refresh around the same time, both get the same base email before either account is created. That’s the gap.

What worked for me was moving the loop into the Field Value rule on the AD provisioning policy itself, something roughly like this:

String base = firstName + "." + lastName + "@yourdomain.com";
String candidate = base;
int counter = 1;

while (!isUnique(candidate)) {
    candidate = base.substring(0, base.indexOf("@")) 
                + counter + base.substring(base.indexOf("@"));
    counter++;
}
return candidate;

// uniqueness check against IIQ identities
public boolean isUnique(String email) throws Exception {
    QueryOptions qo = new QueryOptions();
    qo.addFilter(Filter.eq("emailAzure", email));
    qo.addFilter(Filter.ne("name", identity.getName())); // exclude self
    return context.countObjects(Identity.class, qo) == 0;
}

This way the check runs right before the provisioning request goes to AD — not earlier during refresh.

One thing worth double-checking: make sure emailAzure is marked as searchable in your identity schema, otherwise the filter might not behave as expected. Easy to overlook if the attribute was added recently.

If you want an extra layer of safety, you can also check existing AD Link objects in IIQ — that catches accounts already aggregated even if emailAzure hasn’t been written back to the identity yet.

Hope that helps — let me know how it goes!

1 Like
15

Hi @ayadav_12 ,

As @abhi617 mentioned, if requirement is to create unique value during account provisioning, then code should be written in Provisioning Policy (probably Field value Rule)

Not sure how “emailAzure“ is configured, so probably you can iterate Link objects in code and check uniqueness.