Block request being sent to IQService

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

Hey guys

We have a before create rule used for generating sAMAccountName and email for and Active Directory account

The sAMAccountName is made of the first letter of the identity’s first name concatenated with an incremental number that is stored on a file on IQService machine.
eg c000001

After consulting the file, the process updates the file adding +1 to the incremental number
There is a lock/mutex in the powershell script to make sure that the file is used by only one process at a time.

But sometimes a process dies because of timeout waiting for the lock, and when this happens, the request that is sent to the IQService doesn’t have the sAMAccountName attribute, so the account created will have this attribute with a random value starting with $ eg $E7E500-1R4GNAI9BCET

Where are using try/except throw syntax, and we thought that when raising an exception the request wouldn’t be sent to IQService, but it seems this is not the case.

Is there a way to not send the Request to the IQService when the waiting lock times out? Or when the before creation script starts running the request will be sent no matter what?

2

You could import the file into ISC as a delimited file source then use the cloud rule to compare across both sources.

You’d have to create new search attributes to make it work, but at least then you don’t have to worry about conflicts like you are now

1 Like
3

The request will be send to the IQService no matter what. Did you try increasing the timeout for the script ?

1 Like
4

This is something we’ve thought, but I couldn’t understand the difference between Identity Attribute Rule and Account Profile Attribute Generator.

In the Identity Attribute Rule’s documentation, it says:

An important consideration with IdentityAttribute rules is whether generation logic that includes uniqueness checks is acceptable. While not explicitly disallowed, this type of logic is firmly against SailPoint’s best practices. When calculating and promoting identity attributes via a transform or a rule, the logic contained within the attribute is always re-run and new values might end up being generated where such behavior is not desired. Additionally, the attribute calculation process is multi-threaded, so the uniqueness logic contained on a single attribute is not always guaranteed to be accurate. For this reason, SailPoint strongly discourages the use of logic that conducts uniqueness checks within an IdentityAttribute rule. The recommendation is to execute this check during account generation for the target system where the value is needed.

But isn’t the Account Profile Attribute Generator multi-threaded too?
In the Best Practices - Generating Usernames in IdentityNow documentation it says that using Account Provisioning Generation it is

Less likely to be affected by race conditions.

I don’t really get the difference between these two types of rules that make race conditions less likely

5

I just thought about this.

The ConnectorBeforeCreate rule on ISC only calls a script residing in the IQS machine.

Try{
    C:\Sailpoint\isc-adrule-bc.ps1 $env:Request
}
Catch{
    $ErrorMessage = $_.Exception.Message
    $ErrorItem = $_.Exception.ItemName
    "Error: Item = $ErrorItem -> Message = $ErrorMessage" | Out-File $logFile -Append
}

We are trying different ways of increasing timeout for the script in the IQS machine, but we didn’t modify the attribute in the ConnectorBeforeCreate.

    "attributes": {
        "ObjectOrientedScript": "true",
        "extension": ".ps1",
        "sourceVersion": "1.0",
        "disabled": "false",
        "program": "powershell.exe",
        "timeout": "300"
    },

I’m searching for more information about this timeout attribute, but I still couldn’t find some things:

  • Is it in seconds?
  • Does it have a limit?
  • When the rule times out, the request is sent to IQS automatically?
  • Is there a limit of how many processes can be running at the same time? I guess if there are too many waiting for locks/mutex (this only happens for the script residing in IQS machine) will ISC kill all of them? idk

I’ll try increasing the timeout attribute for the rule and see what happens