For my AD source, I already have a PowerShell script in place that handles OU movement on department change, and it works as expected. The script also includes logic for handling the “Disable” operation and moving users to the Disabled OU:
LogToFile("Entering Main Script")
$nativeIdentity = $requestObject.NativeIdentity
$operation = $requestObject.Operation
$Targeted_OU = ''
# Debug logging to see what values we're getting
LogToFile("Native Identity = $nativeIdentity")
LogToFile("Operation = $operation")
LogToFile("Operation Type = $($operation.GetType().Name)")
# Log all available properties for debugging
LogToFile("Request Object Properties:")
$requestObject | Get-Member -MemberType Property | ForEach-Object {
$propName = $_.Name
$propValue = $requestObject.$propName
LogToFile(" $propName = $propValue")
}
if ($requestObject.Operation -eq 'Disable') {
LogToFile("Processing Disable operation")
$terminatedOU = 'OU=DisabledOU,OU=ISC_Users,DC=demo,DC=info'
#Moving the AD User to terminated OU
Move-ADObject -Identity $nativeIdentity -TargetPath $terminatedOU
LogToFile("User moved to $terminatedOU OU")
LogToFile("COMPLETED")
}
below is remaining code for handle mover does not paste here
Upon checking the logs, I noticed that when the identity status changes to Inactive, the operation is detected as “Modify”, not “Disable”—which explains why the script does not move the user to the Disabled OU.
Yes, there is an after modify rule attached to my AD source.
LogToFile("Entering Main Script")
$nativeIdentity = $requestObject.NativeIdentity
$operation = $requestObject.Operation
$Targeted_OU = ''
# Debug logging to see what values we're getting
LogToFile("Native Identity = $nativeIdentity")
LogToFile("Operation = $operation")
LogToFile("Operation Type = $($operation.GetType().Name)")
# Log all available properties for debugging
LogToFile("Request Object Properties:")
$requestObject | Get-Member -MemberType Property | ForEach-Object {
$propName = $_.Name
$propValue = $requestObject.$propName
LogToFile(" $propName = $propValue")
}
if ($requestObject.Operation -eq 'Disable') {
LogToFile("Processing Disable operation")
$terminatedOU = 'OU=DisabledOU,OU=ISC_Users,DC=demo,DC=info'
#Moving the AD User to terminated OU
Move-ADObject -Identity $nativeIdentity -TargetPath $terminatedOU
LogToFile("User moved to $terminatedOU OU")
LogToFile("COMPLETED")
}
below is remaining code for handle mover does not paste here
I could suggest one thing till the root cause is identified…!!
Have a Workflow Trigger upon Identity Lifecycle changes to Inactive, and disable all the sources using Workflow Actions 1. Get Accounts and 2.Manage accounts
Ya, was about to take down the rule and try ootb can disable AD account or not. But my testing tenant seems is currently unavailable. Will update once the tenant back to normal.
then for now we can suspect as follows
1)disable operation may be triggered before all necessary processes have completed that causing it to fail.
2)if delta aggregation enabled? disable it
3)service account may be locking to disable due to permissions
4)sync issue
5)check account lock status attribute is configured properly
Frankly am not sure which might in your case please
yes attribute sync issue and there in AD there will be account lock status attribute
also take very peculiar issue called timing issue as i stated: disable operation may be triggered before all necessary processes have completed that causing it to fail
@Bernardc
Could you add powershell statement to disable the AD account once it is moved to disable OU,
I am not sure why sailpoint it not doing it, but when you say that account is being moved to terminated ou but not getting disabled, I believe Sailpoint Expects your powershell script to take care of that part as well.
I am also suspecting that, before SailPoint could actually disable the AD account, the script is moving that account to terminated OU and since the account is no longer in the OU that it were before, SailPoint is not able to find it so that it can disable..!!
So, ya, that would be my next suggestion, disable account using your powershell code itself…
