Detect changes that occur in Active Directory (not AR) and trigger an action?

This can be done.  You just need to enable the detection of changes from the Dirsync control.  There is a school of thought that this type of detection can be impactful on the Active Roles Service's performance but it's worth a try as if you are doing this only a limited basis, it's not likely to be a big issue.

You have to enable "Handle changes from DirSync control" option on the policy script that will detect the change.

Here's a discussion of the concept:

www.oneidentity.com/.../setting-a-virtual-attribute-triggered-from-dirsync-change

This ask can be done in Active Roles in two ways:

1) Via a custom policy script.

2) Via a scheduled Automation Workflow.

A custom policy script can be triggered by native changes if the associated policy is set to "Handle changes from DirSync control"

For more information, see this solution:

Title: Active Roles Provisioning Policies are only triggered by Active Roles clients

Solution: 311680

URL: https://support.oneidentity.com/kb/311680

Although an Automation Workflow is not a "triggered change", the end result may be just about the same due to delays resulting from Active Directory replication.

You are too quick for me, sir.

Guilty.  

I appreciate both you guys answering!

Based on the KB and the linked forum post I think I understand how it would work.

It appears to basically work the same way it would if you were dealing with ARS directly.

A few additional questions:

• Is there a log of for the DirSync? I ask only because I am not entirely sure what attribute I should be checking for. I will do some research to get the exact name of the attribute that AD uses to the store BitLocker key.
• Performance wise, I would only be checking on computer objects and I will also implement the check to only process if the BitLocker is created. Do you think this could significantly hurt the performance of AR?
  • I will be curious to see how this is handled because the values aren't really updated, they are added to. 

I will see if I can create just a short dummy script to just test the triggering, I am curious to see how it will.

Thank you for your help guys!

Regards,

Todd

There is no log for the DirSync event, as such, but there is a log for the script module. You can see examine the $Request and other Workflow objects by writing them to a file or by reviewing the Debugging log.

Enable the logging by right-clicking on the script module in the Active Roles Console and go to Properties | Debugging

Brilliant. Thank you kindly sir!

todd harrison - I implement my own log function in all of my scripts as I find the built-in debug logging very "unfriendly".  Here's an example:

function Logit ($Text) # Simple function for creating timestamped log entries
{

$LogPath = "\\ARServer\LogsShare\MyCurrentScriptName\MyCurrentScriptName_log.txt"

$Timestamp = $(Get-Date -Format "MM/dd/yyyy hh:mm:ss").ToString()

$Text = $Timestamp + " " + $Text

Add-Content -Path $LogPath -Value $Text

} # End of Logit function declaration

# Here's some sample code

Function MyPolicyScriptFunction ($Request)
{

$RequestUser = $Request.DN

Logit "In-process user is [$RequestUser]"

}

Hello 

I'm trying to configure a password change in AD to trigger a modification of a virtual attribute in ARS using Dir Sync control via policy object script. 

The script is below however when I change the password in native AD I don't see any modification. Is there something wrong with the script? 

function IsAttributeModified ([string]$AttributeName, $Request)
{
$objEntry = $Request.GetPropertyItem($AttributeName, $Constants.ADSTYPE_CASE_IGNORE_STRING)
if ($objEntry -eq $null) { return $false }
if ($objEntry.ControlCode -eq 0) { return $false }
return $true
} #-- IsAttributeModified

function onPostModify($Request)
{
if($Request.class -ne 'user'){return}

if(IsAttributeModified 'userPassword' $Request)
{
Set-QADObject -proxy $Request.DN -ObjectAttributes @{'edsvaAmundiInviteMailboxCreation'=$TRUE}
}
}

"userPassword" is not a real attribute.

Try changing the trigger to check for when "pwdlastset" is updated. This attribute is typically only updated by a password change.