We have an AD disable policy created through transforms as attached:-
When there is a termination happening for user from workday last day attribute through snow connector
this policy when triggered in AD is updating the user OU from parent to Disabled user accounts and also setting attributes msExchHideFromAddressList to True and extensionattribute12 is set as 30 days from today’s date.(with this date the account will get deleted after 30 days in AD)
This is working as expected when the user is automatically terminated.
But if someone is doing the movement of OU manually before this policy triggers its failing and not setting the attributes in AD.
So we would like to know can we change the current policy to something and how that can be done or else can we user this policy trigger in loop where it checks the user already moved manually to disabled user account and then sets the attribute.
We did check the native change detection is enabled for account create update and delete in AD config, but its not enabled for attributes monitoring. can we enable if for particular attribute, will it detect the OU movement and set the two attributes or do need to handle it seperately?
Per my understanding, the connector is behaving as it should.
In ISC, the reference of a target account is through the distinguishedName. That’s how it would locate the user, update the extensionAttributes as per the policy and then modify the AC_NewParent. But if the target account does not exist in the specified location as the distinguishedName, ISC has no way of knowing that the user account was manually moved to another OU.
Also, native change detection might not help as well for your scenario. Ideally, you might want to ensure that the accounts on the target AD are not manually moved.
Have you considered making use of an afterModify powershell script.?
If there is an attribute you are syncing to AD from your source of truth (eg. employee status that changes from Active to Terminated), you can trigger a powershell script for that change that can update your AD attributes accordingly with the powershell commands.
You can also take a look at the Services standard before provisioning rule to achieve something similar and is recommended to achieve a number of AD use cases.
@yogita_rathod8 This is expected behavior , the connector thinks the user is in one container but he is not, and them fails. To avoid that you need people to stop moving manually.
@yogita_rathod8 have you created a modify policy in the provisioning policy .setting that policy with resync the group into correct Ou.alternatively you can write a before rule to change to correct ou in case ou has changed which will be reflected once you run the aggrgation job.
Let me know if you have these in place
If you want to implement an after modify rule, check these documentations - Link1, Link2
Assuming that you are syncing an attribute named employeestatus (AD attribute) to AD from IDN with value as T when a user is terminated, I am attaching a sample rule that can be helpful in your case.
The rule will take action whenever the employee status value changes to T and updates the extensionAttribute12 and msExchHideFromAddressLists to the desired values.
Also, as I mentioned in my earlier response, Services standard before provisioning rule can be a better option too. You can check the capabilities of it in the below document.
Just to provide another suggestion, i believe this can also be achieved by creating a new identity attribute. You can try to create an identity attribute to hold the value of extensionAttribute12.
NOTE :- I am assuming that in AD you store the extensionAttribute12 only for the disabled users and it holds a date when the account should be deleted.
In extensionAttribute12 identity Attribute, you can then you can use a transform which will first check if the user is in disabled ou in Active directory and current value of extensionAttribute12 is blank, if this condition is matches, then you can simply add 30 days to the today’s date and store in this attribute as per AD date format.
If the condition does not match, then you can store the same value of extensionAttribute12 value as it is there in AD.
Then you can remove this attribute from disable provisioning policy and configure this attribute in attribute sync configurations.
Please check if this could be a feasible solution in your case.