Generating unique email id by checking the attribute in a DB on another network of ISC

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

There is a subsidiary Organization of Primary Organization both are on different networks, there is no direct connectivity between them, Both uses separate VA cluster and VA for integrating to same ISC tenant. While creating AD account on Subsidiaray AD , I need to validate the email id generated while creating the AD account against a burnedEmails DB on the Primary Organization Network. There is no direct connectivity between Primary and subsidiary Organizations. Also the Burned emails DB has only one column emailID which holds all the email ids generated or provisioned while creating new AD accounts. On the Primary Org they are using Powershell scripts in before create native rule to connect to burned emails DB and generate a new unique email id. we cannot access it from subsidiary network directly. Also the Burned emails table has only one column emailID, pls let me know how it can be integrated to ISC and how I can check for unique email id while creating AD account subsidiary AD.

2

Hi @vspatil2211,

You can make use of the promoted attributes as mentioned in this document

You can then use the idn.attrSearchCountAccounts method to evaluate the uniqueness of the attribute using an attribute generator rule as mentioned here.

The above method can evaluate the uniqueness of account attributes across multiple sources.

Here is a sample usage of the method.

import sailpoint.object.*;
import java.util.*;import sailpoint.rule.*;
import org.apache.commons.lang.StringUtils;

     List SOURCE_IDS = new ArrayList(Arrays.asList(new String[]{"4028112837fe14c70177fe1955e9032c","4028812877fa18c72177fs195baa0341"}));
     String PROMOTED_ATTR_NAME = "promotedEmailAddress";
     String SEARCH_OP = "StartsWith"; //Can also use "Equals"
     List SEARCH_VALUES = new ArrayList(Arrays.asList(new String[]{"[email protected]"}));

    //return matching accounts
     return idn.attrSearchCountAccounts(SOURCE_IDS, PROMOTED_ATTR_NAME, SEARCH_OP, SEARCH_VALUES));
     
     //In the event the above call returns non-zero values, it is certain
     //that an email value is already in use.  Should it be required to 
     //know which identity owns the account with this value, this method 
     //can be called.
     //idn.attrSearchGetIdentityName(SOURCE_IDS, PROMOTED_ATTR_NAME, SEARCH_OP, SEARCH_VALUES));
1 Like
3

If all of the Burned emails are in ISC, you can use the method that Jesvin mentioned.

If the BurnedEmails DB has other historical values that are not currently in use, you can set database up as a source in ISC and then use the method Jesvin showed. By setting it up as a source, you will be able to query it regardless of which domain you are provisioning.

4

Thank you all for the updates. The challenge is we can’t aggregate all the Burned Emails to ISC, I tried with JDBC Prov Rule and generate new email by querying to Burned Emails DB but getting challenge about how the new generated email can be updated back to a identity attaribute so thet it can be used for AD account provisioning

6

Why can’t you aggregate all the burned emails into ISC? I would think you would if you have used a jdbc rule to access it. We have very large sources for this purpose when we have to maintain historical ids.

If you really can’t aggregate them all in, then from your jdbc rule write back to a file source in ISC.

1 Like