Set AC_NewName & AC_NewParent in Connector Rule

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

Hi everyone,

I am currently working on mover Scenarios and handling attribute changes.
One of the topics is handling name changes. When a name is changed the CN should be changed too. I am trying to use a before modify rule to set AC_NewName when a name is changed through this logic:

    $cn = GetCnForNewAccount $givenName $lastName $nativeIdentity
    if (-not [string]::IsNullOrEmpty($cn)){
    Set-AccountRequestAttribute $req "AC_NewName" "CN=$($cn -replace ',', '\,')"
    }

function Set-AccountRequestAttribute([object]$req, [string]$name, [string]$value) {
    LogToFile("Setting account request attribute: $name = $value")

    if ($req.Attributes -eq $null) {
        $req.Attributes = @{}
        LogToFile("Created new Attributes hashtable")
    }

    $req.Attributes[$name] = $value
    LogToFile("Set account request attribute: $name = $value")
}

When logging the final request I receive this xml:
<AccountRequest application="TEST AD [source-1755778166653]" op="Modify" nativeIdentity="CN=Morales4\, Miles,OU=Interne Mitarbeiter,OU=SWH,DC=Test,DC=IAM,DC=internal"> <Attributes> <Map> <entry key="uuid" value="{866e673d-1d0a-4091-9f0e-7a3f7607a920}" /> <entry key="cloudPreviousValues"> <value> <Map> <entry key="givenName" value="Marit" /> </Map> </value> </entry> <entry key="AC_NewName" value="CN=Reus\, Martin" /> </Map> </Attributes> <AttributeRequest op="Set" name="givenName" value="Martin" /> </AccountRequest>

which in my opinion matches the documentation Default Provisioning Attributes Reference

Is it not possible to set this attribute through a connector rule or did I oversee something?

Thank you in advance!

2

The connector rules give you access to read the provisioning plan, but not to modify it. That would have to be done in a before provisioning rule

You can technically use the services standard before provisioning rule, but that doesn’t account for uniqueness which can be problematic when trying to use AC_NewName.

I’ve gone back and forth on how to do this and haven’t been able to find a good solution, so I’d love for someone to chime in here

ETA: do you “effectively” control the provisioning plan by being able to modify the account in PS to your liking? Sure, I guess.

1 Like
3

Hi @mohammedfavazhrb,

You can do the configuration in the Update Provisioning Policy to support your changes.

Below is the example of the Update Provisioning Policy or you can also try the After Modify Script to do your changes.

{
“name”: “Account Update”,
“description”: “Account Provisioning Policy”,
“usageType”: “UPDATE”,
“fields”: [
{
“name”: “AC_NewParent”,
“transform”: {
“type”: “static”,
“attributes”: {
“country”: {
“attributes”: {
“values”: [
{
“type”: “identityAttribute”,
“attributes”: {
“name”: “countryCodeIso3166”
}
},
“null”
]
},
“type”: “firstValid”
},
“countryAD”: {
“attributes”: {
“values”: [
{
“attributes”: {
“sourceName”: “Active Directory [QA]”,
“attributeName”: “co”
},
“type”: “accountAttribute”
},
“null”
]
},
“type”: “firstValid”
},
“OU”: {
“type”: “identityAttribute”,
“attributes”: {
“name”: “xadOu”
}
},
“value”: “#if($country != “null” && $country != $countryAD)$OU#{else}#end”
}
},
“attributes”: {},
“isRequired”: false,
“type”: “string”,
“isMultiValued”: false
}
]
}

4

My issue is with changing the CN. I need uniqness checks there, which I could achieve through either a cloud or native rule

5

If the issue is with uniqueness then the best option for you is Cloud Rule only that too Before Provisioning Rule which will give you ability to do customisation as well do check for uniquness

6

But I was also able to modify Provisioning plans inside a before create rule and that worked too. I am trying to avoid cloud rules as much as I can, because I want to be more flexible and able to do quick chnages.

7

Hi @fayadm It’s my understanding that you can’t use a connector rule for AC type name changes because of the additional processing that goes along side the use of those special attributes. ISC itself has to know to do a single aggregation post provisioning to update the account ID, which it wouldn’t know to do if it was done on the connector.