Modify provisioning plan in AfterCreate rule

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

Hello there,

We have an afterCreate rule and script used to create Mailbox. In this script we do not need to use anything other than memberOf and the nativeIdentity.
Moreover, some attribute have cause problems by ending string and so on causing the rule to not call the script.
i.e. An address with some quotes in the value.

As such, I would like to remove all but two attributes from the xml/string we have in the afterCreate rule.
But I do not how to interact with the xml object and functions we have in the rule.
part of the rule:

Try{
    if($enableDebug) {
        LogToFile("Entering SailPoint rule")
    }

    Add-type -path Utils.dll;
 $sReader = New-Object System.IO.StringReader([System.String]$env:Request);
 $xmlReader = [System.xml.XmlTextReader]([sailpoint.utils.xml.XmlUtil]::getReader($sReader));
 $requestObject = New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader);
    $requestAsString = $env:Request

    if($enableDebug) {
        LogToFile("Request as XML object is: $requestAsString")
    }

    #Call the client script
    $command = -join ($command, " -requestString '$requestAsString'")
    Invoke-Expression $command

}Catch{
 $ErrorMessage = $_.Exception.Message
   $ErrorItem = $_.Exception.ItemName
   LogToFile("Error: Item = $ErrorItem -> Message = $ErrorMessage")
}

if($enableDebug) {
    LogToFile("Exiting SailPoint rule")
}

Do you have any advice on this topic, or/and a way to modify the values sent to the script?
I would prefere to not use a beforeCreate rule as not all attribute are sync, and so I want to make sure the AD account is still created with attribute filled.

Thank you.

2

Hi @RLM-AP,

Try below script line to get two attributes’ values of native identity and memberof values

$nativeIdentity = $requestObject.NativeIdentity
if($requestObject.Operation -eq 'Modify') 
{
    foreach ($attribute in $requestObject.AttributeRequests)
    {
	    LogToFile(" Entered the ForEach loop of the attribute Requests and Attribute Name is : ")
	    LogToFile($attribute.Name)
        if(($attribute.Name -eq "memberOf"))
	    {
	        $memberOf = $attribute.Value
		    LogToFile("Attibute value is :")
		    LogToFile($memberOf)
        }
    }
}#end of if condition

remove this lines from your script
$requestAsString = $env:Request
$command = -join ($command, " -requestString ‘$requestAsString’")
Invoke-Expression $command

Thank You.

3

Hi @gogubapu,
Thank you for your quick response.

I see, through this for loop, we can get both values I am looking for.
But after that I still need to send these values to another script (the one that create the mailbox, or modify it) on the IQserver.
By removing the lines with the invoke command, I would no longer be able to send the attributes values (nativeIdentity and memberOf)

I still need to rebuild the xml and format it into a string before sending it I think.

I will still look into the code you wrote.
Thanks.

1 Like
4

In IQservice there you may use this loop in your mailbox script, get the required attribute values and pass in the script.

5

Hi @RLM-AP,

If your AfterRule script is failing because of a quote issue, you can try something as below to escape the single quote :

$sReader = New-Object System.IO.StringReader([System.String]$env:Request);
$xmlReader = [System.xml.XmlTextReader]([sailpoint.utils.xml.XmlUtil]::getReader($sReader));
$requestObject = New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader);
$requestAsString = $env:Request
$requestAsStringUpdtd = $requestAsString.replace("'","''")

$command = -join ($command, " -requestString '$requestAsStringUpdtd'")
Invoke-Expression $command

Also, as per the documentation, it is not advisable to add a lot of customer logic in the rule script. It needs to be handled in the powerShell script within the IQServer.

2 Likes
6

You can also consider using a beforeCreate script that allows you to modify the provisioning plan. This is documented under Entra, but you can follow the same process for AD:

Before and After Scripts for IQService.

7

Hello there,

It worked fine for me.
That is what I was searching for, thank you for your help.

The reason I could not use the logic in a before rule or in the script, is because in a before Rule it would have change the plan for the creation a AD account (if the attribute is not sync I would have needed either a workflow or a beforeProvisioning to later add a value), and in the script it would still not have been called because of the error in the rule.

Thus modifying the rule was the only feasible solution in my opinion.
Thanks everyone.

8

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