Leveraging Another Create Profile Attribute in an Attribute Generator Rule

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

Hi all,

We have a scenario where we are creating an AD account and using an attribute generator rule to generate sAMAccountName. This is no issue and we have that rule in place. However, the mail attribute depends on region and the patterns are as follows:

region 1: [email protected]
region 2: firstname.lastname(uniqueCounter)@domain.com

The issue is that region 2 requires a uniqueCounter. I explored trying to do this via the usernameGenerator transform but mail is not the accountId for AD so I don’t believe I can use it. I keep landing on an writing an additional attribute generator rule, but that hinges on the ability to reference $sAMAccountName. The other option is to just set it in a powershell after create rule, but I would like to avoid that if possible.

Is this possible or does anyone have a different suggestion?

2
  1. I would say, you would have used Transform to generate unique SamAccountName using Username Generator type.

I don’t think so, you can use for any attribute as per SailPoint documentation.

Use the username generator transform to specify logic to use when it derives a unique value for an attribute in an account create profile.

You can try the below transform, you need to work on it a little more. Input to the lookup and concatenation in region 1 to add domain. Test it out, it is worth to try rite.

{
  "attributes": {
    "cloudMaxSize": "100",
    "cloudMaxUniqueChecks": "50",
    "cloudRequired": "true"
  },
  "isRequired": false,
  "multi": false,
  "name": "mail",
  "transform": {
	"type": "lookup",
	"input": {
		......
	}
	"table": {
		"region 1": {
			"attributes": {
                "value": "$samaccountname"
            },
            "type": "static"
		},
		"region 2": {
			"type": "usernameGenerator",
			"attributes": {
				"sourceCheck": true,
			    "patterns": ["$fi$ln${uniqueCounter}@domain.com"],
				"fn": {
					"type": "identityAttribute",
					"attributes": {
						"name": "firstname"
					}
				},
				"ln": {
					"type": "identityAttribute",
					"attributes": {
						"name": "lastname"
					}
				},
			}		
		}
	}
  },
  "type": ""
}

You can reference it as well, let me check that. Also you should look into Account Profile Attribute Generator (from Template) Rule.

3

Hi Krishna,

Thanks for the quick response! I was actually thinking about something like this, and perhaps I am just confused, but this part of the usernameGenerator transform documentation is what I was thinking meant it would only check uniqueness against the accountID attribute.

  • sourceCheck - This boolean value (true/false) indicates whether the generator must check only the IdentityNow database’s representation of accounts for uniqueness, or whether it must query the target system directly. If no value is provided, the attribute defaults to false.
    • true indicates the generator must check the target system directly. The generator only respects this setting if the system supports the getObject functionality. For systems that lack the ability to query for single account objects, the generator ignores this setting and defaults to false. The generator only checks the attribute identified in the account schema as the accountID.
    • false indicates the generator must check only the IdentityNow database of accounts. The generator only checks the accountID.

Is this a misunderstanding on my part as to how this works?

4

I see your point, yes I have seen that discrepancy. Lets test this and observe the behavior.

We have used it for email attribute which is not an account ID attribute, still it works. Only problem is we cannot check uniqueness in AD side, but we can check uniqueness inside IDN.

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.