BeforeProvisioing Rule (cloud), and afterModify (Connector

Scenario:
User changes OU and PS scripts add and remove entitlements based upon OU settings.

When I was using the UPDATE function and AC_NewParent to move OUs, the afterModify script would fail because the nativeIdentity was grabbing the value of before the move, and trying to update that after the user had moved DN’s.
So, I wrote a beforeProvisioning cloud rule to move the OU, which works fine, but doesn’t update the cube that quickly. However, the afterModify rule is still picking up the original DN rather than the new one.

Has anyone else come across this problem?

This snippet of code solves the issue, but I would have rather that it isn’t needed:

 $CN = $nativeIdentity.Substring(0, $nativeIdentity.IndexOf(","))
  $nativeParentOU = $nativeIdentity.Substring($nativeIdentity.IndexOf(",") + 1)

  if ($nativeParentOU -ne $AC_NewParent) {
    $nativeIdentity = "$CN,$AC_NewParent"
  }
1 Like

HI @phil_awlings,

You can get account details directly from AD in PS script which will have the correct OU and add/remove entitlements, or you can add wait time in PS script.

Thanks.

Hi @nikhleshsdg

Thanks, but as I said, I’ve fixed the problem by updating the native identity.
I was frustrated that the beforeProvisioning rule hasn’t done what Sailpoint Expert Services said that it would do.

I was wondering if anyone else had come across this situation

Phil

@phil_awlings This is how it will work as even if you set the AC_NewParent in the BeforeProvisioning rule the requestObject will still have the same nativeIdentity (with old OU).

So in afterModify script you wont be able to find the user with nativeIdentity as the OU is already changed and nativeIdentity is not exist.

So we definitely need to prepare the new nativeIdentity (using CN and new OU) to get or provision the access to the account after OU is changed.

Hi,

I think that this is the prime example of why the native identity needs to be changed to the GUID.

Thanks
Phil

1 Like

I think that I might have resolved my issue with the following fudge:
Much more testing to do, but currently seems stable

  function Get-ProcessedUser($nativeIdentity, $logFile) {
    try {
      # Retrieve the user initially to get the objectGuid
      $initialUser = Get-ADUser -Identity $nativeIdentity -Properties objectGuid
      if ($initialUser) {
        $objectGuid = [System.Guid]::Parse($initialUser.objectGuid).ToString()
            
        # Retrieve the user again using the objectGuid
        $user = Get-ADUser -Identity $objectGuid -Properties sAMAccountName, employeeType, extensionAttribute15, MemberOf, objectGuid
        return $user
      }
    }
    catch {
      Add-Content $logFile "`n Error processing user $($nativeIdentity): $($_.Exception.Message)"
    }
    return $null
  }

You can get the new distinguished name in the After Modify script by pulling it from the resultObject.

Code is below. It pulls the DN from the request first, then checks the result to see if dn was one of the modified attributes

$sReader = New-Object System.IO.StringReader([System.String]$env:Request);
$sResult = New-Object System.IO.StringReader([System.String]$env:Result);
	
# Form the xml reader objects
$xmlReader = [System.xml.XmlTextReader]([sailpoint.utils.xml.XmlUtil]::getReader($sReader));
$xmlReader_Result = [System.xml.XmlTextReader]([sailpoint.utils.xml.XmlUtil]::getReader($sResult));

# Create SailPoint objects          
$requestObject = New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader); 
$resultObject = New-Object Sailpoint.Utils.objects.ServiceResult($xmlReader_Result);

#get the NativeIdentity
$dn = $requestObject.nativeIdentity
	
#check result for change in DN
$dist = $resultObject.Attributes.distinguishedName
if ($dist -ne $null){
	$dn = $dist
}
1 Like

Thank you,
That is a much more efficient way of doing it

You can also get the specific domain controller that was used (in case your worried about replication issues):

$dc = $resultObject.Attributes.createdOnServer